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를 하면서 완성시키기 어렵다는 결론이 나왔고 도입을 안하기로 했다ㅜㅜ
나중에 개인 프로젝트에서 최적화를 연습해본 후 다른 프로젝트에 도입해보자…!
댓글남기기