TL;DR
1. 추상화 수준을 어느 정도로 할 것인가?
- Ts기반이며, 추상화 수준을 낮게 가져간다 => tRPC
- 언어가 독립적이며, 추상화 수준을 낮게 가져간다 => gRPC
- 추상화 수준을 높게 가져간다 => Rest, GraphQL
2. Interface의 주도권을 누가 가질 것인가(client Or server)?
- client가 주도권을 가진다 => GraphQL
- server가 주도권을 가진다 => Rest(Code-gen, Type-sharing)
- 동등하게 주도권을 가진다 => Rest(ts-rest기반 zod계약)
3. 현재 상황과 기술적 특성을 고려했는가?
- 팀의 러닝 커브, 마이그레이션 여부
- 프로젝트 구조 (MonoRepo, MultiRepo, Stack..)
- Caching, Auth, Performance..
- 데이터 표현력 (Method, Data-relation..)
웹 프로젝트에서 생산성을 위한 고민
뽀모도로를 이용해서, 일과를 진행하고 있다.
그래서 주간별로 내가 어떤 업무에 얼마나 시간을 썼는지를 추적해 봤다.
비 효율적이게 일하는 부분이 꽤나 많았다.
그중에서도 API가 쓸데없이 시간을 너무 잡아먹고 있었다.
Document보다 Code-first
OpenAPI스펙으로, code를 생성해 주는 것들이 많다.
Swagger를 쉽게 생성해주는 것들이 많으므로 이들을 조합해서 해결할 수도 있다.
우리 팀은 이미 Ts로 스택을 단일화했다.
굳이 code-generator를 거쳐야 할까? 라는 생각이 들었다.
13. 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
15. DRY: 반복하지 말라.
37. 계약으로 설계하라.
- 실용주의 프로그래머, 데이비드 토머스
누군가가 Type을 만들고, Type-sharing으로 작업을 한다면
효율적일 것이라 생각했고 위의 조언들이 떠올랐다.
전략 단순하게 비교하기
Restful Vs. GraphQL Vs. RPC
RPC는 추상화 수준이 나머지 보다 낮다. (Remote Procedure Call)
gRPC를 사용하여 언어 독립적으로 통신할 수도 있고,
tRPC를 사용하여 Ts기반의 단순한 서버 요청을 수행할 수도 있다.
추상화 수준이 낮아도 되면 tRPC.
gRPC를 쓰면 언어 독립적으로 RPC통신을 할 수 있다.
MSA구조, 언어 다양성, 저비용 통신이 필요하다면 gRPC.
Rest Vs. GraphQL
Restful는 단순하다는 점이 장점이자 단점이다.
쉽고, 명확하지만 client의 표현력이 다소 부족하다.
client가 interface를 주도한다면 GraphQL.
그 외에는 Rest.
(Restful) CodeGen Vs. TypeSharing
client & server의 언어가 다르다면 무조건 CodeGen.
언어가 같을 때, interface의 주도권을 동등하게 가져간다면 ts-rest.
interface의 주도권을 server가 가져간다면 DTO-sharing.
추가로 고려해야 할 많은 것들.
위에서는 극단적으로 단순하게 고려했지만, 실제는 더 복잡하다.
제삼자와도 통신을 해야 한다면 RPC의 난이도는 상승한다.
Server의 퍼포먼스가 부족하다면 GraphQL의 난이도는 상승한다.
데이터의 관계가 복잡하다면 Rest의 난이도는 상승한다.
멀티레포라면 (Rest) TypeSharing의 난이도는 상승한다.
팀이 써본 적이 없는 기술의 난이도는 상승한다.
코드를 못 읽는 팀원이 있으면 CodeFirst의 난이도는 상승한다.
이해관계자들이 어떻게 얽혀있느냐에 따라
장단점은 더욱 세분화 될 것이므로, 최선의 선택을 내리지 못할 수도 있다.
그리고 이분법적으로 쓰냐, 마냐의 문제가 아니라
어떤 조합을 어떻게 배분할 것이냐의 선택이 될 수도 있다.
은탄환은 없다.
여러 상황을 고려한 유연한 사고.
어떤 상황에 어떤 기술이 적절할지 고민하고, 테스트하자!
'프로젝트 > 1. EggERP' 카테고리의 다른 글
| 팀 생산성을 위한 MonoRepo (0) | 2025.03.15 |
|---|---|
| 실용주의 Agile 도입기 (0) | 2025.03.06 |