#03. GraphQL 프레임워크 어떤 프레임워크를 써야할까?

https://gmyankee.tistory.com/302

#02. Go - gqlgen 프로젝트 설정하기

원래는 gqlgen을 이어서 작성하려 했으나, gqlgen에는 치명적인 결함이 있어, graphql-go로 변경하게 되었습니다.

아마 graphql-go가 github에서는 선두를 달리고 있으니.... 가장 많이 쓰이는 데에는 이유가 있을 거라 생각됩니다.

 

gqlgen의 가장 치명적인 문제는 크게 2가지가 있습니다.

 

• Custom Schema로부터 자유롭지 않습니다.
• Graphql-Relay가 없어 수동으로 만들어서 작성해야 합니다.

 

사용자 정의 스키마가 자유롭지 않다는 것은 별도의 스키마를 생성하는 것을 의미하는데,

타입명시 후 go generate 또는 gqlgen init 등 명령으로 자동으로 grahpql 스키마를 생성하는데 이게 기존에 존재하던 녀석과 관계되어 있거나, 명시되어 있다면 상당히 귀찮고 골치 아파집니다.

몇 번 삽질해보시면 감이 오게 되는데, 매번 그러는 것도 상당히 스트레스입니다.

 

 

Graphql-Relay가 없다는 것은 사실상 페이지 네이션을 스스로 만들어야 한다는 격입니다.

django에서도 너무도 당연하게 쓰던 것이 말이죠...

사실 go가 워낙 자유분방하니깐 그럴 수도 있긴 한데, Prisma, Prisma2나 Apollo Server, Yoga, Django Graphene 오 생각보다 제가 써본 프레임워크들이 상당합니다요.  그런데 위 친구들에겐 Relay가 너무도 당연시되었던지라 너무 불편합니다.

 

 

 

 

 

각 프레임워크의 문제점

Framework	장점	단점
Prisma1	스키마만 작성하면 자동으로 db를 생성합니다.	JVM 때문에 메모리 이슈 발생
Prisma2	마찬가지로 스키마만 작성하면 자동으로 db를 생성합니다.	Relay, Generate 다 좋은데 우리한테 너무도 당연했던 외래키 제약사항이 제정신이 아님
Apollo Server, Yoga Framework	Nodejs기반으로 빠른 개발이 가능합니다.	대규모는 검색들 많이해보셨으면 아시겠지만 암덩어리라 코드가 산처럼 불어나서 유지보수에서 각종 폐암 대장암 후두암 등 없는 암이 없습니다.
gqlgen	Go와 gin으로 작성되어 굉장히 빠르고, echo도 가능합니다.	앞서 언급된 2가지 문제입니다. relay가 없는 것 과 스키마자유성이 떨어지고 추가로 덧붙이자면 플러그인이나 커스텀타입도 답이없습니다.

 

 

 

 

GraphQL 프레임워크의 선택 기준

저는 graphql Framework를 선택할 때 (i'm not super hero) 많은 것을 바라지 않습니다.

• GraphQL Playground를 지원하는가? (GraphiQL이나 혹은 playground조차 없으면 진짜 암입니다.)
• Relay를 지원하는가?
• Schema First인가? (Code first보다 스키마를 우선순위로 지향하는가를 확인합니다.)
• Auto Generate한가? (이건 prisma, gqlgen을 버리면서 이제 기대 안 합니다)

 

GraphQL Playground를 지원하는가?

Prisma Project에서 개발하여 지금은 Apollo 공식 playground가 되어버린 Graphql Playground를 지원하지 않고

그 찐따 같은 Graphiql을 사용한다면 차라리 REST API를 사용하겠습니다...

사실 graphql playground는 Electron으로 Window Client 도 지원을 하긴 합니다만 웹으로 왠지 안 해주면 기분이 나쁩니다.

 

Graphql Playground

플레이 그라운드의 영롱한 자태입니다.

반면에 찐따 같은 iql을 보시죠

하얘서 봐주기가 싫습니다.

 

 

 

Relay를 지원하는가?

GraphQL은 대체로 많은 서비스 또는 사람들이 Cursor Based의 Pagination을 활용합니다.

근데 이 커서 기반에서는 Relay를 사용한다면

hasNextPage, hasPrevPage, afterCursor, beforeCursor, total 등 이런 것들을 굳이 만들지 않고도 획득할 수 있습니다.

그런데 이게 없을 경우에는 대충 만들면 쿼리 3개를 호출하여야 하는 불상사도 볼 수 있습니다.

 

 

Schema First한가?

프레임워크의 우선순위 방식이 Code First 한 것인지, Schema First 한 것인지에 따른 문제입니다.

SDL이라고도 표현하긴 하는데, 스키마와 코드 중에는 사람에 따라 케바케입니다.

Prisma는 2018년 이후로 Code First로 변경하였는데,

스키마 접근 우선 방식은 예외적인 상황 처리가 어렵지만 스키마가 명확하기 때문에, 백엔드가 아직 Resolver를 개발하지 못하였어도, 프런트 측에서 스키마를 보고 동시 개발이 가능하고, DIP 원칙을 수렴할 수 있습니다.

코드 접근 우선 방식은 DRY원칙을 수렴하여 재사용성을 늘리고 스키마 명시를 분산할 수 있습니다.

 

근데 스키마 우선도 분산 쌉가능하던데...

 

 

 

개인차가 있겠지만, 저는 크게 3가지를 고려하였으며 아마 많은 분들은 언어를 보고 선택하는 경우가 많으실 겁니다.

Nodejs라고 해서 무조건 유지보수가 어렵다는 것은 아니지만 거기에 투자해야 하는 많은 것들이 포함될 수 있습니다.

그렇다고 새로운 언어를 한다고 해도 거기에 투자되어야 할 시간이 들어야 하죠.

 

Typescript를 안 해보신 분이라면 정적 언어를 접할 경우 괴리감이 느껴질 수 도 있습니다.

당근 마켓처럼 점진적 변경 방식을 추구하는 것도 방법인 것 같습니다.

 

한때 Python은 프로 토타 입용으로 개발하고 미래에 다른 언어나 프레임워크로 변경하는 추세를 많이 따라가던 시절이 있었죠...

 

 

그래서 앞으로 이 시리즈 포스트를 살려서 결론은

graphql-go를 이용해서 진행될 예정입니다.