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