問題タブ [server-to-server]

サーバー間の通信、より正確にはさまざまなマイクロサービス内で、 GraphQLを使用することは良い考えですか?

アイデアは、消費者が関連するフィールドのみを取得できるようにすることです。REST GET エンドポイント自体のフィールド プロジェクションを構築することも、Rest.liなどのライブラリを使用して構築することもできます。

GraphQL が同様の問題を解決するために存在する時代では、READ に GraphQL を使用し (ここで GraphQL が多くの価値をもたらします)、書き込み操作に REST を引き続き使用する方が理にかなっています (GraphQL に移行するいくつかの説得力のある理由があります)。 for writes は現時点では不可能です)?

Apple は、一部のサブスクリプション イベントでは、複数の通知をトリガーすると述べています。別の安価なオプションを提供できるように、ユーザーがサブスクリプションをキャンセルしたかどうかを調べたいとします。

DID_CHANGE_RENEWAL_STATUS彼らがいつ自動更新をオフにしたかを聞くことができました。ただし、問題があります。ユーザーが別の SKU にアップグレードした場合、同じ通知がトリガーされます。実際、彼らのドキュメントによると、それはCANCEL、DID_CHANGE_RENEWAL_STATUS、 の3 つの通知をトリガーしINTERACTIVE_RENEWALます。

これらのシナリオを区別したいと思います。明らかに、これらは非同期操作であるため、到着順序は保証されません。しかし、3つの通知すべてが同じで届くと期待できるかどうか疑問に思いますかunified_receipt? DID_CHANGE_RENEWAL_STATUSもしそうなら、通知を聞いて確認unified_receiptし、ユーザーが別の製品にサインアップしていないことがわかった場合は、別のサブスクリプション オプションを提供できます。

ただし、ドキュメントには、複数の通知が送信された場合に、すべてが同じunified_receipt. それは論理的です...しかし、notification_type物事を単純化するために配列を作成することも論理的です。unified_receiptそして、Apple がそれを行っていないことを考えると、今後の通知が同じになるとは期待できないのではないかと心配しています。

あなたが共有できるこの経験をした人はいますか？