Is GraphQL the Next Frontier for Web APIs?
brandur.org
Is GraphQL the Next Frontier for Web APIs?
1–10 of 74 posts
Re: Is GraphQL the Next Frontier for Web APIs?
#2Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of improving developer ergonomics in an increasingly predictable world.
This is like everyone finally agreed on a plug type, and someone starts to push 3 phase. Let's get all the houses wired up, instead.
Re: Is GraphQL the Next Frontier for Web APIs?
#3It's probably not super popular to suggest that REST isn't the be-all and end-all when it comes to web APIs, but I'm interested in a future that lets us integrate with APIs more quickly and more safely. I'm interested to hear about what people think about the subject.
(I'm the author.)
Re: Is GraphQL the Next Frontier for Web APIs?
#4Our front end guys use it at work. They seem excited about it. It actually makes a lot of sense to me, but I haven't used it myself except for their quick star wars demo when it was first announced.
Re: Is GraphQL the Next Frontier for Web APIs?
#5Yes it probably is. Back when I worked on LDAP, we found that people were using the protocol in unexpected ways, basically as a standardized general purpose record/field/value/query access protocol. They were doing this quite strange thing because it appeared to them better than the alternatives which were : use the underlying database access protocol (usually proprietary and undocumented) or roll their own HTTP-based thing, inventing most of the rules and encoding mechanisms themselves (sound familiar??), or use some invented-by-committee thing such as CORBA.
GrahpQL I think is meeting a similar need but with the added advantage that it was designed for the task at hand, mostly not by a committee.
Re: Is GraphQL the Next Frontier for Web APIs?
#6By Betteridge's Law of Headlines, the answer is "No".
REST describes the architecture of the web, which most websites already conform to. Developers could design web APIs more like web pages, but standard media types must be adopted first. JSON-LD is a strong contender at that.
Re: Is GraphQL the Next Frontier for Web APIs?
#7Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of improving developer ergonomics in an increasingly predictable world. This is like everyone finally agreed on a plug type, and someone starts to push 3 phase. Let's get all the houses wired up, instead.
Have you ever actually used it? It does greatly improve developer ergonomics on the client side. Check out Apollo + React (or another framework).
Re: Is GraphQL the Next Frontier for Web APIs?
#8Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of improving developer ergonomics in an increasingly predictable world. This is like everyone finally agreed on a plug type, and someone starts to push 3 phase. Let's get all the houses wired up, instead.
I don't know enough to justify my opinion but I really really don't get REST. Having recently had to learn a lot of web stack in a short time REST was one of the most confusing parts, and I think it's because it intrinsically doesn't make sense. I have a client and a server, they need to share a language so that the client can tell the server what do do.
REST seems like jumping from that situation to a situation where you have an object hierarchy modelled as a tree and can only perform CRUD. But why? As in the article, what if I have operations which only make sense as a combination of CRUDs on different objects? What if my type system doesn't map nicely to a tree? Why am I forcing this interface through a step of serializing it into a set of actions that it doesn't naturally map to and don't individually make sense?
In most programming languages you import a library with a set of functions or classes, and call them with parameters (binding on key-value or order or both).
If the server is to my client side another library, why do I impose CRUD on every operation and pretend that this makes sense? It's like a programming language where instead of calling a function, you have four modes of calling a function which must map to CRUD, (these have different conventions for the same thing (body vs querystring)) although there are no guarantees that they actually do map to CRUD lots of people don't follow the convention properly and everyone insists that you must try to adhere to it as purely as possible in the name of "standardization".
Re: Is GraphQL the Next Frontier for Web APIs?
#9By Betteridge's Law of Headlines, the answer is "No". REST describes the architecture of the web, which most websites already conform to. Developers could design web APIs more like web pages, but standard media types must be adopted first. JSON-LD is a strong contender at that.
> By Betteridge's Law of Headlines, the answer is "No".
I feel a little bad for phrasing a title like a question, but an alternative working title was "The Future of API Paradigms". I tried to touch on a variety of possible paths beyond GraphQL, including that REST might be the right way forward.
> REST describes the architecture of the web, which most websites already conform to. Developers could design web APIs more like web pages, but standard media types must be adopted first. JSON-LD is a strong contender at that.
Yes, quite possible, but it seems to me that REST and hypermedia aren't actually buying us all that much when it comes to APIs. Theoretically it makes them more discoverable and future proof, but in practice I find that no one really uses these features, and even when they're available, they're often used improperly.
On the other hand, something like GraphQL has some pretty significant advantages in the form of very flexible querying and very efficient message transport (you get everything in one call instead of _N_).
Re: Is GraphQL the Next Frontier for Web APIs?
#10Yes it probably is. Back when I worked on LDAP, we found that people were using the protocol in unexpected ways, basically as a standardized general purpose record/field/value/query access protocol. They were doing this quite strange thing because it appeared to them better than the alternatives which were : use the underlying database access protocol (usually proprietary and undocumented) or roll their own HTTP-base…
> GraphQL I think is meeting a similar need but with the added advantage that it was designed for the task at hand, mostly not by a committee.
Right on. I think that its early strength of opinion and design and having a spec available from the get-go is one of GraphQL's big strengths.
There are lots of ideas about how to use REST and HTTP correctly, but for the most part the only things that are universally agreed on are that URLs are _usually_ resources (you can find lots of cases where they're not even in APIs that are popularly thought to be well designed) and that HTTP verbs _should_ map to CRUD (but again, they often don't because ideas like `PATCH` only became widespread quite late in the game).