Nestia Guide Documents - Swagger to NestJS
swagger.json 파일 읽고 분석해서
NestJS 프로젝트 생성도 가능하고 (별로 안 중요)
E2E 테스트 프로그램도 자동으로 만들어주고 (그닥 안 중요)
SDK나 Mockup 시뮬레이터도 만들어주고 (이건 중요)
해주는 프로그램 만들었거든?
대충 위 용어 중 SDK는 API 스펙 따라 fetch 함수 모아둔거고
Mockup Simulator는 프론트에서 백엔드 API
목업 시뮬레이션 해 볼 수 있는 놈임 ㅇㅇ
각각 openapi generator나 msw와 비슷한데
그거보다 조금 더 편하고 더 자동화되었다고 이해하면 됨
그래도 이해 안가면 아래 링크 누르고 gif 짤이랑 예제코드 보면 됨 ㅇㅇ
- SDK: Nestia Guide Documents - SDK Library
- Mockup Simulator: Nestia Guide Documents - Mockup Simulator
그리고 이거 만든 김에 슬슬 주변에 권유를 해봤음
Swagger 파일 쑤시면 편리한거 빌드된다면서 권하는데
주변 지인들 회사 중에 swagger 빌드 불가능한 곳이 워낙 많아서 충격이더라
API 문서 노션/슬랙으로 공유하는 놈들은 양반이고
그마저도 없어서 즉석에서 야부리 기반 API 공유하는 애들도 있고 그러함
이게 누구나 이름만 들어도 알법한 그런 회사들조차
누군가가 DTO 대신 response 타입에 Map<string, Object> 박아버려서
스웨거 빌드 불가능한 곳도 그렇게 많더라
뭔가 조선 백엔드의 매운 맛을 본 거 같아서 씁쓸하더라
p.s) RestDoc 이거 뭐 테스트 짜는데 유리하고 나발이고
웨 API 문서 이딴거 의존해서 손으로 한땀 한땀 짜가며
만들어야 했는지 이해 못했는데 이번에 제대로 깨닫게 됨 ㄷㄷㄷ
삼촌 ㅎㅇ - dc App
노션 같은 걸로 공유하는게 양반이라니 ㄷㄷ
아가리 베이스드 API 썰 듣는게 개무섭다 진짜
블라인드 회사 리뷰 단점으로 “스웨거 같은 거 안 쓰고 위키로 api 공유하려는 사람 많음“ 쓰던 중이었음
엌ㅋㅋㅋㅋ
openapi generator 버그 많아서 ㅈ같음 - dc App
저거 돌려보고 버그 있으면 이슈 리포트 ㄳ
이렇게 스펙이 있고 스펙에서 출발하는 방식이 정확한 듯? 전 팀 팀장이 스웨거를 code-first로만 하려고 해서 극혐이었음.
스웨거 code-first는 뭔 뜻임?
java로 치면 annotation 달아서 swagger doc 만드는 방식
원래 그렇게 하지 않음? DTO랑 컨트롤러 API 딱 인터페이스 수준에서 정의하고, 그대로 swagger 빌드한 후 프론트/백엔드 각자 개발
전 팀은 백엔드 구현까지 끝낸 후에 프론트에게 공유하는 식으로 함. annotation 방식은 강제성이 없다보니(annotation 제대로 안 달아도 api 동작은 문제 없으니까) 누락되는 게 많아서 프론트 개발자들이 힘들어하더라 그런데 너희처럼 dto controller까지만 만들고 공유한 다음 백/프론트 각자 개발하면 이런 문제는 없긴하겠다
아 컴파일러에서 안 잡아주는구나... ㅇㅋ... 나도 이거 Node 진영 없어서 내가 걍 만듦
swagger 스펙 파일을 작성하든 너가 말한 방식으로 하든 본질은 api의 스펙을 명확히하는 것으로 출발하는 건데 전 팀은 너무 백엔드가 일방적으로 통보식으로 해서 나도 백엔드지만 불만이었음. 너가 말한 방법은 솔직히 생각 못했는데 좋은 거 같다. 근데 전 팀 팀장이 받아들이지는 않았을 듯? ㅋㅋㅋ
애초에 팀장이 swagger를 잘 못 이해한거고 팀원들은 다 그렇게 잘못 배운 거 같네
내가 팀장하겟다 이런거 안 됨? ㅋㅋㅋ
팀장이 도메인도르로는 ㅆㅅㅌㅊ여서 서비스 비즈니스 로직은 빠삭해서 회사 내 입지가 강력함. 객관적으로 인성도 괜찮고. 근데 기술적으로는 경력에 비해서는 굉장히 아쉽다
간만에 프갤에 어울리지않는 양질의 글이라 새롭네요..