Con: Unpredictable code paths (at least in complex use cases).<p>I've seen so many times GraphQL implementations or ad-hoc equivalents with user supplied property and filter requests, that regret giving the caller so much flexibility. IME, flexibility is a bad thing because in the API world, often once you cross a feature bridge, there's no going back. I say be very restrictive in your API for many reasons. And for that UI use case, I disagree with a complete client-side/server-side dev separation. Unlike data APIs, backend data requests for frontend use should be tightly tailored to what is used. GraphQL is just another way to forget what you've exposed and also allow clients to hit never before seen code paths to your backend. There are security, bloat, and maintenance concerns...keep the UI backend thin and light and inflexible and strict and limited yet agile and volatile and you'll be so happy you did a couple years down the road.
This is kind of touched on by other comments here, but after using GraphQL heavily on a bunch of different projects for both native apps and web UI front ends, one of the biggest benefits I've seen is how it enables the individual teams (front end and back end) to work faster, more efficiently, and more independently.<p>Our dev process for using GraphQL:<p>1. Product and design come up with screen designs and workflows.<p>2. Importantly, the <i>front end teams</i> then take a first stab at writing the GraphQL type contracts, fully doc'ed (we use a Node backend, so it's easy for the front end folks, even native app devs, to know enough JS to write these type strings). They then confer with backend folks on the contract to get agreement, and front end folks write mock endpoints for these contracts. This allows the front end teams to get off to the races early with a working (albeit mocked out) backend. Since the GraphQL type contracts are optimized to closely match the front end screens, it makes the front ends <i>much</i> simpler. With native apps it also means there are a lot more things we can fix with just a server change, not requiring an app store release.<p>3. Backend folks then start implementing the GraphQL resolvers, which in our architecture is mainly orchestrating microservices. The great thing about GraphQL here is that it essentially serves as a "decoupling layer", giving the backend folks a lot more freedom to change and switch up the microservices as long as the GraphQL contract is still respected.<p>4. Once the GraphQL resolvers are done, we switch out the mock resolvers. Usually there are a couple of edge cases or other bugs to fix, but for the most part we've seen very little disconnect.
The backend scaling/complexity problems originate in the database, its kind of cute the way they put it: "Making the graph-oriented way of getting data fit over an SQL database can be tricky." Tricky vastly understates this: we are talking about ORM, the "vietnam of computer science"<p>Clojure ecosystem has an immutable database, Datomic, which is designed for functional programming and fully solves the impedance mismatch. Datomic "Pull queries" is essentially GraphQL – and even predates GraphQL by a year!<p>Unlike GraphQL, Datomic is also a real database, competitive with SQL and can express relational filters and joins. Datomic is designed for the read-heavy data modeling loads that, today, SQL (and mongo, etc) is used for in anger. <a href="https://www.datomic.com/" rel="nofollow">https://www.datomic.com/</a>
I've still not seen tooling in the Python ecosystem to make a GraphQL API actually safe to expose to the internet -- without query complexity policing, a malicious client can construct queries that will take an effectively infinite amount of time to complete, and take out your DB connection.<p>Github handles this problem: <a href="https://developer.github.com/v4/guides/resource-limitations/" rel="nofollow">https://developer.github.com/v4/guides/resource-limitations/</a><p>Is this something that's generally solved in other languages? (I've seen a few plugins on NPM that tackle the problem). Or is this just not something that implementors are worrying about?
Most GraphQL presentations I have seen tend to construct the following strawman scenario:<p>- we have a REST API that forces the client to make too many requests
- it's impossible to fix the REST API for some reason
- the app is slow because of the multiple REST API calls<p>The followup:<p>- we bring in GraphQL and everything becomes super fast and efficient
- the people who couldn't provide an efficient REST API, can all the sudden provide a GraphQL interface
- the cost of implementing and maintaining GraphQL is usually glossed over<p>The reality is that GraphQL has a lot of drawbacks that are overlooked:<p>- it might be cheaper to fix the REST API than to implement GraphQL
- it's one extra service or module(if you are lucky) on your backend to look after
- protecting the database from bad queries becomes an order of magnitude harder
- you will have to maintain an additional GraphQL schema
- the client side tooling for GraphQL is far from simple<p>Depending on your needs, it might still be worth it, I would just wish that GraphQL presentations would be more honest about these.
Adding to the pros:<p>Self Documenting - GraphQL documents the shape of responses properly. It's like Swagger if the spec always actually matched the implementation. This is a big win for everyone. Backend doesn't have to think about updating separate documentation, frontend always has an up to date and accurate spec.
If you go down the GraphQL path be aware you are trading the simplicity, flexibility and universality of HTTP, which you can debug via cURL, to a custom protocol and fat client owned by Facebook. It isn’t even an open standard. The last time Facebook tried to make HTML better we got FBML, remember that?<p>Be wary of tech that promises to solve all your problems that you yourself don’t understand and haven’t solved. You’re going to end up with at best another set of problems.
> A GraphQL API (server) implementation, out of the box, will have better performance than a standard REST API - for the clients. Since resolvers are called in parallel, data will load faster.<p>What does this mean? Are these theoretical REST endpoints fetching information serially, or something?<p>Almost all of our REST endpoints fetch all of their information in a single hand-optimized SQL query. How is GraphQL going to run faster than that?
Coming from Mobile developers experience :<p>- Graphql does allow you to specify data you need and make the user experience better but this is only true in theory. Since in graphql it is so easy to ask any data there are high chances of your queries not optimized and you end up doing a complex operation spanning multiple domains because you can do it. In REST since domains are tightly defined chances of non-optimized request are less.<p>- Another major con with GraphQL on mobile is there are no alternatives than Apollo client yet. This ties you to 1 solution for your entire application.<p>- There are companies that tried to enable Querying over rest. Though it is not as flexible as GraphQL.
I don't see why "rich UI/UX-based applications" is listed as "mobile-first". Sure, GraphQL is probably great for highly dynamic client applications, but why would that be limited to mobile?<p>As far as I can tell, GraphQL primarily allows you to trade client flexibility for back-end complexity. If you're willing to take the additional complexity on the back-end, GraphQL allows you API clients to iterate far quicker, and removes (or at least lessens) the dependency of the client on the team maintaining the back-end. If that's not worth it to you, don't use GraphQL.
One huge benefit is that the client controls the response shape and the same server will power multiple different response schemes without requiring any changes. Very nice for supporting N types of clients.
Correct me if I'm wrong, but having read around the topic of GraphQL with a slowly-changing, largely static catalogue type appication in mind (ideal fit for CDN in front of REST); I remember a few horror stories around GraphQL not being CDN-friendly.<p>Perhaps if you have a dynamic or real-time data-lake or messaging-style app with quickly-stale data that would need to be talking to regional server clusters anyway, then GraphQL has benefits on top for schema independence etc. But I wonder if its CDN caching story has improved (not just client-side as mentioned.)
OCFX, it appears you've been shadowbanned. Your question is very good so reposting it here:<p>> Does anyone know how GraphQL manages (or if it even can) to sort and filter across microservices? It seems impossible to me to do from any client. If you have a list view that is made up of data from microservice a, b, and c and you try to sort on a column from microservice b, how does microservice b know how to sort then data when there are additional constraints applied to data on other microservices such as a filter applied to microservice a. Does that make sense?
Basically I feel very frustrated when it comes to sorting and filtering across microservices, some people at work think that GraphQL will solve this and I have found absolutely nothing to support the claim that it would help us with this. Thoughts?
One thing I'd like to add, if your primary data store resides in a document-oriented DB like Mongo or Dynamo, GraphQL provides that missing "relational" piece, and allows you to create a strong schema without having to manually do "joins" in application code. I realize attempting to "relationalize" a document store isn't how you were supposed to use it, when I started at my current company thats what they had going on. GraphQL was essential for improving the sanity of how we grab data from dynamo, and gave us a good way to iteratively migrate over to Postgres where appropriate.
Seriously they are both bad ideas (graphql and rest). Just create a remote method doing exactly what you need with a well-defined metaprotocol. It really doesn’t have to be so hard.
This reads like an Apollo ad.<p>I'll start off by noting that I haven't been keeping up as much with the latest developments within the GraphQL ecosystem so some of my comments may be outdated.<p>They ignored one of the most thorough GraphQL implementations: Sangria [0], which provides almost everything you need out of the box to implement a fairly sophisticated application. I guess that Scala isn't very cool. I'd reluctantly agree that most of the community seems to be centered around the JS ecosystem, but I don't think it's fair to so easily dismiss the dozens of GraphQL implementations out there. Perhaps I'm wrong about this, but based on the author's bio it sounds like they're most experienced with JS and Ruby, which means that they're probably heavily biased towards those two languages. I don't think they've seriously evaluated each library extensively and they should be transparent about it if that's the case. I've used GraphQL with Elixir, Node, and Ruby, but took a lot of inspiration from Sangria's docs when working on my apps.<p>I don't know if it was meant as a criticism, but I actually think that the declarative syntax used with Elixir and Ruby is quite nice. The examples provided for the reduced "Developer Experience" are rather weak in my view. I think the author might just be most comfortable with JS.<p>> Secondly, as said in the second point, a GraphQL API server needs optimisations and maintenance.<p>> Making the graph-oriented way of getting data fit over an SQL database can be tricky.<p>IMO, this is severely understating the complexity. Depending on the type of application, you should probably be prepared to have at least one engineer dedicated full-time to maintaining your GraphQL server.<p>It's a lot easier to write a secure REST API with good performance than it is to achieve the same thing with GraphQL. The author doesn't even mention anything about the huge headache involved with protecting against malicious queries.<p>I immediately fell in love with the idea of GraphQL when I first heard about it, but as I started to use it I found it wasn't some magical solution. You'll probably end up having to figure out a lot of stuff on your own since the technology is so young, so be prepared to invest a lot of time in it. It depends heavily on your use-case and your team's collective experience, but I'd probably lean towards avoiding GraphQL within a small team.<p>If race conditions aren't a concern, you can wrap a REST API with a small GraphQL server. The inverse is also possible.<p>There's no mention of file uploads. Although many GraphQL libraries include some form of file uploading capability, I'd suggest against using that and just creating separate endpoints for each upload type. Having a separate endpoint makes it way easier to place reasonable limits on input size, as well as rate-limiting those actions adequately. You can also handle streaming uploads, which I don't think most GraphQL libraries can handle; if I recall correctly the Node GraphQL server parses the whole body before executing any resolver.<p>[0] <a href="https://sangria-graphql.org/" rel="nofollow">https://sangria-graphql.org/</a>
Episode 27 of the Syntax podcast gives a good overview of GraphQL and its ecosystem. Demystified a lot for me. <a href="https://syntax.fm/show/027/graphql-here-is-what-you-need-to-know" rel="nofollow">https://syntax.fm/show/027/graphql-here-is-what-you-need-to-...</a>
This is a great summary of the reasons why I initially dismissed GraphQL, and why I'm now a fan - having gone through a process of evaluating it against REST for a production API for a mobile app.<p>Great post.
Does anyone know how GraphQL manages (or if it even can) to sort and filter across microservices? It seems impossible to me to do from any client. If you have a list view that is made up of data from microservice a, b, and c and you try to sort on a column from microservice b, how does microservice b know how to sort then data when there are additional constraints applied to data on other microservices such as a filter applied to microservice a. Does that make sense?<p>Basically I feel very frustrated when it comes to sorting and filtering across microservices, some people at work think that GraphQL will solve this and I have found absolutely nothing to support the claim that it would help us with this. Thoughts?