So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club.
Ignoring the noise is really becoming a key skill to survive as a programmer.
Ignoring the noise is really becoming a key skill to survive as a programmer.
IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working to better support this type of thing more directly/natively.
Plus not all of it is merely overexcitement/immaturity either, small companies and small dev teams often try to keep their toolsets small and eventually end up pigeonholing stuff into tech that doesn’t fit, until they get time/resources to do it properly. Some things are more obvious in retrospect.
The vast majority of the software world is still pretty conservative when you look beyond HN and Twitter.
In your own, exactly what point did you tried to make? Complaining that x and y technology users joined the "whoops" crowd when those technologies are in fact well established and proved to be effective if not nearly optimal in some applications, what do you perceive as "whoops"?
Frankly, it didn't seemed you had a point to make other than parroting cliches.
The Gartner Hype Cycle[1] has both a 'peak of inflated expectations' and a 'trough of disillusionment'.
The thing a lot of tech cynics fail to spot is that both of them are wrong about the long term value of the technology.
The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche.
I keep thinking of the tower of babel.
> God was concerned that humans had blasphemed by building the tower to avoid a second flood so God brought into existence multiple languages. Thus, humans were divided into linguistic groups, unable to understand one another.
see? Now you can be wrong with the rest of us :)
No wonder it feels like a clunky extra glue layer if it’s being used as one.
I looked at graphql and saw a return to the horror of DoSomethingBecauseItsMondayAndDueTomorrow() type API methods.
Hundreds or thousands of them that accumulate like cruft over time, and no one can delete anything because you have no idea what it'll break.
I stick with well designed and well planned REST APIs.
It's not a panacea, but it helps.
This is a problem with GraphQL, but you can monitor if anyone is requesting that data.
Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc.
GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful.
It depends if you're in that situation or not, or what parts of your domain are in those situations.
I don't think "GraphQL everywhere" is sane.
Most sane REST-like implementations also support this, typically with query string modifiers like a "fields" param or similar.
A lot of them also support deep relationships this way too.
For example, the Directus REST API is completely feature compatible with the GraphQL API.
- Request the users, their IDs, and emails, and their post ids
Or:
- Request the user, tons of profile information about them, and the posts with all the info about the posts
You'd have to implement all this filter stuff for REST - and at this point if you have a bunch of different queries, yeah GraphQL makes sense.
Again, as an example, Directus supports doing everything you just said over both REST and GraphQL.
There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever.
You may also want to take a look at HATEOAS and JSON:API and similar.
REST-like APIs have long had feature parity with GraphQL and also superior mechanisms for caching etc...
I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard.
GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if you think they have some aversion to POSTing JSON for a query.
Yes.
But not without reason.
GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs.
You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc...
This cost would be worth paying if GraphQL brought new and valuable capabilities, but as I've discussed, it doesn't really do that.
With REST endpoints, you have to really reason about entities and URL structure to design it properly. It's not easy, but it shouldn't be - it's meant to be a long-lived API contract based on document location, so you should spend time reasoning about the design.
GraphQL, in my experience (much like SOAP/WSDL) encourages lazy API development with the GetWidgetsByColorForArthurOnSunday() type functions. It requires additional libraries and tooling and a whole additional layer of complexity. It works against long-standing native browser functionality, and in many cases is just a solution in search of a problem since for most popular API consumption there's a client-side library that abstracts away details like transport.
Also, I personally dislike it because I can't use my preferred data mutation strategy, JSON-PATCH [1].
I also think GraphQL should never be used for updating data, just that it is nice for a segment of problems related to querying data.
Use the @deprecated directive on your schema.