HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
프로그래머스 프론트엔드 데브코스 2기
프로그래머스 프론트엔드 데브코스 2기/
📓
기동팀/
💪
기동팀(CheQuiz)/
📌
07.01 이번주 의견
📌

07.01 이번주 의견

정말 너무 바빠서.. 전체 API 설계 생각까지는 못했습니다ㅠㅠㅠ 제 부분 API 관련해서 있어야 할 것 같은 것 + 디자인 시스템 위주로 생각해보았습니다! 밤샘 작성해서 내용이 이상한 부분 있을 수 있어요..! 그런 경우 언제든 슬랙 + 디코로 말씀해주세요!

회의 유용할(?) 자료

FigJam 링크
제가 오픈세션 눌러놔서 24시간 동안 100% 수정 가능이에요!
기동팀
Created with FigJam
https://www.figma.com/file/nif8T3sYmC08eQoVUEJVWq/%EA%B8%B0%EB%8F%99%ED%8C%80
기동팀
Figma 링크
오픈세션 이런게 없어서.. 혹시 수정 안되면 저한테 슬랙주세요!
기동팀 UI디자인
Created with Figma
https://www.figma.com/file/57DkQpe5ZyZaUtRR6Ioi2c/%EA%B8%B0%EB%8F%99%ED%8C%80-UI%EB%94%94%EC%9E%90%EC%9D%B8?node-id=558%3A7787
기동팀 UI디자인
선협님 회사 (cobalt) 디자인시스템
이정도로 하자는건 아니고, 그냥 참고자료로 가져왔어요!
Webpack App
Webpack App
http://blog.cobalt.run/co-design/?path=/story/co-design-core-affix--default

API 관련

[요약]

💡
유저 탭에 보여줄 문제를 어떻게 가져올지에 대한 의견이 궁금합니다 + 새로 모델 만들 때 사용자 이름 ( fullname) 에 unique 추가해주세요!! ( 닉네임 중복 방지 ) + 뱃지 시스템 어떨까요?
 
[ 유저 정보 관련 필요한 정보]
  • 이름, 경험치, 뱃지 정보, 문제 정보( 풀고, 만들고, 댓글달고, 좋아요 누른)
 
[유저 탭에 보여줄 문제를 어떻게 가져올지]
내용 보기
기존 API 상은 2번 방식인데, 데이터가 많아지면 통으로 모든 퀴즈를 불러와서 filter하는게 최선일까 하는 생각이 들어서 다른 방식도 생각을 해봤습니다! 다른 의견도 좋아요..!
  • 1안 유저 객체에 유저가 풀고, 댓글달고, 만들고, 좋아요 누른 문제에 대한 모든 정보가 들어가 있다
    • ( API 호출 1번)
      • 예시
      //User
{
	...
	solvedQuiz:QuizAPI[],
	madeQuiz:QuizAPI[],
	commentedQuiz:QuizAPI[],
	likedQuiz:QuizAPI[],
}
//or
{
	...
	Quizzes:{
		solved:QuizAPI[],
		made:QuizAPI[],
		commented:QuizAPI[],
		liked:QuizAPI[]
	}
}
  • 2안 퀴즈 객체에 문제를 풀고 / 댓글을 단 사람의 id가 들어있다.
    • ( API 호출 2번, 매번 모든 퀴즈를 가져와서 클라이언트에서 filter 필요 ⇒ 데이터가 많아질경우 우려 : 현재 API 방식)
      • 예시
      //GET /quizzes
//기본 퀴즈 데이터 통으로 가져와서 filter
[
	{
		...
		like:LikeAPI[],
		comment:CommentAPI[],
		author:User
	}
]
  • 3안 유저 객체에 경험치, 뱃지 정보 / 퀴즈에 유저 id 정보 표시
    • 퀴즈 데이터를 GET으로 가져올 때, 특정 유저의 id가 들어있는 정보만 가져올 수 있도록 strapi에서 커스텀 ( 전체 Quiz에서 filter)
      • 예시
      //GET /quiz/search/{userId}

//특정 유저의 활동 내역
{
	solved:QuizAPI[],
	made:QuizAPI[],
	commented:QuizAPI[],
	liked:QuizAPI[]
}

유저 정보 API

내용 보기

유저 정보 불러오기

[ method ]
  • GET
[ address ]
  • /users/{userId}
[ response ]
  • User[]

유저와 관련된 퀴즈 불러오기

위 1~3안 참조

유저 경험치 획득

[ method ]
  • PUT
[ address ]
  • /settings/points
[ request header ]
Authorization: bearer JWT토큰 //경험치 획득할 유저 정보
[ payload ]
{
		"points": Number
}
[ Response ]
  • User

닉네임 변경

[ method ]
  • PUT
[ address ]
  • /settings/user
[ request header ]
Authorization: bearer JWT토큰
[ payload ]
{
		"fullName": String
}
[ Response ]
  • User

비밀번호 변경

[ method ]
  • PUT
[ address ]
  • /settings/pad
[ request header ]
Authorization: bearer JWT토큰
[ payload ]
{
		"password": String
}
[ response ]
  • 없음
 

뱃지

모든 뱃지가 정의된 모델을 하나 만들고, 각 유저에는 획득한 뱃지 id만 있는건 어떨까요?
상세 설명
뱃지 모델을 정의해서, 현재 클라이언트의 breakpoints에 있는 뱃지 정보를 서버로 옮기고, 유저가 id만 가지게 되는거죠! 그렇게 되면 서버 측에서 뱃지 옵션을 바꾸면 일률적으로 적용하기도 좋고, 아직 획득하지 못한 칭호 이런 것도 바로 보여줄 수 있을 것 같아요!

뱃지 API

상세히 보기

모든 뱃지 조회

[ method ]
  • GET
[ address ]
  • /badges
[ Response ]
  • Badge[]
 

사용자에게 뱃지 부여

[ method ]
  • PUT
[ address ]
  • /badges/give-badge
[ request header ]
Authorization: bearer JWT토큰 //뱃지를 받을 사용자의 토큰
[ payload ]
{
		"badgeId": String// 유저에게 새로 부여할 뱃지의 아이디
}
[ Response ]
  • User
{
	...
	badges:[...{넣은 BadgeId, isSelected:false}]
}

사용자 뱃지 선택여부 토글

[ method ]
  • PUT
[ address ]
  • /badges/select-badge
[ request header ]
Authorization: bearer JWT토큰 //admin 토큰
[ payload ]
{
	"badgeId":String; //뱃지의 id
}
[ Response ]
  • User
[ 유의사항 ]
  • 존재하지 않는 id를 payload로 보냈을 경우 에러 헨들링
  • 데이터 보내면, User.badges 중 badgeId와 일치하는 배열 값의 isSelected 가 토글된다.
 

데이터베이스에 새 뱃지 정보 추가

[ method ]
  • POST
[ address ]
  • /badges/add-badge
[ request header ]
Authorization: bearer JWT토큰 //admin 토큰
[ payload ]
{
	"id":String; //uuid
	"label":String; //내가 레벨 100이라니! 등 칭호 이름
	"value": Number | String; //label을 붙이게 되는 기준
  "option": Optional<Object>; // 커스텀 데이터  (색, 혜택 등 기타 내용이 들어갈 부분)
}
[ Response ]
  • Badge[]
 

Badge 모델

{
	id:String; //uuid
	label:String; //내가 레벨 100이라니! 등 칭호 이름
	value: Number | String; //label을 붙이게 되는 기준
  option?: Object; // 커스텀 데이터  (색, 혜택, 얻는 기준 등 기타 내용이 들어갈 부분)
}
 

User 모델

{
	...
	userName: string // 유저 이름을 보여주기 위한 키값
	points:Number,
	quiz://퀴즈 관련 정보  (1~3안)
	badges: Object[], //배열 내부에 {badgeId, 선택 여부}
	data?:{} // 빈 객체 커스텀
	userImage:string
}
data 왜 넣었냐면요..!
 
이미지 조건부를 프론트에서 하고 있는데 이것도 서버에서 조건부 매칭하여 userImage 키 값으로 내려주면
좋을것 같습니다.
 
 
 

디자인 시스템 관련

혹시 Figma, Figjam 작동 안되면 슬랙 연락주세요!!!
위쪽 쓰다가 시간 배분 실패로…. 간단하게 적습니다 ㅠㅠ

스토리북 관련

선협님 회사에서 쓰는 스토리북처럼, 저희도 각 디자인 부분 만든 사람이 스토리북까지 추가해주면 좋을 것 같아요! ( 일단 저는 할 의향 아주 많습니다)
어떤 컴포넌트를 만들었다고 PR에도 적겠지만, 그걸 찾아보는 시간이 걸리기도 할 것 같아서 스토리북으로 직관적으로 보여주면 더 잘 사용할 수있지 않을까 싶습니다!
 

어떤 컴포넌트를 만들어야 할까요?

  • typography에서 h1~h6 + large, medium, small 이런 식으로 표시해둔게 있는데, 컴포넌트로 만들어도 좋을 것 같아요! ( 선협님의 강의에서 text 컴포넌트 만들었던 것 처럼)
  • 푸터도 있으면 좋을 것 같아요! 지금은 메인 화면만 딱 있으니까 아래에 뭔가 더 있을 것 같은 느낌이 조금 드는 것 같아요!
  • 카드 틀을 만들면 좋을 것 같아요! width + height props로 받고, border 3px solid + gray_800 + border-radius 8px 적용한 카드 컴포넌트를 만들면, 다른 부분 개발할 때 받아서 사용하면 좋을 것 같아요!
      • 예시
      export const Card = styled.div`
	...
`;

exponrt const userCard = styled(card)`
	
`
  • 로딩 관련 컴포넌트도 만들어두면 좋을 것 같아요! 스켈레톤 같은?
  • 그 외 컴포넌트 ㅡ 버튼, 텍스트 컨테이너, 이미지 컨테이너,토스트,태그
    • container 컴포넌트 너무 정의 애매해요 ☹️ㅠㅠ
 

또 어떤 작업을 해야할까요?

  • theme 통일도 해야하고,
  • 무엇보다 디자인시스템 만들 때, 적용시켜서 전체적인 컴포넌트 크기를 조금 줄여야 할 것 같아요..! 생각보다 크더라구요 ㅠㅠ
  • 베이직으로 구현한 부분을 지금 체퀴즈에 친화적인 API로 바꾸어서 우선 구현한 후
  • 그 후에 advance로 진행할 사항에 대해서 논의하는게 좀더 효율적일 것 같습니다.
  • 지금은 넓게 보려고 해도 커스텀한 api가 없으므로 확장해서 생각하기 힘들거 같아요.
 
디자인시스템 관련은 필요한 컴포넌트 회의하시면 그것 보고 열심히 만들어볼게요!!