https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
이제 GraphQL 없는 정적 웹은 상상도 못하겠군요
# 잡담
h
이제 GraphQL 없는 정적 웹은 상상도 못하겠군요
h
어떤 점이 더 좋은지 알려주실 수 있나요?
h
'더 좋은지' 라는건 비교 대상이 있나요?
GraphQL 을 안쓰고 비교할만한 Jamstack 프레임워크...? 11ty?
h
그냥 GraphQL 없이 데이터를 넣는 녀석들도 있었으니까요. Jekyll이라던지?
프레임워크는 아니지만 정적 사이트 서비스중인 곳에서 GraphQL을 안쓰는 곳이 쓰는 곳 보다 훨씬 많다고 생각되어서요. 그래서 딱히 비교군이 필요 없다고 생각했었는데... GraphQL 없인 정적 웹을 개발못한다고 말할 정도면 뭔가 엄청난 비교점이 있으리라 생각했어요.
h
음 제가 Jekyll 이나 11ty 같이 템플릿 기반인 녀석들을 그리 하드하게 안써봐서 모르는걸 수도 있지만 Gatsby 만큼 깔끔하게 나올거 같지는 않네요. 컨텐츠가 명확히 모델링 가능하고 그게 타입시스템이랑 같이 확장되면서 연결되는 모양이 주는 이점이 확실해서
h
Jekyll같은거 안쓰더라도 DataDog 정적 문서화 시스템이나 Next.js 정적웹 보면 GraphQL Data pipeline 없이 운영하고 있어서 어떤 펀데멘탈한 차이가 있는지 잘 감이 안오네요.
h
갯츠비 기능들이 하나같이 모델을 재사용하는데 사용할 수록 content mesh 모델에 공감대가 생기기도 하고요
음 일단 제가 생각하는 제일 큰건 얼마나 쉽고 안정적으로 분산 컨텐츠를 통합할 수 있는지인데요.
h
음 컨텐츠가 파일시스템 뿐만이 아니라 외부 CMS나 외부 서비스에 있을 때
어떻게 통합하느냐 인가요?
h
기존의 "생성기" 수준이라면 결국 컨텐츠 모델에 대한 지식이 당연히 외부서비스로 가게되는데
그게 지금의 Headless CMS 생태계인데
너무 중앙화되어있어서 워크플로우가 유연하지 못해요
"Content Hub" 라고 불리는
h
유연하지 못하다는게 어떤 말씀이실려나요?
h
모든 컨텐츠 관리가 하나의 CMS 도구로 집중되는거죠
근데 실제로는 컨텐츠에 참여하는 팀들은 엄청 분산되어 있거든요
저마다 다른 도구를 쓰기도 하고 저마다 다른 업무방식이 있기도 하고
어디는 스프레드 시트로 데이터를 관리하고 어디는 뭐 노션같은거로 쓸 수도 있죠
h
그렇네요, 다양한 팀이 있을때 데이터를 관리하는 방법이 다를 수 있겠어요.
h
갯츠비의 기능들을 전체적으로 목업해보면
하나의 업무방식 하나의 소스를 각각 "노드"로서 확장하고 재사용하도록 설계가 되어있고
실제 프론트엔드가 통합되는 방식도 엄청 우아하게 되어있어서 뭐랄까 쓰면서 계속 감탄하게 되네요
이 그림이 2015년도에 릴레이보고 탄생한 그림이라는거잖아요
Kyle 아마 학생이였을텐데 (전공이 뭔지 모름)
제가 느끼기엔 분산된 큰 조직의 미디어를 다 감당하기에 Gatsby만큼 이상적인 도구가 아예 없기 때문에...
아 물론 개발팀이 규모가 더 크거나
개발팀 자체를 분산시키는 방법이 있긴 하겠지만 ㅋㅋ
개인적으로 갯츠비의 Content sourcing 이나 Themes 같은 피쳐들은 다른 툴들이 착실히 배워줬으면 좋겠습니다.
h
음 그럼 GraphQL이 아니라 Gatsby의 Data pipeline 인터페이스가 중요한걸까요?
h
GraphQL이 전신이죠 정확히는 릴레이 컴파일러 아키텍처가
GraphQL 없으면 동작을 안해요 정의하는 쪽이던 쓰는 쪽이던
아 왠지 출처를 알거같기도한데
나중에 안거지만
GraphQL 창시자 중 한 명인 Lee Byron 이 GraphQL 공개할 때 유사한 정적 웹사이트 프레임워크를 만들었더군요. 물론 데이터 레이어에 대한 아이디어는 안들어있는것 같지만
릴레이 발표보고 감명받아서 웹사이트 까보다가 번개라도 맞으면 이런 아이디어가 나오는건지
으으음... 저도 이걸 짧게 설명하는게 불가능해서 그냥 단순한 감탄밖에 못하고 있는데
글을 한 번 장편으로 쓸 생각을 하고 있긴 합니다 ....
h
분명 이유가 있으실 것 같아요. 다만 주신 말씀만으로는 아직 이해하기 어려운게 사실이에요. 제가 혜성님만큼 맥락을 몰라서요.
h
음 그... 제가 처한상황은 어느정도 유추가능하실거라 생각하는데, 저는 갯츠비 기능을 좀 적극적으로 활용하면 이 상황이 정복이 가능할거라고 믿고있어요. (저만 믿는거 같지만)
https://www.gatsbyjs.com/blog/2018-10-04-journey-to-the-content-mesh/ 큰 그림은 이 글에 대략적으로 있고
실제 구현은 갯츠비의 기능 하나하나를 들여다보는 식이 제일 좋을 것 같은데
u
저는 예전에 gatsby + contentful 로 잠깐 깔작여본 수준이라 그 말씀하시는 내용 전부를 이해하진 못했지만 ㅎㅎㅎㅎ.. 
각각 "노드"로서 확장하고 재사용하도록 설계
부분에서 짐작한 질문입니다: 뎁시 기술-스토리? (tech-story) 블로그 내에서 “컴포넌트“나 “Fragment” 로 보이는 기능 단위?들이 전부 잘게잘게 구현되어 있는지 궁금합니다 (제가 써놓고도 정확하게 무슨 질문인지 이해가 안되네염 잠시만요..)
h
ㅋㅋㅋ 네
Prismic 에는 content model 안에 slice 라고 하는 빌딩블럭이 있는데 그걸 쓰는 코드 생김새구요
그리고 이 부분 스키마는 한 번 만들어놓으면 다른 사이트에도 그대로 재사용이 가능해져요
탄탄한 스키마랑 갯츠비 쪽 쿼리 컴파일러 덕분에 저거 React 17 쓴다고 TS 타이핑이 다 깨졌는데 런타임 타입에러 안밟기도 했고요 (휴)
u
awesome…
조각 단위로 컴포넌트가 되고 그 안에서 스타일링이라던지 그런게 해결되는 구조로 구현하신거 보니까 너무좋네요..
2 Views
Open in Slack
PreviousNext
Powered by