Clojurescripters liked to leverage GraphQL (david nolen)
Is GraphQL the Next Frontier for Web APIs?
11–20 of 74 posts
Re: Is GraphQL the Next Frontier for Web APIs?
#12Nah, 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.
> Nah, 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.
I certainly agree with the plug idea -- consistency is very good -- but I think that we should really consider what REST is actually buying us at the end of the day.
Most people prefer to integrate through a well-maintained SDK where one is available rather than shelling out to HTTP directly (imagine calling the APIs of something like AWS over raw HTTP), and if that's fairly widespread, it might not be too bad of a thing to start moving the underlying transmission protocol of those SDKs over to something that's more flexible and more efficient (like GraphQL, but also maybe other things).
A comparable analog might be when Google experimented with replacing TCP and TLS with a new protocol called QUIC that operates over UDP [1]. Because QUIC still exposes an HTTP/2 API, providers and server-side infrastructure could potentially move over to it relatively painlessly.
[1] https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp...
Re: Is GraphQL the Next Frontier for Web APIs?
#13Nah, 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 wher…
> 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?
Because, frankly, most people doing "REST" don't understand REST. While URLs can imply a tree structure, REST does not give URLs any meaning besides resource identifiers; relations are communicated in resource representations not URLs and can be any model you like.
There is a sense in which operations are essentially CRUD-like but, in the database analogy, it's CRUD operations against views with arbitrarily complex definitions, and trigger logic for operations other than reads, not CRUD against base tables.
> As in the article, what if I have operations which only make sense as a combination of CRUDs on different objects?
Then, most likely, you have a resource for the operation, which you create to initiate the operation (or create to configure and have a specified update to trigger.)
> What if my type system doesn't map nicely to a tree?
Then you don't use a tree representation REST doesn't need URLs as anything other thab opaque identifiers and resource representations can communicate any relationship structure you want.
> If the server is to my client side another library, why do I impose CRUD on every operation and pretend that this makes sense?
Well, one, CRUD against resources with unconstrained definitions is part fairly flexible and universal model, so it probably makes sense as long as you don't artificially constrain the model, and second, REST isn't always the right choice anyway. There is nothing wrong with doing RPC or other non-REST things (and it would be better if we could accept that so people could stop feeling obligated to say that the non-REST things they are doing are "REST" and muddying the waters.)
Re: Is GraphQL the Next Frontier for Web APIs?
#14I don't know for web external APIs but for an internal network of services talking to each other I've found GraphQL to be very convenient. The "single entry point" and "describe what you want, you'll get what you described" mindset makes it powerful, when used with the graphiql trial and error interface. We barely have to document anything anymore. It seems a bit weird to use a twisted json for the queries but it works well after getting used to it. If someone wants to go this road, I'd suggest enforcing use of variables in queries (so high level caching works better) and do directly to the connection modelfor pagination.
http://graphql.org/learn/queries/#variables http://graphql.org/learn/pagination/
Re: Is GraphQL the Next Frontier for Web APIs?
#15Personally, I found the description of (G)RPC intriguing, since the API that I've been building recently for a project resembles this most closely. I had started by trying to follow REST, then over time in an effort to reduce and simplify network requests, the API became a collection of, basically, remote function calls - organized as a map of "actions" on both client and server. I'm still pretty much a novice at building APIs, though, so the article was educational for me to compare the pros and cons of various approaches.
Re: Is GraphQL the Next Frontier for Web APIs?
#16REST is horrible. It encourages new developers to think in terms of CRUD, which is also horrible. (https://msdn.microsoft.com/en-us/library/ms978509.aspx).
RPC is great. It encourages developers to think in terms of functions and leverage more creative ways of getting things done. Event Sourcing, CQRS, etc.
GraphQL is really neither here nor there. It's more of a convention on top of those layers. I think it's a good idea, and a good convention for libraries in different languages to rally around. Though it can be abused too: don't use it to replace a fairly simple set of REST-style queries just because you can.
Is GraphQL the future? It may be part of it. But, it's not everything. It's just a query language. Okay there's a mutation part of the spec too, and it's CRUD-like. I'd like GraphQL better if there was a more RPC-like mutation.
I hope the future includes some more interesting streaming-style protocols. The whole request/response thing is pretty boring anymore no matter how you do it.
Re: Is GraphQL the Next Frontier for Web APIs?
#17We tried to use GraphQL, but it in our opinion it has a major design flaw: not everything that can be expressed in JSON can be expressed in GraphQL. Since our application makes heavy use of Semantic Web (if you haven't already, checkout SPARQL and RDF which made similar promises). But this means we often end up with responses that contain URIs as map keys. This is not allowed as a filter in GraphQL, even though it is valid JSON. Other parts of our stack contain Clojure(Script), and we make use of namespaced keywords that serialize to "foo/bar" as map keys. Again something that is not allowed in the language, and would break our application. I find it a particularly odd design choice to not make GraphQL spec match the JSON spec. As there are now many things that are impossible to specify as a query, which would otherwise be valid JSON.
Re: Is GraphQL the Next Frontier for Web APIs?
#18REST is horrible. It encourages new developers to think in terms of CRUD, which is also horrible. ( https://msdn.microsoft.com/en-us/library/ms978509.aspx ). RPC is great. It encourages developers to think in terms of functions and leverage more creative ways of getting things done. Event Sourcing, CQRS, etc. GraphQL is really neither here nor there. It's more of a convention on top of those layers. I think it's a go…
I have a fairly dumb question. If one were building a standard web app... say, a super simple web store that lists products, allows someone to submit products and such. How would they use RPC instead of rest? Can you give some concrete examples of how it's different / better.
Re: Is GraphQL the Next Frontier for Web APIs?
#19REST is horrible. It encourages new developers to think in terms of CRUD, which is also horrible. ( https://msdn.microsoft.com/en-us/library/ms978509.aspx ). RPC is great. It encourages developers to think in terms of functions and leverage more creative ways of getting things done. Event Sourcing, CQRS, etc. GraphQL is really neither here nor there. It's more of a convention on top of those layers. I think it's a go…
REST is horrible. It encourages new developers to think in terms of CRUD, which is also horrible.
It encourages developers to think in terms of data, which is amazing. At the end of the day, we're just doing data transformations, that's it. GraphQL is an interesting iteration on that idea, because it focuses more on the data.
REST is simply a way to design your APIs so that they're extensible, usable, and maintainable. If you're doing something really specific, maybe it's not the best thing, but it's a really good starting point.
As per your CQRS comment.... https://martinfowler.com/bliki/CQRS.html
"Despite these benefits, you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base that is updated in the same way that it's read, adding CQRS to such a system can add significant complexity. I've certainly seen cases where it's made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team. So while CQRS is a pattern that's good to have in the toolbox, beware that it is difficult to use well and you can easily chop off important bits if you mishandle it."
Re: Is GraphQL the Next Frontier for Web APIs?
#20I can see three contenders:
1. CRDTs/sync solutions (like Firebase)
2. GraphQL with real-time subscriptions
3. A variant of REST over WebSockets with real-time subscriptions
I don't think #1 will be able to cover all necessary use cases because it is much more computationally expensive (in terms of memory, CPU and bandwidth). Both #2 and #3 are good solutions but I think #3 will prevail in the end because it's a lot simpler.
You can break-up RESTful resources into individual fields which each have their own independent real-time subscriptions (so each observable model on the front end can hold a single property of a resource). With GraphQL, you may end up with overlapping fields between different 'views' and it makes it harder to track/manage subscriptions.