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