Meh, everything in GraphQL can be defined as JSON. I fail to see the benefit (over just using JSON).
I definitely agree with the author's assertions as to how and why REST sucks. I'd also add that a big reason why REST sucks is that it is completely orthogonal to streaming. You're supposed to GET or POST never both at the same time.
Your web app has grown astronomically and the number of GET and POST calls are creating a massive overhead ("maybe we shouldn't have put so much state data in cookies."). So everyone gets together and decides WebSockets are a good solution... Because all your stuff was made with REST in mind you are now tasked with basically writing an entirely new API from scratch whereas if you used something like JSON-RPC you could just send the same exact API calls over the WebSocket and call it a day.
> You're supposed to GET or POST never both at the same time.
The standard says you can. The simplest way to add pagination is to POST your data with GET values overriding. I see no reason to use PUT or DELETE at all.
The pendulum swings back the other way. One of the advantages of (proper) REST is precisely that the returning payload is a server-defined, well-specced mediatype, so you know that responses always look the same way. GraphQL -- and literally any other client-driven query language, including SQL -- instead you ask for specific data items and have to case-by-case write the handling logic right after your request completes.
It's a trade-off, like any other. As another commenter said, this battle was fought many years ago with SQL, where it began to be considered good practice to formalize the APIs with stored procedures or abstract away from the backend tables by restricted-column views, instead of just accepting arbitrary queries against the raw table.
I'm in the process of re-writing an API and was looking at GraphQL just yesterday.
I'm trying to figure out if there is any environment/situation where GraphQL is not a good solution?
I'm moving everything to a lambda/microservice architecture, and it seems now I would have a single service managing all the api calls rather than using something like API Gateway to route to the correct lambda.
I can't think of one (other than FB) where this is preferable over some form of REST (just go back to calling it HTTP actions or HTTP). Tying services together makes for more problems (as coupling often does), not less.
The very first point is either disingenuous or outright ignorant. "Gone is the mess of relying on an ever expanding set of predefined REST endpoints", moving that to the server logic is not "better". The number of code paths hasn't been reduced, just placed deeper in the execution path. How many months does it take the average developer to learn deep paths are worse than shallow ones?
Next, your result caching needs to be inserted in other places. As result caching is no longer at a predictable location AND mixed with other cached values (if you just keep caching everything at the request level) which makes splitting work more difficult.
Most of the sentences are restatements or vague assertions, until you get to the "type system". This part is where the "idea" stops seeming all that original, since webservices (in aggregate) define an application query system. You can always define what your APIs return so the "asking for the results you want" as if it's new, is a just a misunderstanding of how webservices work NOW.
Finally we get to the actual selling point. Ad-hoc results. Typically, if your using services, you know the common operations that need to be combined and probably, so do the vendors (sometimes that's yourself). Popping out a new endpoint for combined data (see: https://client.cdn77.com/support/api/version/2.0/data#Purge All vs Purge) or adding a GraphQL-esque query param is not all that unusual, except in edge cases where you have a giant graph database. This is not the common case.
On the one hand, when I read the open sourcing announcement, I found it enticing, too.
On the other hand, we have had this kind of thing for decades in the form of SQL. There, it is considered best practice to restrict the API by requiring callers to exclusively use stored procedures. Reasons are that they make it easier for the engine to optimize query evaluation, for the DBA to optimize the storage format to the queries to be run, for the security guys to enforce security, etc.
You can make the front-end API more flexible, but that doesn't remove the need to do that kind of back-end stuff.
Yes, I still like it, but I'm not sure it really simplifies stuff as much as it seems at first sight; to get performance you still have to tune the backed to the kind of queries that are run.
I'm in the process of rewriting our external api using GraphQL, It's kind of amazing, I do find my self tripping on "best practices" e.g. pertaining to a User view model
I definitely agree with the author's assertions as to how and why REST sucks. I'd also add that a big reason why REST sucks is that it is completely orthogonal to streaming. You're supposed to GET or POST never both at the same time.
Your web app has grown astronomically and the number of GET and POST calls are creating a massive overhead ("maybe we shouldn't have put so much state data in cookies."). So everyone gets together and decides WebSockets are a good solution... Because all your stuff was made with REST in mind you are now tasked with basically writing an entirely new API from scratch whereas if you used something like JSON-RPC you could just send the same exact API calls over the WebSocket and call it a day.