GraphQL 및 마이크로 서비스 아키텍처

GraphQL 및 마이크로 서비스 아키텍처

---

GraphQL이 Microservice 아키텍처 내에서 사용하기에 가장 적합한 곳을 이해하려고합니다.

대상 마이크로 서비스에 대한 요청을 프록시하고 응답을 강제하는 API 게이트웨이로 작동하는 GraphQL 스키마가 1 개 밖에없는 것에 대한 논쟁이 있습니다. 마이크로 서비스는 여전히 커뮤니케이션 사고에 REST / Thrift 프로토콜을 사용합니다.

다른 방법은 마이크로 서비스 당 하나씩 여러 GraphQL 스키마를 사용하는 것입니다. 요청의 모든 정보와 GraphQL 쿼리를 사용하여 요청을 대상 마이크로 서비스로 라우팅하는 더 작은 API 게이트웨이 서버가 있습니다.

첫 번째 접근법

API 게이트웨이로 1 GraphQL 스키마를 사용하면 마이크로 서비스 계약 입력 / 출력을 변경할 때마다 API 게이트웨이 측에서 GraphQL 스키마를 변경해야하는 단점이 있습니다.

2 차 접근법

마이크로 서비스 당 다중 GraphQL 스키마를 사용하는 경우 GraphQL이 스키마 정의를 시행하므로 소비자는 마이크로 서비스에서 제공된 입력 / 출력을 존중해야합니다.

질문

• 마이크로 서비스 아키텍처 설계에 적합한 GraphQL을 찾으십니까?

• 가능한 GraphQL 구현으로 API 게이트웨이를 어떻게 설계 하시겠습니까?

---

확실히 # 1에 접근하십시오.

고객이 여러 GraphQL 서비스에 접근하게되면 (접근법 # 2에서와 같이) GraphQL을 처음 사용하는 목적을 완전히 상실하게되는데, 이는 전체 애플리케이션 데이터에 대해 스키마를 제공 하여 단일 왕복으로 가져올 수 있도록하는 것입니다.

갖는 비공유 아키텍처하면 microservices 관점에서 합리적으로 보이지만, 당신은 당신이 업데이트해야 할, 당신의 microservices 중 하나를 변경할 때마다 때문에 클라이언트 측 코드는, 절대 악몽 수있는 모든 클라이언트의합니다. 당신은 그것을 후회하게 될 것입니다.

GraphQL과 마이크로 서비스는 고객에게 마이크로 서비스 아키텍처가 있다는 사실을 숨기므로 완벽하게 적합합니다. 백엔드 관점에서 모든 것을 마이크로 서비스로 분할하려고하지만, 프론트 엔드 관점에서 모든 데이터가 단일 API에서 제공되기를 원합니다. GraphQL을 사용하는 것이 내가 아는 가장 좋은 방법입니다. 백엔드를 마이크로 서비스로 분할하면서도 모든 애플리케이션에 단일 API를 제공하고 다른 서비스의 데이터를 조인 할 수 있습니다.

마이크로 서비스에 REST를 사용하지 않으려는 경우 각각 고유 한 GraphQL API를 보유 할 수 있지만 여전히 API 게이트웨이가 있어야합니다. 사람들이 API 게이트웨이를 사용하는 이유는 마이크로 서비스 패턴에 잘 맞지 않기 때문에 클라이언트 애플리케이션에서 마이크로 서비스를 호출하는 것이 더 관리하기 쉽기 때문입니다.

---

접근법 # 1이 어떻게, 왜 더 나은지에 대한 기사를 참조 하십시오 . 또한 내가 언급 한 기사에서 가져온 아래 이미지를보십시오.

단일 엔드 포인트 뒤에있는 모든 것을 갖는 주요 이점 중 하나는 각 요청에 고유 한 서비스가있는 경우보다 데이터를보다 효과적으로 라우팅 할 수 있다는 것입니다. 이것이 복잡성과 서비스 크리프의 감소 인 GraphQL에서 종종 선전되는 가치 인 반면, 결과적인 데이터 구조는 또한 데이터 소유권을 매우 잘 정의하고 명확하게 설명 할 수있게합니다.

Another benefit of adopting GraphQL is the fact that you can fundamentally assert greater control over the data loading process. Because the process for data loaders goes into its own endpoint, you can either honor the request partially, fully, or with caveats, and thereby control in an extremely granular way how data is transferred.

The following article explains these two benefits along with others very well: https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/

---

For approach #2, in fact that's the way I choose, because it's much easier than maintaining the annoying API gateway manually. With this way you can develop your services independently. Make life much easier :P

There are some great tools to combine schemas into one, e.g. graphql-weaver and apollo's graphql-tools, I'm using graphql-weaver, it's easy to use and works great.

---

As of mid 2019 the solution for the 1st Approach has now the name "Schema Federation" coined by the Apollo people (Previously this was often referred to as GraphQL stitching). They also propose the modules @apollo/federation and @apollo/gateway for this.

ADD: Please note that with Schema Federation you can't modify the schema at the gateway level. So for every bit you need in your schema, you need to have a separate service.

---

I have been working with GraphQL and microservices

Based on my experience what works for me is a combination of both approaches depending on the functionality/usage, I will never have a single gateway as in approach 1... but nether a graphql for each microservice as approach 2.

For example based on the image of the answer from Enayat, what I would do in this case is to have 3 graph gateways (Not 5 as in the image)

• App (Product, Basket, Shipping, Inventory, needed/linked to other services)

• Payment

• User

This way you need to put extra attention to the design of the needed/linked minimal data exposed from the depending services, like an auth token, userid, paymentid, payment status

In my experience for example, I have the "User" gateway, in that GraphQL I have the user queries/mutations, login, sign in, sign out, change password, recover email, confirm email, delete account, edit profile, upload picture, etc... this graph on it own is quite large!, it is separated because at the end the other services/gateways only cares about the resulting info like userid, name or token.

This way is easier to...

• Scale/shutdown the different gateways nodes depending on they usage. (for example people might not always be editing their profile or paying... but searching products might be used more frequently).

• Once a gateways matures, grows, usage is known or you have more expertise on the domain you can identify which are the part of the schema that could have they own gateway (... happened to me with a huge schema that interacts with git repositories, I separated the gateway that interact with a repository and I saw that the only input needed/linked info was... the folder path and expected branch)

• The history of you repositories is more clear and you can have a repository/developer/team dedicated to a gateway and its involved microservices.

---

As microservice architecture does not have a proper definition, there is no specific model for this style but, most of them will come with few notable characteristics.In case of microservices architecture, each service can be broken down into individual small components, which can be individually tweaked and deployed without affecting application integrity. This means you can simply change a few services without going for application redeployment through custom microservices app development.

---

마이크로 서비스에 대한 자세한 내용은 GraphQL이 서버리스 아키텍처에서도 완벽하게 작동 할 수 있다고 생각합니다. GraphQL을 사용하지 않지만 비슷한 프로젝트가 있습니다. 많은 함수를 호출하고 단일 결과에 집중 시키는 집계 자로 사용합니다 . GraphQL에 동일한 패턴을 적용 할 수 있다고 생각합니다.

참고 URL : https://stackoverflow.com/questions/38071714/graphql-and-microservice-architecture