Update 3575-sync.md

proposals/3575-sync.md

@@ -1452,6 +1452,25 @@ and 10,000s of rooms per account as metadata rooms continue to be added (VoIP co
 spaces, profiles-as-rooms, thread-per-room, etc). If this assumption is false and room counts remain
 reasonably well bounded then this MSC may not be required.
 
+## GraphQL
+
+We could define schemas for querying sync data and expose a GraphQL server on every Matrix homeserver.
+This would have numerous benefits:
+ - flexible query language,
+ - SDKs exist which interact with GraphQL e.g for automatically handling pagination, streaming,
+ - more standardised than a custom line protocol i.e if you know GraphQL already, it lowers the barrier to entry (e.g using Subscriptions for real-time updates)
+ - some would argue this is less complex than designing a custom API.
+
+This would have the following drawbacks:
+ - easy to design slow performing queries. Denial of Service risk, mitigated via strong rate limits (see [Github v4 API](https://docs.github.com/en/graphql/overview/rate-limits-and-node-limits-for-the-graphql-api),
+ - higher bandwidth costs than a custom API (both for requests and responses),
+ - easier to accidentally expose confidential information by not applying sufficient authentication checks,
+ - some would argue this is more complex than designing a custom API,
+ - it forces all Matrix developers to become familiar with GraphQL as the queries are crafted client-side,
+ - it's difficult to cache responses, impacting speed.
+
+Overall, GraphQL would be suitable for rapid prototyping, but does not meet the [Goals](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/sync-v3/proposals/3575-sync.md#goals) of this API.
+
 # Security considerations
 
 This API presents new ways to request data from the server which need appropriate authentication checks: