BE와 FE의 API 동기화!(OpenAPI Generator) → 적용 안하기로..😥
OpenAPI Generator
OpenAPI Generator가 왜 필요한데?
기존 data fetching에는 2가지 문제점이 있다.
- API server에서 넘겨주는 값을 직접 swagger에서 확인해야함
- API가 변경되었을 때 FE에서 알지 못하면 둘 이 다른 데이터를 보고 있는다.
이 두가지 문제점은 높은 확률로 휴면오류를 야기한다.
이 문제점들은 BE에서 변경된 값을 FE에서도 동기화 해주면 해결할 수 있다.
이를 위해 바로 OpenAPI Generator를 도입을 고려해보기로 했다!
OpenAPI Generator가 뭐가 좋은데?
- OpenAPI Specification 기반의 문서만 잘 정의되어 있다면 따로 타입을 정의하거나 API 호출 코드를 작성하지 않아도된다. ( 생산성 증가 / 휴먼에러 감소 )
고민중…
이전에 graphql-codegen 라이브러리의 플러그인 중 graphql-codegen/typescript-react-query을 이용해서 TQ 훅을 자동 생성했던 경험이 있었어서 REST도 있지 않을까 찾아보니 TQ공식문서에서 나와있는 커뮤니티 프로젝트 중 Kubb 가 동일한 기능을 제공해준다!! 타입을 자동화하는 것은 너무 좋지만 다른 부분들은 조금 고민이 된다..
axios의 경우 현재response와request를 인터셉터하는instance를 만들어서 사용하려고 세팅을 하였는데 자동생성된 axios함수에 그냥 axios대신 커스텀한 instance로 변경 가능한지에 대한 우려- TQ 훅같은 경우 자동생성된 커스텀 훅을 보면 타입 지정, querykey, queryfn을 자동화 해서 훅을 만들어주는 것으로 확인!
axios 함수 자동화를 사용하지 않는다면 우리 코드로 queryfn을 넣을 수있도록 변경가능한지에 대한 우려⇒ axios 인스턴스를 직접 정의가능!- 자동화를 하지 않는다면 1줄이면 끝날 코드가 자동화를 위해 타입들과 옵셔널props들을 받으면서 너무 길어져서 가독성에 대한 우려
- 레퍼런스가 적어서 오류가 났을때 해결방법에 대한 우려
크게 이렇게 3가지의 고민들로 인해 도입 고민 중…
하지만 type은? res, req 타입 api 문서 보고 무지성 작성해야하잖아!
→ 이것만 자동화 하면되겠다!!
(우리는 Type만 쓰면 되지~)
고로 도입은 할 꺼지만 어디까지 자동화 할지는 좀 더 고민해보자!!
| 만약 type | type+axios만 자동화한다면 좀 더 성숙한 생태계를 가지고있는 openapi-generator 도입을 고려해보자! |
회의결과
리서치 결과 우리가 원하는 기능들은 커스텀해서 구현 할 수 있다. 하지만 문제가 되는 것은 번들 사이즈였다… 자동생성이다보니 중복되는 코드와 불필요한 속성에 대한 코드들이 같이 생성된다.
이는 bundle size를 증가시키고 퍼포먼스에 악영향을 줄 수 있다.
이를 최적화시키는 방법이 있긴하지만 이를 한달이라는 개발 기간 내에 이미 정해진 task를 하면서 완성시키기 어렵다는 결론이 나왔고 도입을 안하기로 했다ㅜㅜ
나중에 개인 프로젝트에서 최적화를 연습해본 후 다른 프로젝트에 도입해보자…!
댓글남기기