안녕하세요? 코드를 보니 이건 Server, Client가 같은 repo에 존재하는 mono repo를 기본적으로 취하고 있는 것 같습니다. 이렇게 사용할 때는 매우 좋은 라이브러리 인 것 같습니다. 하지만 backend, frontend가 완전 분리된 경우에는 이를 어떻게 사용해야 할까요? shared kernel 형태로 route를 공유해야 할까요? 아니면 git의 sub module 형태로 가야 할까요? Server, Client가 완전 분리되어 개발이 진행되는 경우는 좀 더 많은 고려가 필요할 것 같습니다. 혹시 이에 대해서 어떻게 생각하시나요?
글쎄요.. 묘비로 갔다기에는 개발팀 사정에 따라 다를 거 같네요. 백엔드가 spring 디폴트인 한국 개발 환경에서 앞으로도 REST와 GraphQL은 많이 쓸모 있을 거 같습니다. 스타트업 초창기 씬에서는 풀스텍 개발자 고용해서 tRPC 쓰거나 Next에서 직접 DB 쿼리하는 경우가 있을 거 같지만요. 백엔드 개발팀이 다른 언어를 사용하고 있는데, GraphQL을 사용하기 부담스럽다면 OpenAPI를 활용보는 것도 좋을 것 같습니다.
IDE 자동완성, 폭포수처럼 떨어지는 체이닝.. 말다했다 이건 그냥 최고다. 하지만 초기 아이디어 가디고 일단 빨리 해볼때나 좋을듯. GraphQL이 가지는 Overfetching, Underfetching 문제 해결 및 유연성, 무한한 resolver 활용성 등 생각하면 장단점이 명확할듯.
개인적으로 최근 새로 시작하는 프로젝트에 도입을 고려했었는데 실제 프로덕션에는 어떤식으로 배포되어야 하는지 감이 안잡혀서 포기했던 경험이 있는데요, 서버와 클라이언트가 각각 별도의 애플리케이션으로 배포되어야 하는 케이스에서 Router 타입을 공유할 수 있도록 할 수 있는 방법을 딱히 찾지 못해서, trpc는 TS 단일 풀스택 환경으로 구성된 프로젝트에서 사용하기 적합한게 아닌가 결론짓게 되었습니다. 회사 업무보다는 나중에 개인적으로 소규모의 토이 프로젝트를 진행하게 된다면 적용을 고민해볼만 하겠다 정도의 생각도 해볼 수 있었습니다.
📌 직접 만들면서 코딩 배우기 (*무료*)
👉🏻 bit.ly/46W9XVC
.
🔥 풀스택 GPT (2024 최신 버전) 🔥
bit.ly/3VhITwB
.
🔥 NextJS 14 시작하기 (무료) 🔥
bit.ly/4cCtQnE
.
🔥 당근마켓 클론코딩 (2024 최신 버전) 🔥
bit.ly/4aaaZyK
T3 스택이라는걸 사용하면 간단하게 Nextjs + Typescript + Tailwind 셋업 할 수 있어요! 개인 프로젝트 할때 써봤는데 개발속도 엄청 빠르더라고요!
니꼬쌤님 최신 기술 동향 매번 감사해요.
저도 감사드립니다!!
니꼬쌤 혹시 여러 개발용어를 알려주는 영상은 어떠신가요? 개발을 시작하는 사람들에게 많은 도움이 될 것 같습니다!
graphQL 안하길 잘했다(?)
맛만 보길 잘했다
안녕하세요? 코드를 보니 이건 Server, Client가 같은 repo에 존재하는 mono repo를 기본적으로 취하고 있는 것 같습니다. 이렇게 사용할 때는 매우 좋은 라이브러리 인 것 같습니다. 하지만 backend, frontend가 완전 분리된 경우에는 이를 어떻게 사용해야 할까요? shared kernel 형태로 route를 공유해야 할까요? 아니면 git의 sub module 형태로 가야 할까요? Server, Client가 완전 분리되어 개발이 진행되는 경우는 좀 더 많은 고려가 필요할 것 같습니다. 혹시 이에 대해서 어떻게 생각하시나요?
그런 경우 타입만 분리해서 npm 패키지로 관리할 수 있을 것 같습니다. 다만 이를 위해 배포 자동화를 해야하니 좀 번거로울 것 같긴 합니다.
Trpc의 장단점 영상도 있으면 좋을 것 같습니다~😊
풀스택 개발자가 되기 위한 아주 좋은 API 생성 도구를 발견한 것 같아요!
좋은 말씀 감사합니다!
좋은 영상 감사합니다~ 😀
Few years later...Why I don't use tRPC begins!
타입스크립트로 서버를 두는게 아니면 사용이 어렵고 다른 언어로 구현된 모듈이 나온다고 하면 결국 코드 생성을 거쳐야하고 그럴거면 차라리 graphql을..
언어 종속성이 생긴다면 좋은 솔루션이라 보긴힘들죠
요새는 딸깍으로 crud api는 기본에 join까지 최소성능손해로 딸깍으로 되는게 나와가지고ㅋㅋ
한 5년기다려야죠 생산성이 나오기까지..
조그만 서비스에는 유연하게 붙일 수 있을 거같아서 좋아보이더라구요
대박이네용 ..
그러게요 요즘시대엔 graphQL 이 꺼려지는 이유죠
나온지얼마나됏다고 다운트렌드인가..
nuxt3는 이전부터 server directory를 통해서 tRPC와 같은 기능을 제공하고 있습니다.
핵심은 라우팅이 아니라 유형오류를 방지해 준다는 것 아닌가요? 아니면 내가 모르는 뭔가가 있나?
서로 영향 받으며 발전하는 거죠. 문제는 이런 기능이 마치 자기것인 마냥 같잖은 이름 붙여서 도둑질을 한다는 것입니다. tRPC가 그 예이죠.
실버불릿은 없다. 항상 명심할것
작용이 있으면 반작용이 있다.
님 문과죠? @@junghwanhwang4299
글쎄요.. 묘비로 갔다기에는 개발팀 사정에 따라 다를 거 같네요.
백엔드가 spring 디폴트인 한국 개발 환경에서 앞으로도 REST와 GraphQL은 많이 쓸모 있을 거 같습니다. 스타트업 초창기 씬에서는 풀스텍 개발자 고용해서 tRPC 쓰거나 Next에서 직접 DB 쿼리하는 경우가 있을 거 같지만요.
백엔드 개발팀이 다른 언어를 사용하고 있는데, GraphQL을 사용하기 부담스럽다면 OpenAPI를 활용보는 것도 좋을 것 같습니다.
2025년 nico : I never go back to trpc graphgl rest api and i use xxx. But I really like noko and rhis channel
naver
@@shadow-song Thanks, I edited
요즘 자체 프레임워크와 개발언어를 개발중입니다. 결국 사용할 프로젝트에 최적화 될 수 밖에 없고, 범용으로 개조시에 어느정도의 트레이드오프는 필연적이게 되더군요.
대단해요.
grpc라는 이미 좋은 프레임워크가 있는데 굳이 trpc...?
grpc, nuxt3의 server directory등 trpc보다 더 먼저 나왔거나 안정화되어 실사용까지 되는 기술들을 두고 굳이 trpc만 저렇게 띄우는 썸네일은 너무 어그로... 니꼬야 혹시 신규강좌 런칭임?
IDE 자동완성, 폭포수처럼 떨어지는 체이닝.. 말다했다 이건 그냥 최고다. 하지만 초기 아이디어 가디고 일단 빨리 해볼때나 좋을듯. GraphQL이 가지는 Overfetching, Underfetching 문제 해결 및 유연성, 무한한 resolver 활용성 등 생각하면 장단점이 명확할듯.
니코쌤 unjs에 대해서도 한번 다뤄주시겠습니까
감사히 보겠습니다🙂↕️
저도 감사합니다!
이런게 있었구만 신기하네
모노 레포에 대한 영상도 만들어주세요
개인적으로 최근 새로 시작하는 프로젝트에 도입을 고려했었는데 실제 프로덕션에는 어떤식으로 배포되어야 하는지 감이 안잡혀서 포기했던 경험이 있는데요,
서버와 클라이언트가 각각 별도의 애플리케이션으로 배포되어야 하는 케이스에서 Router 타입을 공유할 수 있도록 할 수 있는 방법을 딱히 찾지 못해서, trpc는 TS 단일 풀스택 환경으로 구성된 프로젝트에서 사용하기 적합한게 아닌가 결론짓게 되었습니다.
회사 업무보다는 나중에 개인적으로 소규모의 토이 프로젝트를 진행하게 된다면 적용을 고민해볼만 하겠다 정도의 생각도 해볼 수 있었습니다.
trpc 서버 주소를 클라이언트에 제공하면 자동으로 타입지원이 되는게 아닌가요?
모노레포 구조로 레포를 관리하시면 될 것 같습니다. 별개의 레포를 가져가는 구조에서는 타입만 따로 뽑아 쓰면 되겠지만, tRPC 특유의(?) 장점이 많이 희석되겠지요...
백프 팀다르게 별개로작업하는데 레포하나쓰는겓 쉽지않을듯
깃헙 같은 사내레포에서 직접 실시간 다운 받아 업데이트해가면 좋을듯 타입 파일만
관련된 보안문제는 없을까요~?
trpc 들어가있는 T3 stack도 맛봐주세요 니꼬쌤😂
Already uploaded? Thought no videos for a while!
아니 형 ㅋㅋㅋ 나 형이 올린 Graphql강의 열심히 듣고 있는데 빨간약을 먹어버렸어
혹시 사용한 브금이 뭔지 알 수 있을까요?
흠~ 뭔가 혼자 하기엔 나쁘지 않은데
query 나 mutation 안에 db 쿼리를 따로 적는 것도 그렇고, 안정성을 위해서 단계를 하나 늘리는건데,
개인적으로 타입안정성에 대한 장점이 크게 다가오진 않네용
양질의 뉴스 감사합니다
요즘 HL7 FHIR를 활용해서 병원쪽 시스템 구축을 하고 있는데 RESTful하게 구축하는게 너무 어려웠는데 이런 방식을 쓸 수 있다면 정말 좋을꺼 같지만 고객이 FHIR를 RESTful하게 해주는걸 요구해서 ㅠㅠㅠ
도메인을 확인 할수 없기에 이것 또한 관짝으로 가야함 결국 모든것의 완결점은 이미 수십년전에 만든 XML
What is difference between gRPC and tRPC?
I usually use gRPC in my MSA repository and tRPC makes me interesting ...
같은 RPC기반의 통신입니다. gRPC 는 google 사에서 만든것입니다.
The name 'procedure' brings me PTSD when I used to work in company use 'Stored-Procedrue' to handle domain logics...
tRPC는 타입스크립트 환경에서만 쓸 수 있는게 단점인거 같네
유일한 진실) 이 hype이 실무에서 실제로 유용하든 아니든 강렬한 어그로썸네일과 함께 조회수는 올라간다
Elysia 한접시...
Http아님?
아 솔직히 새로운거 너무 마니 나온다.. 백엔드 자바스크립트로 짜는거 자체가 에바임
모노레포 필수로 써야되나여?
정답! 안하면 된다
왤케 불편해ㅋㅋ
음... 그닥... 매력적이지 않네요.
마이크로 서비스에서 dto를 패키지로 따로 빼서 전체 배포하면 tRPC와 기능이 100% 똑같아 보이거든요.
그냥 자바스크립트 버전의 rpc네. 저렇게 개발하면 개발속도는 엄청 빠르겠지만 반대로 restful api원칙이 무너지기 쉬움. ajax가 보편화 되기 이전의 웹 개발은 command 패턴을 적용한 프레임워크를 직접 짜서 저런식으로 call 하는 경우가 많았음.