개발에 들어가기에 앞서 큰 그림을 먼저 그려야합니다.

• 페이지 전체의 데이터 플로우를 알아야 합니다.
• 데이터가 흐르는 전체적인 구조를 봐야 데이터를 API, 설정파일, 목데이터(Mock Data) 등 어떻게 정리해야할지 알 수 있습니다.
• 보통은 보이는 화면만 그리게 되는데 그러면 그 뒤에는 관리되지 않는 수많은 데이터들이 남습니다.

프론트에서 실수할 수 있는 포인트 중 가장 큰 것이 데이터입니다.

• 그 중에 가장 먼저는 인증 입니다.
• 인증의 종류는 OAuth, Cookie, Session 등이 있습니다.
• 인증이 제일 먼저인 이유는 인증을 어떻게 하느냐에 따라서 뒤의 플로우가 전부다 바뀌게 됩니다.
  • 예시, 인증을 한 유저와 인증을 안한 유저의 보여주는 페이지가 다릅니다.

외부에서 주입시켜주는 데이터인가 내부에서 가지고 있는 데이터인가를 정리해야 합니다.

• 여기서 정의하는 내부는 Project 내 입니다.
• 여기서 정의하는 외부는 API, 3rd API 등 입니다.
• 내부와 외부를 가르는 중요한 포인트는 관리를 어디서 하느냐 입니다.
• 강의목록 API 에 대해서 이야기하면 강의목록 API 가 우리가 만들 웹사이트에서만 사용되는지 아니면 협력사나 어드민 페이지 등에서 사용되는지 판단해야합니다.

각 데이터의 관리주체가 어디인지를 정해서 개발 중에 각 관리주체와 협업합니다.

• RnR : Role & Responsibility 의 약자, 즉 어느 곳이 데이터의 관리주체인지 정리합니다.
• 그 외에 세세하게 더 나누면 MSA(Micro Serveice Architectures) 로 나눌 수 있습니다.

대부분의 경우에는 외부에서 가져오는 것이 더 많습니다.

• 예시, 마케터분들이 직접 카테고리, 메뉴를 수정합니다.
  • 어드민 도구가 있고 어드민 에서 사이트에 데이터를 내려주게 되면 외부에서 관리해야 합니다.
• 예시, 메뉴 API 를 카테고리 와 GNB(Global Navgation Bar)에서 사용합니다.
  • 메뉴 API 하나로 카테고리 와 GNB 데이터를 모두 사용하는 방법이 있고 메뉴 API 내에서 쿼리 파라미터를 사용하여 카테고리 API 와 GNB API 를 따로 나눌 수도 있습니다.

API 설계시 프론트엔드 개발자와 백엔드 개발자가 함께 설계하는 것이 좋습니다.

• 따라서 프론트엔드 개발자는 API 설계 를 어떤식으로 할지 판단하여 백엔드 개발자에게 요청하여 진행합니다.
• API 덩어리가 커지면 커질수록 프론트엔드 개발자는 더 편해집니다.
• 하지만 백엔드 개발자 입장에서 데이터 베이스 단일책임 원칙 이나 성능 면에서 API 를 여러개로 분기하여 관리하는 것이 더 좋습니다.
• 따라서 API 설계 할때 프론트엔드와 백엔드 개발자가 충분한 논의가 필요합니다.

웹사이트의 배너, 강의목록, 강의상세 또한 API가 필요합니다.

• 어드민 에서 관리해야하기 때문에 외부 데이터로써 관리합니다.
• 강의 API 가 따로 있더라도 강의 목록 API 와 강의상세 API 가 분리되어 있어야 불필요한 데이터를 추가로 가져오지 않도록 해야합니다.

메인 페이지 내 유튜브 태그가 포함된 설명 데이트 부분은 내부에서 관리해도 될 것 같습니다.

• 데이터가 자주 바뀔것 같지 않으면서 데이터를 바꿔달라는 요청이 왔을때 클라이언트에서 즉식 바꿔줄 수 있기 때문입니다.
• 추천 키워드 및 자주 바뀌지 않을 부분은 내부에서 관리할 수 있습니다.
• 필요시 후에 외부에서 관리하는 것으로 빼도 됩니다.

---

결론

API 설계시 백엔드 개발자와 프론트엔드 개발자가 함께 설계해야합니다.

MOCK API 를 만들어 준 후 백엔드 개발자에게 이런식으로 API를 만들어 달라고 요청하는 것도 좋습니다.

---