The article pretty much sums up why I've been a bigger fan of OData than GraphQL, especially in the business cases. OData will still let you get all those same wins that GraphQL does but without a sql-ish query syntax, and sticking to the REST roots that the web works better with. Also helps that lots of Microsoft services work out of the box with OData.
GraphQL: The enterprise honeymoon is over
11–20 of 241 posts
Re: GraphQL: The enterprise honeymoon is over
#12> The main problem GraphQL tries to solve is overfetching.
My issue with this article is that, as someone who is a GraphQL fan, that is far from what I see as its primary benefit, and so the rest of the article feels like a strawman to me.
TBH I see the biggest benefits of GraphQL are that it (a) forces a much tighter contract around endpoint and object definition with its type system, and (b) schema evolution is much easier than in other API tech.
For the first point, the entire ecosystem guarantees that when a server receives an input object, that object will conform to the type, and similarly, a client receiving a return object is guaranteed to conform to the endpoint response type. Coupled with custom scalar types (e.g. "phone number" types, "email address" types), this can eliminate a whole class of bugs and security issues. Yes, other API tech does something similar, but I find the guarantees are far less "guaranteed" and it's much easier to have errors slip through. Like GraphQL always prunes return objects to just the fields requested, which most other API tech doesn't do, and this can be a really nice security benefit.
When it comes to schema evolution, I've found that adding new fields and deprecating old ones, and especially that new clients only ever have to be concerned with the new fields, is a huge benefit. Again, other API tech allows you to do something like this, but it's much less standardized and requires a lot more work and cognitive load on both the server and client devs.
Re: GraphQL: The enterprise honeymoon is over
#13My hot take is that if you’re using GraphQL without Relay, you’re probably not using it to its full potential.
I’ve used both Relay and Apollo Client on production, and the difference is stark when the app grows!
Re: GraphQL: The enterprise honeymoon is over
#14I don't like GraphQL, it feels strange for me (for my rest brain)
despite many Rest flaw that I know that it feels tedious sometimes, I still prefer that
and now with AI that can scaffold most rest. the pain point of rest mostly "gone"
now that people using a lot of Trpc, I wonder can we combine Grpc + rest that essentialy typesafe and client would be guaranteed to understand how model response look ?????
Re: GraphQL: The enterprise honeymoon is over
#15I wish, plenty of SaaS their main query API is GraphQL.
Re: GraphQL: The enterprise honeymoon is over
#16What I liked about GraphQL was the fact that I only have to add a field in one place (where it belongs in the schema) and then any client can just query it. No more requests from Frontend developers like „Hey, can you also add that field to this endpoint? Then I don’t have to make multiple requests“. It just cuts that discussion short.
I also really liked that you can create a snapshot of the whole schema for integration test purposes, which makes it very easy to detect breaking changes in the API, e.g. if a nullable field becomes not-nullable.
But I also agree with lots of the points of the article. I guess I am just not super in love with REST. In my experience, REST APIs were often quite messy and inconsistent in comparison to GraphQL. But of course that’s only anecdotal evidence.
Re: GraphQL: The enterprise honeymoon is over
#17I'm probably about as qualified to talk about GraphQL as anyone on the internet: I started using it in late 2016, back when Apollo was just an alternate client-side state/store library.
The internet at large seems to have a fundamental misunderstanding about what GraphQL is/is not.
Put simply: GQL is an RPC spec that is essentially implemented as a Dict/Key-Value Map on the server, of the form: "Action(Args) -> ResultType"
In a REST API you might have
app.GET("/user", getUser)
app.POST("/user", createUser)
{
"getUser": getUser,
"createUser": createUser,
}
The arguments and output shape of your API routes are typed, like in OpenAPI/OData/gRPC.
That's all GraphQL is.
Re: GraphQL: The enterprise honeymoon is over
#18> The main problem GraphQL tries to solve is overfetching. My issue with this article is that, as someone who is a GraphQL fan, that is far from what I see as its primary benefit, and so the rest of the article feels like a strawman to me. TBH I see the biggest benefits of GraphQL are that it (a) forces a much tighter contract around endpoint and object definition with its type system, and (b) schema evolution is muc…
Agree whole-heartedly. The strong contracts are the #1 reason to use GraphQL.
The other one I would mention is the ability to very easily reuse resolvers in composition, and even federate them. Something that can be very clunky to get right in REST APIs.
Re: GraphQL: The enterprise honeymoon is over
#19I dunno. I still really like Lighthouse (for Laravel).
It's about the only thing about my job I still do like.
The difference is that it is schema-first, so you are describing your API at a level that largely replaces backend-for-frontend stuff. If it's the only interface to your data you have a lot less code to write, and it interfaces beautifully with the query builder.
I tend not to use it in unsecured contexts and I don't know if I would bother with GraphQL more generally, though WP-GraphQL has its advantages.
Re: GraphQL: The enterprise honeymoon is over
#20A blog post about GraphQL in an enterprise setting, that fails to address the biggest GQL feature for enterprises. Not unlike most material on HN about microservices. Federated supergraph is the killer feature imo.