[WIP] Republish Marc-André Giroux's blog post with light edits #1721
Conversation
|
@bignimbus is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel. A member of the Team first needs to authorize it. |
bignimbus
force-pushed
the
source
branch
2 times, most recently
from
67aabcc
to
13b1ed2
Compare
Co-authored-by: Benjie <[email protected]>
Co-authored-by: Benjie <[email protected]>
|
|
||
| Public APIs are a bit different. To be clear, it's not necessarily true that you can't use Persisted Queries in public APIs; one could ask customers to register queries first. But figuring out the DX for this would be an interesting task. That's why [We Don’t See Many Public GraphQL APIs](https://productionreadygraphql.com/blog/2019-10-21-why-we-dont-see-many-public-graphql-apis) out there, and why I would not pick GraphQL if I were to expose a public API today. | ||
|
|
||
| For a public API, a coarser-grained, resource-based API works great, and can be described through OpenAPI. SDKs can be generated through amazing tools like [Kiota](https://learn.microsoft.com/en-us/openapi/kiota/overview). It's hard to beat a well-made SDK for a public API, and in my experience, that's actually what customers expect and want to use. |
There was a problem hiding this comment.
Even though I very much agree with the "you probably need persisted queries" call, I have heard a couple of people that created public GraphQL APIs and when you have to go public, mentioned in their talks that GraphQL was a better choice for several reasons.
It is much much harder then private GraphQL APIs but it does have benefits over public REST APIs.
I'm not sure I feel comfortable with that specific suggestion on the community blog
I wonder what others who built public GraphQL APIs and continued to invest in them for years thing (CommerceTools, Shopify, GitLab, Saleor)
|
|
||
| This part is interesting as well and another challenge of authorizing code and models in general. The same "object" accessed through different contexts can actually have different authorization rules. Again, this is common in all API styles as well. That's why I actually usually advise designing this through a different model entirely, since it's likely they'll evolve differently. Here this is even possibly an API design mistake instead. If `handle` should never be seen for `blockedUsers`, then it shouldn't even be part of the schema here. This is a super common mistake where folks try to reuse common models/types instead of being specific. | ||
|
|
||
| After 8 years of GraphQL, I realize more and more that authorization is much more than a GraphQL problem. The API layer part is easy, but most code-bases are much more complex and must guard against unauthorized access in much better ways. Companies like [oso](https://www.osohq.com/) and [authzed](https://authzed.com/) and two great examples of how to do this well but also how complex this thing can be in general. |
There was a problem hiding this comment.
I would add here that this is exactly why graphql.org best practices guide has always suggested not to put Authorization as part of your GraphQL layer:
https://graphql.org/learn/authorization/
|
|
||
| To be 100% fair, of course GraphQL exposes this problem a bit more, earlier on, especially when not using persisted queries (Which should not happen!). And while folks building a small RPC API may not need to implement variable rate limiting or some sort of cost categories, they almost always end up having to. | ||
|
|
||
| And again: this focuses on public, unauthenticated public APIs. I think we can agree this is not [GraphQL's Sweet Spot](https://productionreadygraphql.com/blog/2020-05-14-sweetspot). |
There was a problem hiding this comment.
I would also add that unlike other APIs, with GraphQL, because of its static nature, you can and do have tools that help you with these calculations instead of only creating ad-hoc solutions per endpoint
|
|
||
| Many GraphQL critics talk about the N+1 problem and DataLoader. It's true that a GraphQL API must be ready for many query shapes and use cases. It is wise to implement efficient data loader for most fields through dataloaders. In fact, that's why I don't recommend using datafetching techniques that are overly coupled to the query shape, things like AST analysis, lookaheads, and things using context from sibling or parent fields. But an honest observer should acknowledge that this is a problem with REST as well. As the complexity of an endpoint or operation increases, an engineer should expect to have to make more trade-offs in the name of performance. | ||
|
|
||
| Overall I think dataloader is a requirement for GraphQL, and I agree with critics that it's part of the slight complexity add for a GraphQL API, even simple ones. Authorization N+1s are also an issue, though, again, REST has these issues as well. |
There was a problem hiding this comment.
I would say that its a complexity that everyone will get to eventually, but when you do get there, GraphQL offers more automated tools to handle these complexities instead of ad-hoc endpoint based solutions
|
|
||
| Arguably one of GraphQL's most powerful tool is around continuous evolution. The fact the client declaratively selects the API surface it is interested in means we can track with very high precision how our API is used. This allows us to actually **avoid** breaking changes, and make removals safely on fine grained parts of the schema. | ||
|
|
||
| Breaking changes and deprecations suck. We all try to avoid them, and yes it's annoying for clients. But if anything GraphQL makes this easier, not harder. |
There was a problem hiding this comment.
I would make that argument even stronger - in a case where you have a system, a service that runs for years and years.
there is no other technology other then GraphQL where you can know which fields its consumers are using in production right now.
Its hard to state the value of that knowledge on a legacy system
|
So happy we are having that blog post!! |
No description provided.