GraphQLとマイクロサービス

Question

私の会社では、新しいプロジェクトのためのマイクロサービスアーキテクチャを決めました。 GraphQLを見て、単一のAPIエンドポイントとして使用することの可能性と利点を実感しました。

私たちは、GraphQLと各マイクロサービスとの間の通信をどのように行うべきかについて意見を異にします。 RESTを主張する人もいれば、サービスごとにgraphQLエンドポイントを持つべきだと言う人もいます。

それぞれの長所と短所のいくつかが不思議でした。 たとえば、各サービスのスキーマの一部を複製するので、graphQLのすべてを少し冗長に見えることがあります。 一方、RESTの落とし穴を避けるためにGraphQLを使用しています。 RESTエンドポイントがgQLから得られる利点を無効にするのではないかと心配しています。

誰も同じようなジレンマに遭遇しましたか？ 私たちの誰もGraphQLを経験していないので、私たちが行方不明になっていることは明らかです。

ありがとうございます！

Answer 1

GraphQLとマイクロサービス用にアーキテクチャを設定する方法と、その理由について質問しているようです。

背景

それが最高のユースケースですので、私はGraphQLを使用することをお勧めしますきれいな方法でデータソースを統合し、1つの標準化されたAPIを介して、あなたにすべてのデータを公開することです。裏返して、マイクロサービスを使用する際の主な問題の1つは、おそらくあなたが持つ可能性があるすべての異なる機能を取り組むのが難しいということです。アプリケーションが大きくなるにつれ、これらのマイクロサービス機能をすべて統合することが大きな問題になります。

これらのテクノロジを使用する利点は、Graphite APIゲートウェイを基本的に備えているため、クライアントから単一のモノリシックアプリケーションのようにマイクロサービスにアクセスできるようになりますが、マイクロサービスパフォーマンスと効率の観点から。

アーキテクチャ

だから私は推薦するアーキテクチャは、あなたのmicroservicesの前に座っGraphQLプロキシを持つことである、とあなたGraphQLクエリおよび変異リゾルバでは、必要なデータを取得する必要がある関数を呼び出し。

GraphQLマイクロサービスの前にGraphQLゲートウェイを置くか、RESTエンドポイントの前にGraphQLゲートウェイを置くことは、それほど重要ではありませんが、マイクロサービス機能をRESTとして公開する方が簡単だと主張します各機能は理論的に1つの目的のみを果たすべきであるからである。この場合、余分なオーバーヘッドやGraphQLの複雑さは必要ありません。なぜなら、あまりにも多くのリレーショナルロジックがバックグラウンドで行われるべきではないからです。

あなたはmicroserviceプロバイダーを探しているなら、私が見た中で最高のものはAWS Lambda、Webtask、Azure Functions、およびGoogle Cloud Functionsです。また、これらのマイクロサービス機能を管理および展開する方法として、Serverlessを使用することができます。例えば

：

import request from 'request'; 

// GraphQL resolver to get authors 
const resolverMap = { 
    Query: { 
    author(obj, args, context, info) { 
     // GET request to fetch authors from my microservice 
     return request.get('https://example.com/my-authors-microservice'); 
    }, 
    }, 
}; 

GraphQLサービス

これは、我々はあなたが管理を支援するサービスに依存したい場合にもScapholdで模索してきたものですこのワークフロー。最初に、GraphQLのバックエンドサービスを提供し、数分でGraphQLを開始し、独自のマイクロサービス（カスタムロジック）をGraphQL APIに関数の構成として追加することができます。これは本質的に、最も高度なウェブフックシステムで、マイクロサービスへの呼び出し方法を柔軟に制御できます。

はあなたが地域にいる場合も、SFでServerless GraphQL Meetupに参加してお気軽に:)

は、この情報がお役に立てば幸い！