|
|
|
|
|
by sradman
2047 days ago
|
|
Aside: why is there not an RSS feed for the WunderGraph blog? I think Jens Neuse is making two important observations about GraphQL: 1. GraphQL's single URL/endpoint [1] is possibly an anti-pattern 2. ETags are important for Cache-Control and Concurrency-Control on REST endpoints The concept of prepared statements is useful for my SQL-centric brain. WunderGraph effectively creates a REST endpoint for each prepared statement (GraphQL DML). Like prepared statements in SQL, WunderGraph uses query metadata to determine the types of input parameters and the shape of the JSON response. Kyle Schrade makes an important point about canonical GraphQL queries: response payloads can be reduced by filtering JSON fields, similar to SQL projection (i.e. the columns specified in the SELECT clause). It seems that WunderGraph can potentially support both approaches by allowing optional GraphQL queries on each REST endpoint that can be used to filter the endpoint specific JSON response. [1] https://graphql.org/learn/serving-over-http/#uris-routes |
|