You won't use REST after this!

당신의 선택은?
GraphQL 기본개념, 탄생 배경 10분 정리...! REST API 와의 비교까지!
#GraphQL #REST #그래프큐엘 #프로그래밍 #코딩
-
📌 무료 GraphQL 기초 강의는 요기 👇🏼
bit.ly/3l9tn2Q

[@nomadcoders]

📌 무료 GraphQL 기초 강의는 요기 👇🏼 bit.ly/3l9tn2Q

[@user-ju3tq7wq1t]

graphql을 뭘봐도 이해히지못했었는데 이 영상으로 너무 잘 이해되었네요!!! 역시 니꼴라스입니다~!!! 강의도 꼭 들어볼게요!!!

[@user-iq7bc4pk4q]

한글자막을 잘 달아주셔서 넘나 보기 편했어요. 좋은 영상 감사합니다.

[@GlobalYoung7]

감사합니다. 노마드 코더 니콜라스 선생님 덕에 코딩에 입문해서 아직까지 도움 받고 있는 1 인 입니다. ㅎㅎㅎ 언제나 최고 👍

[@user-ur8ne5jb5g]

오... 덕분에 그래프 큐엘을 더더욱 봐야겠다고 생각이 드네요 감사합니다

[@tangO_Ov]

graphql이란걸 들어만 봤는데 알기쉽게 설명해주셔서 고맙습니다ㅎㅎ

[@paolovalmori7184]

I've watched many of your videos lately Nick, I'm so glad you've come so far, totally deserved! Keep it up, cheers from Italy :)

[@nomadcoders]

thank you for the support! really appreciated!

[@KSY3215_A]

거의 1년 째 구독 중입니다. 영상 너무 잘 보고 있어요.

[@xxxxxx542]

Very clear explanation! .. Thank you 👍👍👍👍

[@yoman9446]

You're an amazing teacher! This video was very detailed, thank you

[@nomadcoders]

thank you for the support! really appreciated!

[@user-cw6fu2qx8p]

영상 잘봤습니다ㅎㅎ 역시 니꼬 영상이 이해가 제일 잘되네요!! 혹시나 생각이 있으시다면 graphql 을 이용하는 프레임워크 중 하나인 relay에 대해서도 설명해주시면 감사하겠습니다ㅠㅎㅎ 늘 화이팅입니다~

[@shobitdeshwal2962]

Thanks, well explained ♥

[@yjkim1243]

와... 그 동안 헷깔렸던 개념이었는데 명확해지네요.

[@user-vf1tj3vg6s]

그 동안->그동안

[@MushroomVillain]

코딩 배우기 전엔 몰랐는데 코딩 배우고 나니까 형이 신처럼 보여

[@mygakuku]

graphQL강의가 새로 업데이트 되었군요. 예전에 수강했는데 좋은 내용이었습니다. graphQL공부하시는 분들께 도움이 많이 되리라 생각됩니다. 개인적으로는 이 강의에서 Subscription 도 다뤄주었으면 하는 바램이 있습니다.

[@kookbrown]

개념이해에 정말 좋아요~ 감사합니다. 비록 언제 깊이있게 공부할지는 모르겠지만;;;;

[@user-lg4ot9hx5f]

굿굿!!!!

[@woo2653]

오 graphQL 짱이네요!!

[@oxygen2236]

GraphQL을 하고나서 느낀점은... 마법은 없다는것. 마법처럼 보이는 모든것을 개발자가 코딩해 줘야한다는것. 결국 "이 프로젝트는 GraphQL이 아니면 안되겠네"라는 프로젝트가 아닌 이상은 그냥 REST API가 최고다.

[@user-bp4yo1on5e]

공감합니다. 그래프 큐엘은 api 문서도 따로 만들어줘야 합니다..

[@mojomoth]

저도 공감합니다

[@user-nu7bg3nq3v]

같은 생각을 접하니 좋네요

[@fang3131]

REST 도 팀이 사용하려면 문서 만들어야 하지 않나요? 문서를 강제하는게 장점이라고 생각합니다.

[@ryan_dev7560]

@@fang3131 swagger 짱

[@user-bc6wr5kt2q]

마침 새 서버 프로젝트를 진행 중인데 NestJS 기반으로 prisma, graphql을 적용해서 프로토 타입을 구현했습니다. 개인적으로 기존 rest api를 사용하는 것보다 간단 명료하고 직관적인 점이 마음에 들었네요 :) 아마 제가 진행하는 프로젝트가 완전히 새로 구현하는 프로젝트라 다른 분들이 겪으시는 레거시 문제가 없어서 좋은 인상이 큰 것 같아요. 새로운 기술을 익히고 적용하는 일은 언제나 즐겁네요ㅎㅎ 영상 늘 잘 보고 있고 정말 많은 도움을 받고 있습니다!

[@ahnistyle]

죄다 도입하고 싶었던 것들인데, 개발자를 못찾아 드롭한 실패자로써 한국은 틀렸다고만 생각했는데, 세상은 넒군요.

[@user-bc6wr5kt2q]

@@ahnistyle 회사가 IT 전문이 아닌데다가 새 프로젝트다보니 후다닥 밀어붙인 면이 있습니다 :D 한국도 쓰던거만 쓰지말고 다양해졌으면 좋겠어요!

[@user-wf2cj5xt7p]

사내 인트라넷에 살포시 적용해봐야겠어요. 감사합니다.

[@green__apple]

rest api로만 만들어 봤었는데 다음플젝을 만들땐 graphql을 배워서 사용해봐야겠네요! 무료강의 감사합니다!!

[@neodahl5898]

진짜 이 형은 신인가

[@ekka_in_the_mask]

내용은 보는 중인데... 제목이 무지 자극적이네요. ㅎㅎㅎ --- 오... graphql... 써봐야겠네요.

[@jetbrains141]

실제 사내에서 사용하게된다면 rest, graphql 을 알맞게 섞어쓰게됩니다 일반 서비스에서는 rest api 가 유지보수하기에도 쉽고 구조잡기에도 쉽지만 사내 오픈API 와 같이 클라에서 어떠한 값을 조회할 지 모르는경우 graphql 을 쓰기도 하죠 특히 CUD 영역은 graphql 로 할 경우 하나의 엔드포인트에 수많은 CUD 가 모이게되어 관리에 매우큰 골치거리가 되었습니다 언제나 생각드는건 기술이 문제가 아니라, 기술을 사용하는 사람이 문제라는걸 깨닫게되죠

[@user-vf1tj3vg6s]

할 지->할지 골치거리->골칫거리

[@sujeonglim9340]

짱 좋네..

[@koreateam9447]

유튜브 항상 잘 보고 있습니다😁 최근에 MEV에 관심이 생겨서 arbitrage bot을 만들어보고 싶은 생각이 들어, 코딩 배우려고 합니다. solidity는 기본이고.. 혹시 또 어떤 언어를 같이 배우면 좋을까요? 코딩에 대한 지식이 0이라 잘 모르겠네요. 지금은 solidity 맨땅에 헤딩식으로 공부하고 있습니다

[@ding-co8036]

Thank you

[@user-pp8rj6ny3p]

그래프큐엘을 말로만 들어만 봤을뿐 이 영상을 보고 그래프큐엘이 무엇인지 이해했습니다.

[@user-vw2ph3xr7b]

딴 얘기인데 GraphQL 로고를 너무 이쁘게 잘만든듯..ㅋㅋㅋ 리액트보다 더 이쁨

[@user-gtd35hgt787]

헐.. 대박👍. 김치찌개 김치볶음밥 김치전 감사합니다.

[@KIMDDUSHI]

다음 프로젝트는 이걸로 해봐야겠네

[@unfortunately816]

love you bro

[@TV-cb6lu]

결국 rest는 서버사이드에 맞추어 프론트에서 개발해야하는거고 graphql은 프론트가 개발하기 편하게 마치 디비 select 하는 것마냥 쉽게 쓰고싶다 이거군요. 클라이언트, 서버 개발간의 많은 의사소통이 필요해보이는건 동일해보이구요. 단순한 구조에서는 rest보다 나은점이 많겠지만 트위터나 무비 프로그램에서 든 간단한 예로는 모든 어플리케이션 환경에서 마법같다는 표현은 할 수 없을 것 같아요 ㅎㅎ

[@fang3131]

GraphQL 서버를 DB 접근권한 관리 서버처럼 사용하면 서버개발자가 따로 없이 개발할 때 상당히 편리합니다. GraphQL 쓰면 서버개발자가 프론트 요청으로 API를 만드는 업무를 상당히 줄일 수 있기 때문입니다. API를 DB를 그대로 불러올 수 있게 만들어두면(프리즈마 등 많은 라이브러리에서 자동으로 코드 생성해줍니다) 프론트에서 쿼리 만들듯이 알아서 불필요한 요소를 빼고 쓸 수 있고 굳이 리졸버 안 만들어도 클라이언트에서 계산해서 쓰면 됩니다. 언더페치를 해결하는 건 서버 개발자가 리졸버를 만들어야 해서 REST보다 좋은 지 잘 모르겠지만(게다가 컴포넌트 디자인의 프레임워크를 쓰면 언더페치 문제는 어찌할 수가 없습니다. 캐시지원하는 라이브러리 써서 똑같은 쿼리 두 번 날리지 않으면 충분합니다.) 오버페치를 해결하는 건 확실히 도움이 됩니다. 이렇게 쓰면 클라이언트 변경으로 필요한 쿼리가 계속 바뀌어도 REST API 버전 올려가면서 대응하지 않아도 됩니다. 클라이언트에서 요구하는게 계속 바뀌는데 API 버전 관리 때문에 제대로 대응 못하는 경우가 REST에서 생각보다 많습니다. 이 개념이 발전하면 BaaS가 되는데 그래서 BaaS에서 상대적으로 graphql을 많이 지원하는 것으로 알고 있습니다. 아니면 프론트 언어 별로 다 라이브러리 만들어줘야 하니까요.

[@user-fi8tm4cb4b]

@@fang3131 s

[@alexhan4489]

@@fang3131 거대한 편리함엔 거대한 책임이 따르는 법

[@david-ji8tw]

@@alexhan4489 레알 내가 담당하는 프로젝트 예산 규모가 커지면 편리만 추구하기엔 리스크가 커짐.

[@mojomoth]

Graphql도 써보고 REST API도많이 썼는데 graphql은 높은 커뮤니케이션 비용과 코드 복잡도가 높아서 결국 안쓰게됐습니다. 차라리 gRPC또는 subsribe하는 observe패턴 개발이 낫더라구요

[@tonyjin4771]

모든 기술이 장단점이 있어요. 가장 아쉬운 점은 사람들이 트렌드라고 하면, 우르르 몰려 사용하는데, 써보고 후회 하는 경험도 좋은데, 그 전에 자신의 팀이 어떻게 설계되어있고, 왜 그렇게 만들었는지 확인 후에 새로운 기술에 관심 가졌으면 합니다. 신기술의 접목은 자칫하면 사탕 발림 정도로만 갈 수 있어요. 쿨 해 보이는데, 로직 보면 굳이 바꿀 필요가 없었다면 시간 낭비가 될 수도 있고요.

[@cyrusgracias4556]

It still depends on implementation right In react project my one component could ask for upcoming movies and other would ask for recently released Still resulting in 2 api calls

[@keikim7341]

Rest graphql 섞어서 쓰십시오 최곱니다

[@sungjuyea4627]

graphql 좋긴 한데 아직도 러닝커브가 좀 빡세기도 하고 유지보수가 힘든게 단점인거 같습니다 아무래도 성능튜닝이 중요한 대기업에서 하는 서비스가 아닌 이상 개인이나 중소기업에서는 rest로 하는게 확실히 편한거 같아요 ㅎㅎ ㅜ

[@xoutaku7600]

nice >puts in the never ending to do list

[@jcmh74]

저도 평소 RestAPI에 불만이 많았습니다. 즉시 강의 등록했습니다. 감사합니다.

[@this4134]

믿고보는 노마드코더

[@user-us4jk7yh2x]

그래프큐엘 짱!

[@user-yn5bz5fz1b]

hasura라는 graphql 엔진도 써보시면 좋아요:)

[@user-vb5dw5ev7b]

Cool

[@Lucid-xg6ur]

니코쌤 오늘도 잘 보고 갑니다! 그런데 질문이 있어요. 영상에서는 GraphQL의 등장 배경과 함께 Over/Under Fetching을 해결할 수 있다 설명해 주셨는데, 반대로 GraphQL을 사용했을 때 발생할 수 있는, 혹은 해결하기 어려운 단점들은 없나용? 그리고 Under Fetching의 경우는 뭔가 상황에 따라 REST API가 더 좋아보이기도 하네요. 프로젝트에 적용해 보셨거나, 시도해 보셨는데 불편함이 있으셨던 분들의 의견은 어떠신지 궁금해요.

[@semteul]

제 경험을 공유드리자면 사용가능한 타입에 제한이 있는것은 json string을 쓰던지 해서 해결했었지만, 파일 업로드만큼은 GraphQL로 처리하기 까다로워서 (GraphQL은 공식적으로 직렬화된 데이터만 허용합니다. 이 때문에 Base64 같은 해괴한 방법으로 업로드 하는 방법도 있고, 아예 프로토콜 자체를 개조해서 뒤에 버퍼를 붙이는 비공식 방법도 봤지만... 이런 방법은 별로 추천하고 싶지 않습니다) -> 결국 정석적인 multipart REST + GraphQL을 동시에 관리하다보니 복잡성 증가되어서 힘들었고 한번 오류가 발생하면 디버깅하는 것에만 시간을 몇배로 쏟아야 하는 상황이 자주 발생했습니다 (제일 좋은건 AWS S3 같은 외부 서비스를 이용하는거라고 생각합니다) 제가 주로 처리한 프로젝트에서는 리엑트와 같은 프레임워크를 사용하면 각 컴포넌트에서 직접 fetch 하는 경우가 많았는데 이 경우 under fetch에 강한 GraphQL의 장점이 많이 퇴색되었습니다 (페이지마다 최대한 적은수의 쿼리를 날리기 위해선 페이지 최상단에서 필요한 정보를 한번에 쿼리해야하는데 이렇게 하는것이 제 경우에는 유지보수성을 오히려 해친다는 생각이 들었습니다)

[@pepsiguy706]

제 개인적으론 대부분의 경우 graphql의 장점인 특정필드만 가져와야 하는 경우가 적었습니다. 대부분의 페이지에서 쓰는 필드의 수는 거의 비슷했으며, 그조차도 rest api의 경우 ?range={value} 파라메터로 등으로 처리할 수 있었던 부분이었습니다. 그렇다면 파라메터 자체를 외워야하는거 아니냐? 라고 생각하실 수 있지만, graphql에서도 백엔드의 특정 필드이름을 알아야 했던 점을 생각하면, 큰 문제점이 아니였던 것 같습니다. 이런 전체적인 점들을 고려했을 때, "닭잡는데 소잡는 칼"이라는 느낌이었습니다.

[@Lucid-xg6ur]

소중한 경험 공유해 주셔서 감사합니다!

[@user-vf1cu9dc2k]

특정 a라는 필드안에 제이슨 형태로 다양한 내장 필드가 존재했을때 a라는 필드안에 추가적으로 더 필드가 추가되면 그것을 호출하기 위해선 쿼리문을 재 작성해야한다는 것도 불편하더라구요 a필드 안에 뭐가 추가되든 다 가지고오고 싶은데 말이죠 .. 따로 프레그먼트로 선언해도 계속 추가될때마다 고쳐야하고..

[@user-vf1tj3vg6s]

@@semteul 던지->든지

[@mangchi-the-cat]

gql의 mutation은 생각보다 별로다라구요. nestjs 기반 개발 경험상 typeorm 이나 cms rest api 조합으로 쓰는게 더 개발하는게 빠름..

[@crispy6047]

grpc 가 궁금하네요 그래프큐엘을 사용해보니 생각보다 매직은 아니었어요 오히려 더 손이가는 경우도 있고요

[@uuutttuuubbbee]

Hey Nicholas. Can u make a vid about Bytesafe?

[@only5409]

신기하다

[@devjung_jay]

필요한 곳에만 쓰는 게 아직은 제일 효과적인듯…

[@keikim7341]

그리고 graphql은 게이트웨이 형식의 msa에서 큰힘을 발휘합니다 영세한 모노서버에서는 그냥 http api 쓰는게 ... 일만 늘어나니까요

[@redarishem]

You 👍 👍 👍 👍 👍 👍

[@yyy912]

개인적으로 apollo서버로 구축하면 플레이그라운드가 진짜 잘돼있어서 너무 편한 기억이...

[@42_cloud]

특정 상황에서는 좋은느낌

[@user-ox7zq8oe2p]

underscope 같은 경우는 API 설계를 영상의 예시처럼 하면 되지 않을까.. 🤔

[@hey1829]

뒤에 배경 집이에요? 개좋네요

[@leesang627]

GraphQL은 스키마 따로 관리해주고 typegen같은 게 필요하다는 거 때문에 안 쓰고 싶어집니다. ㅠ 약간 깔끔한 느낌이 떨어진다고 해야 하나

[@daenlevel2823]

항상 마무리 멘트에 김치는 왜 넣는걸까 ㅋㅋㅋ 영상이 매콤하군

[@ss-mc4lg]

그래프큐엘말고 프리즈마를 쓰면 원하는 데이터를 가져올 수 있던데 프리즈마쓰면 그래프큐엘은 안써도 되나요?

[@zestyxz]

음... 뭐랄까 풀스택으로서 단편적인 생각입니다만 이런걸 굳이? 라는 생각이 들긴 합니다. 써보면 생각이 달라지긴 할거 같기도 하지만 일단은 그렇습니다.

[@semteul]

REST API로 다시 돌아가게 된 결정적 계기가 파일 핸들링 문제점 때문이였는데 이부분은 요즘은 어떻게 해결하는지 궁금하네요

[@jkijljbnj7165]

이 문제는 REST 같이 쓰는 수밖에 없는 것으로 아네요

[@jongmin0328]

@@jkijljbnj7165 graphql-upload 라이브러리 쓰시면 REST 없이도 파일 업로드 구현 가능합니다.

[@jkijljbnj7165]

@@jongmin0328 과거에 써봤다가 문제 생겨서 다시 돌아온 경험이 있네요. 아무래도 써드파티라 불안하더군여.

[@user-vf1tj3vg6s]

이였->이었

[@user-sn7pm7ji9d]

프론트를 위한 프록시 서버로써 사용하기에는 나쁘지 않을 것 같습니다. 여러 마이크로서비스는 rest로 구축하되 프론트의 요구사항에 따른 데이터 취합을 graphql로 구현한다는 느낌입니다.

[@kjl7316]

저는 graphql을 잘 몰라서 이 영상에서 알려준 rest api의 두가지 문제(overfetching, underfetching) 관점에서만 보면 말씀하신게 의미가 별로 없지 않을까요? bff에서 graphql로 제공해봤자, 뒷단 마이크로 서비스들에 rest로 조회를 해오면 영상에서 언급된 두가지 문제는 여전할 것 같다는 생각이 들어서요!

[@jalfredprufrock620]

api gateway pattern

[@firstlast8035]

제목 그대로네요 진짜 REST 쓰기 싫어질 듯

[@sammashu]

i stumble this video great video by the way but i don't agree to move away from normal REST API i would still use REST over GraphQL simply of the follow reasons : 1- GraphQL give way to much freedom to users people would just make complex query if not having expert to design it correctly 2- GraphQL make tasks Complex with all the Types, Queries, Mutators, Resolvers... imagine how you gonna maintain that in high architecture 3- How will you cache a single enpoint if one endpoint would hold all your traffic ? The goal is to reduce heacy cpu lifting on the server and cost

[@danielbathke]

1- The query isn't a real database query, is just a way to filter the data you want, so users don't benefit too much in making complex queries. 2- It's an implicit schema registry or model for you. 3- Client-side js libraries can cache your query results, and server-side can cache resolver results (see AWS AppSync for instance). But all and all, I agree that as great as it looks, we shouldn't simply assume it as a silver bullet and use it for all cases (as any other architectural and technological decisions).

[@trustytech]

서버 개발 / 웹개발로 개발 파트가 정해서 사람이 나뉘어 있으면 사실 적용하기가 어렵죠. 웹하시는분이 따로 서버 구성해서 쓰거나 해야해서 데이터량이 많지 않다면 일만 더 늘것으로 보입니다.

[@OM-bs7of]

You can just provide the fields as parameters you want to be returned in the response to a REST API so graphql didn't solve anything... It just made things more complicated.

[@amkorousagi]

사실 동영상에서 말한 모든 문제는 url뒤 쿼리를 더 자세히 붙히면 해결할수 있는데 그래프 ql은 그런게 미리되어 있나보네 일종의 쿼리 빌더 같은 느낌인등

[@user-vf1tj3vg6s]

붙히->붙이

[@andrewc8125]

GraphQL은 cRud에 좋고 Rest는 CrUD에 좋다고 하는데 혹시 insight 좀 가지고 있으신 분 있으신가요?

[@galaxykim8385]

급 질문이 있습니다. 1. 백엔드 개발자가 엔드포인트를 새로 만들고, 언더페칭/오버페칭이 안나도록 쿼리문을 잘 짜면 되는거 아닌가요? (공격하는게 아니라, 순수한 궁금증 입니다. 소위말하는 한방쿼리 신공이면 해결되지 않을까? 궁금하네여) 2. 그래프큐엘도 뎁스가 커지면 DB에 부하가 많이 간다고 들었습니다만... 니코쌤 우버강의는 그런것의 대처가 잘 되있나요?

[@Vuduendudje]

객체중심 개발에 좀 더 시간을 투자할 수 있는데 쿼리에 집중한다면 그건 백엔드 개발자가 아니라 DBA아닐까요? 개발은 SQL 중심개발보단 객체 중심 개발이 더 개발일이라고 생각하는데 그래프ql은 그런 개발관점에서 필요한거 같습니다.

[@galaxykim8385]

@@Vuduendudje 그럼 api 마다 요구에 적절하게 ORM을 잘 짜면 되는거 아닌가요?

[@galaxykim8385]

@처음처럼 네😀, 우리나라에서는 앞단 잘만지고 쿼리문 잘 쓰는 사람을 원하긴 하죠~~ ( 스프링 + 마이바티스 + 쿼리 날리기 )

[@Daniel-ei8tv]

필요할 때마다 엔드포인트를 새로파거나, 그렇게 새로파서 늘어난 많은 엔드포인트를 관리하는 것도 개발자에게 많은 리소스를 필요로 합니다. 그리고 규모가 큰 서비스회사의 경우 하나의 API서버의 데이터를 필요로하는 많은 서브 프로젝트, 도메인이 있어서 그들에게 딱 맞는 데이터만 쿼리로 가져오기 어렵습니다. 원하는게 각자 다를테니까요. 그렇다고 엔드포인트를 서브 프로젝트마다 파기엔 앞선 이유로 개발자가 갈리죠. 오버페칭과 언더페칭으로인한 문제는 확실히 크리티컬한 것 같습니다. 다만 개발자의 숙련도에 따라 완화될 순 있어요.

[@galaxykim8385]

@@Daniel-ei8tv 감사합니다. 많은 도움이 되네요~

[@kn-he1ik]

기존 REST 에서는 서버에서 주는 데이터를 기반으로 클라이언트 가 맞춰서 작업 해야 합니다. 클라이언트 측에선 fetch 로 받은 데이터를 직접 모델링하고 가공해야 하죠. Graphql 에서는 반대 입니다. 서버에서 클라이언트가 원하는 데이터를 맞춰서 줍니다. 클라이언트는 query 하나로 해당 컴포넌트에서 원하는 데이터를 한번에 받아 옵니다. 즉, backend for resource 에서 backend for usecase 로 이동합니다. fe 입장에서는 BFU 가 개발하기도 좋으며, sideeffect 도 rest 에 비해 적고, 네트워크 트래픽도 줄어듭니다. 서버와 동일한 스키마를 공유하기 때문에, 별도로 데이터를 모델링 해줄 필요도 없구요. rest 의 장점은 json 외 multipart 데이터들 처리가 더 쉽다는것? 그리고 인증과 관련된 api 를 설계하기 쉽다는 것? graphql 을 제대로 사용해본 사람들이라면 안쓸이유가 없어요.

[@Elfail]

그랍쿠엘

[@baedori323]

언제쯤 이런 것들을 쓸 수 있게 될 것인가.. (=ㅂ=)ㅋㅋ

[@tyler.the.developer]

적어도 graphQL은 써야 도메인 분리를 시도할 수 있지 않을까싶네요 말로만 MSA사기 그만치고 😂

[@Jeenie92]

오늘은 집이 아니고 콜롬비아군요,,,멍뭉이가 안보여서 아쉽

[@florasblancas9921]

배경이 배경이라 그런가 노마드코더 옛날 영상들 느낌이 나네요.ㅋㅋㅋ

[@nomadcoders]

앗 그런가요 ㅡㅇ ㅡ ㅎㅎㅎ

[@wkdrn970]

신규 서비스 spring graphql로 만들고 있는데 graphql을 지원하는 라이브러리 마다 소켓 통신인 subscription 잘 지원하는게 있고 애매하게 지원하는거 있어서 잘 확인하고 사용해야 함 graphql로 원하는 데이터만 빼오는거 결국 그걸 백엔드에서 다 맞춰 줘야함 결국 rest api랑 차이가 없었음 또 graphql 쿼리 명 짜는것도 스트레스 받음 웹은 rest api가 최고인데 어플은 graphql 도입할 고려 있다 생각함

[@hopOnTheTeapot]

graphql로 원하는 데이터만 빼오는거 결국 그걸 백엔드에서 다 맞춰 줘야함 : 이게 진짜로..ㅋㅋㅋㅋ

[@fang3131]

백엔드에서 리졸버로 다 맞춰줄 거면 그냥 REST 쓰는 게 낫습니다. GraphQL은 어지간한 건 db 담긴 값 그대로 읽어서 필요한 것들 가져가서 클라이언트가 계산해서 쓰라는 쪽입니다.

[@user-vf1tj3vg6s]

리 마->리마

[@polarisnation201]

Apollo Server + GraphQL + TypeScript? So sexy...

[@jumping-wolf]

요즘 이 이름이 많이 보이길래 이름 보고 화면 그리는 프론트엔드 기술인가 했는데 전혀 반대네요

[@chansong153]

제 동생이 썸네일 보고 제2의 닥터 옥토퍼스래요

[@Jay-bb6kw]

이 영상을 보고 GraphQL을 한번 공부해보는건 좋은 생각입니다 다만 GraphQL을 안전하게 적용하기 위해서는 프로그램 전체 라이프사이클상에서 고민이 필요합니다. 좋게말하면 클라이언트에서 직접 쿼리를 날릴 수 있다지만. 나쁘게 말하면 클라이언트에서 "위험한" 쿼리를 직접 날릴 수 있다는 양날의 칼과도 같아서 적용 가능한 분야가 한정적이라는것을 꼭 유념해야 합니다. 풀스텍개발자라는 미명하에 작은 사이트를 개발자한명에게 몽땅 개발 시키는 경우 정도라고 생각되는데 그이상의 대규모 프로젝트에서 적용하다보면 이거저거 따지다 보면 결국 복잡도만 올라간 잘개쪼개진 REST API들의 집합처럼 만들어 지게 되고 오히려 유지보수만 어려워질 뿐입니다.

[@jkijljbnj7165]

graphql에는 authentication도 없을 거라 생각하시나요..? 쿼리 조금이라도 어긋나게 날리면 1차적으로 자체에서 거부합니다. 개별적인 검증도 당연히 구현 가능하구요. 오히려 자체적으로 검증해 주는 과정이 있어 기본적으로 해줘야 하는 직업들이 주는 편이죠. 잘 모르시는 분 견해인 듯하니 공부하실 분들은 너무 깊게 듣지 마시길

[@jkijljbnj7165]

@@user-wc9ni4ib8g 컬럼을 키워드로 하여 조회할 때 각 컬럼 식별자와 같이 조회하면 조회한 값이 바로 캐시에 저장됩니다. 다음 쿼리때 같은 식별자가 있다면 캐시에서 먼저 조회하여 이미 존재하면 서버에 재요청 안합니다. 여기서 특별한 건 스키마 상으로 관련된 데이터를 조회하면서 해당 컬럼값을 포함시켜 이미 받아왔다면 이것도 캐시에 저장돼 있어서 쿼리시 캐시에서 읽어 옵니다. graphql은 이런 작업을 개발자 입장에서 신뢰를 하고 쉽게 구현 가능하죠.

[@jkijljbnj7165]

graphql이라고 해서 반드시 서버를 거치지 않도록 해야 하는 것도 아니고 선택적으로 가능하고 다만 graphql 사용시 서버와 클라이언트 간에 오가는 정보가 하나의 스키마 구조로 캐시화가 효율적으로 된다고 이해하는 편이 좋은듯합니다. 처음에 스키마만 제대로 만들어 두면 개발자는 그거 보면서 각 api만 만들면 된다 이게 핵심이라고 생각하는 게 맞지 않나 하네요

[@user-vf1tj3vg6s]

스텍->스택 어 지->어지

[@assistant-brother]

일단 써본 입장에서 GraphQL 은 두 가지 점에서 매우 불편하다. Apollo GraphQL 기준으로 설명하자면, 1. SQL DB 와의 연동 힘듦 아폴로에선 공식적으로 SQL DB 와의 연동을 제공하지 않는다. SQL DB 가 한두개가 아니니깐 이해한다지만... 가장 인기있는 서드파티 라이브러리라도 존재해야 할텐데, 작년 기준으로 딱히 보이지 않았다. 기껐해야 PostGraphile 또는 Hasura 인데, 당장 쓰기에는 초보자 입장에서 매우 만족스럽지만, 깊게 들어가기엔(내가 원하는대로 쿼리 구성) 문서 자체가 불친절. 꼭 SQL DB 를 써야하느냐? 물론 그럴 필요는 없다. 그러나 대학생이 포트폴리오를 준비하는 입장에서 SQL DB 는 누구나 고려하는 선택 아닌가. 2. 기존 API 사이트들은 여전히 REST API 를 제공함 내가 공공기관에 접속해서 미세먼지 정보를 받아온다거나, 영화 정보를 제공하는 사이트의 API 를 이용한다치면 당연히 REST API 로 제공될 것. 물론 GraphQL 은 REST API 와의 연동성도 좋다지만, 글쎄다. 굳이 그럴 필요가 있나 싶다. 전체적으로 써보고 느낀 점: 써보면 진짜 감탄이 나올 정도로 멋지지만, 딱 그 정도고, 평소 쓰던 칼(REST) 이 더 편함. 적어도 취준생은 안 썼으면?

[@jkijljbnj7165]

prisma 있습니다.

[@forestpark1166]

I have a deep love-hate relationship with Graphql. I love the server side portion of graphql. However, the biggest problem I have with implementing graphql comes in the frontend client. Apollo Client's graphql cache handling is a nightmare. It took me weeks to even have a rough understanding of how Apollo Client caching works. I still love graphql and will continue to use it, but the deeper you dig into grapqhl, the less logical sense it makes. On that note, does anyone know of a good client/documentation on how to handle cache on the frontend?

[@nomadcoders]

What problems are you having with it?

[@forestpark1166]

@@nomadcoders Mostly the lack of documentation with how the caching system works with Apollo Client. Also, some of the network options straight up dopn't work. I can't remember the exact situation, but for example if you were using a mutation you couldn't use the cache-and-network strategy or something like that(might not be this exact example). I was so furstrated with it I sent an email to one of the maintainers and confrimed that some of the network strategies are availble in the options, but won't actually do anything and just default to a network-only strategy. It was something insanely stupid. Again, graphql's problem is not with the server, but the client.

[@forestpark1166]

@@nomadcoders I've heard a lot of good things about Relay, but the there's practically no documentation on it. Also read a lot of articles from FB engineers saying it's quite difficult to use. I just hope there's a better graphql client in the future.

[@user-jy5zy1kj4q]

썸네일의 예술성에 한 번 감동하고, GraphQL의 놀라움에 두 번 감동하고, 무료 강의가 있다는 거에 세 번 감동하는, 거를 타선 없는 영상이었다..!

[@nomadcoders]

고맙습니다~~~^^

[@hJ-ze4jm]

코드에 마법은 없다.

[@adover]

DRF로 졸업프로젝트를 진행 중입니다. 공부해보니 모델에 시리얼라이저를 여러 종류를 두면 over fetching이나 under fetching 문제를 해결할 수 있다는 걸 발견했었어요. 시리얼라이저를 많이 두는 게 비효율적일 것 같지만 큰 프로그램이거나 그런 일부 데이터만 요청하는 경우가 많다면 좋은 트릭인 거 같더라고요. 결론적으로, 굳이 GraphQL을 공부하는 건 시도하고 싶지 않네요. Rest FrameWork로 충분히 해결 가능한 문제점들을 처리하려고 학습 진도를 초기화하고 싶지는 않아요.

[@yangmooyoung8787]

사실 rest api 도 디자인을 잘한다면 영상에서 말하는 문제점을 해결할 수 있다고 생각합니다. 쿼리를 잘 고안한다던지 서버팀이랑 잘 얘기해서 개발하려는 서비스에 최적화된 명세를 받는다든지요. 클라이언트 단부터 개발을 시작해서 서비스를 완성할 때 graphql 을 사용하는 게 나쁘지 않겠지만..글쎄요. 러닝커브를 빨리 극복하시는 분들이 사이드 프로젝트나 프로토타입으로 시도해보는 것은 좋겠지만, 이미 업무에서 개발환경이 잘 짜여져 있는 팀에서 추가로 사용하기를 권하고 싶지는 않습니다 😀

[@user-vf1tj3vg6s]

던지->든지 짜여져->짜여

[@jkijljbnj7165]

REST로 일정 수준에 올라오신 분들의 적극적인 저항이 여기저기 보이는군요 ㅎㅎ 제가 써본 걸로는 오히려 REST를 쓰면서 성능이나 유지보수성 위해서 나중에 어차피 해야할 수밖에 없는 것들을 이미 자체적으로 심플하게 마련해둔 것들이 graphql인데 말이죠. 원래 좀 그렇죠.. 자기가 잘하는 것에 비해 발전된 뭔가가 나오면 새로 나온 것에서는 그게 안될거라고 생각하는... 근데 그건 그냥 본인이 오래된 것에 대해 잘 알고 새로운 것에 대해서 잘 모르기 때문일 뿐입미다.

[@jongmin0328]

대충 찍먹만 해보고 REST API에 비해 보일러 플레이트가 늘어나니 배우기 귀찮고 배워야 할 이유를 다들 못 찾으시는 듯. 원래 본인이 잘쓰고 있는거 변화가 싫은 사람들이겠죠. 개인적으로 언더 페칭 오버페칭은 솔직히 큰 장점인진 잘 모르겠고, 서버와 클라이언트가 동일한 스키마(타입)를 가지고 작업할 수 있다는게 최대 장점이라고 생각함... 저는 REST로는 돌아갈 수 없는 사람이 되어버렸습니다.

[@jkijljbnj7165]

@@jongmin0328 더 해 보시면 그건 정말 빙산의 일각일 뿐임을 알게 되실 겁니다... cache 관리 및 dataLoader까지 도입하면 언더페칭 오버페칭이 왜 막강한지 알게 되실 겁니다. 파보면 파볼수록 진짜 대단한 게 GQL이라고 생각하네요

[@david-ji8tw]

지금 회사 취업 공고를 보셈 ㅋㅋㅋㅋㅋㅋㅋ 그래서 회사의 몇프로가 쓰냐고요 ㅋㅋㅋ 95%이상이 rest api 아니 5%도 안됨 rest 안쓰고 그래프로 사업하는곳은. 무슨 제목은 앞으로 레스트 api 못쓴다며 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 2020년도에 앞으로 4년뒤에 모든회사는 자바 안쓰고 파이썬이라는 언어로 백엔드를 올릴겁니다 더이상 자바의 시대는 갔습니다라고 말하는 것 같네 2

[@jkijljbnj7165]

@@david-ji8tw 한국 고인물

[@user-ly9le4vz2i]

그래프큐엘... POST 밖에 못보내는것부터 꺼림칙..

[@byeonggeonkim7973]

웹사이트 최적화냐 내 건강이냐

[@TheWintrover]

블랙필은 없구만

[@david-ji8tw]

항상 설레발은 ㅋㅋㅋ 취업공고를 봐라 graphQL ㅋㅋㅋㅋ

[@frontend_ko]

리덕스 쓰기 싫어요

[@user-cp8qt2hb5l]

Grpc 붐은 온.. 왔다?

[@user-os9st5rd8i]

않데... Rest잘쓰고있었는데 바뀔각이 보여...

[@1dulee289]

댓글을 보면 아직 GraphQL의 장점에 대해서 공감하지 못하는 분이 많은거 같아요. (약간 크로스 플랫폼 같은 포지션? 의도는 좋지만 결국 하는 일의 양은 비슷한데 굳이 이걸 쓸 이유가 없는?) 니꼬가 한번 더 설득력 있게 GraphQL을 주장해보면 어떨까 싶어요! ts랑 next, nest 는 다 잘 쓰고 있습니다

[@jongmin0328]

대충 찍먹만 해보고 REST API에 비해 보일러 플레이트가 늘어나니 배우기 귀찮고 배워야 할 이유를 다들 못 찾으시는 듯. 저는 REST로는 돌아갈 수 없는 사람이 되어버렸습니다.

[@JakubSK]

GraphQL is noise