11 ms·

Why use GraphQL, good and bad reasons

186 points by vvoyer 8y ago

Vinnl 8y ago
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? 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.
- i_s 8y ago
  Often, it isn't on net more complexity on the backend, because the alternative is having to maintain more endpoints.
- sametmax 8y ago
  It appeals to big structures, because they often have many clients but much less backend endpoints. If you have one server side code base but targets the web, the mobile, an customer api, a desktop client and embeded devices, it's a net win. However, if you just have web + mobile, the complexity may not be worth it.
- chacham15 8y ago
  I think the reason which the author glossed over is because it reduces the number of RTTs between the front and back end. On desktop, you typically have a much better internet connection where packets are less likely to get dropped and will generally arrive faster meaning that the performance impact of having a large number of RTTs is much less than on mobile.
dustingetz 8y ago
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" 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! 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. https://www.datomic.com/ https://www.datomic.com/
- SmirkingRevenge 8y ago
  Before clicking through, I never knew that datomic has dependancies on AWS specific services. That's a serious downside, for many cases.
  - bhurlow 8y ago
    Datomic "on premise" version is not dependent on any AWS services and can be run on any box using vanilla java
  - bpicolo 8y ago
    You can use a variety of different backends as the data store.
  - dsp1234 8y ago
    There appears to be an on premesis version, which doesn't use AWS services. https://www.datomic.com/on-prem.html https://www.datomic.com/on-prem.html
  - Scarbutt 8y ago
    That threw me away, worse is that the cloud version and on-premise are different products and not compatible. Is not something like RDS where you can just move your postgres setup to your own server or some other cloud service. As it just happened to you, you can see they are putting some effort in hiding on-premise from their front page. All their effor seems to be going to the cloud version.
- headcanon 8y ago
  I love clojure and appreciate what Datomic brings to the table, but it seems like you need the whole package (clojure backend) in order for the benefits to pay off. GraphQL is a much less risky proposal for most companies, since it can be implemented more iteratively, and is storage-layer agnostic.
  - dustingetz 8y ago
    Just different risks. Adopting GraphQL without also adopting Facebook's exotic graph datastore is the unknown-unknown sort of risk that eventually leads to intractable problems as demonstrated by Hibernate and a long history of ORM related failures, and it isn't even on the radar of 90% of GraphQL adopters, if HN comment activity is any indicator.
Justsignedup 8y ago
has anyone used JSON API? How does it compare to graphql? Did you find JSON API was better until you hit a certain size?
- Vinnl 8y ago
  For others as confused as I was: "JSON API" is not just "an API that returns JSON". Apparently it's a spec: http://jsonapi.org/ http://jsonapi.org/
  - wruza 8y ago
    Finally a graph QL that can actually return graphs. Otoh, I don’t get why it is breaking news at all. Figuring out that in some cases you better interchange graphs and implementing a simple json-query-walker is a task for a day or two. You don’t need to go through The Era of REST or The Age of RPC to do that, neither is it a stellar innovation. Where are all the hackers gone?
    - deleted 8y ago
      [deleted]
- headcanon 8y ago
  We maintain an Ember app that uses JSON API, as well as a graphQL schema that both touch the same data. JSON API is well suited to Ember, since it manages data relationships client-side with its heavy data layer. GraphQL makes the backend a bit more complex (but not overly so IMO), but the tradeoff is that it abstracts the backend better than JSON API and allows new clients to be spun up more quickly since the data aspect is already taken care of, and the clients only need to be a view layer.
- hiccuphippo 8y ago
  I think the problem with it is it solves the transport but you still have to deal with the shape of the data.
- boromisp 8y ago
  We are using it heavily, and with a few extensions (like a batch modification endpoint) it scales pretty well. I'm not sure what measure of size are you referring to.
krn 8y ago
Why would one choose GraphQL over gRPC for a native iOS / Android app?
- masklinn 8y ago
  A composable and flexible RPC query format for the client and exploratory tooling. grpc is efficient, but it's the same rpc we've ever had with inflexible static calls and a bunch of roundtrips to do deep querying.
  - viiralvx 8y ago
    Yeah, I will also say that you can use gRPC with GraphQL as the API Gateway: https://iheanyi.com/journal/2018/05/12/the-g-unit-stack-go-graphql-and-grpc/ https://iheanyi.com/journal/2018/05/12/the-g-unit-stack-go-g... Kind of gives you the benefit of both.
aaronblohowiak 8y ago
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.
guiriduro 8y ago
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. 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.)
- PKop 8y ago
  Or for slowly changing, largely static pages, cache it all inside static html pages (Gatsby.js for example) and don't request any data on the client
- headcanon 8y ago
  Some GraphQL clients will create POST requests by default with the query as the data (Apollo does this), which should normally break caching, however there is no reason you couldn't append the query as a querystring param in a GET, which would help with that.
- accountantbob 8y ago
  I'm helping to move a big 10B per year ecommerce site to graphql. This lack of tooling support around graphql (vs REST) is a big minus currently. Some examples: CDN is a big one that you mention. Our vendor (the biggest in the industry) has no support for GraphQL beyond what they do for REST or html pages. We've talked about moving the query into the path or as a parameter but then we have to figure out how to determine what can be cached. With REST it is easy: cache /sku, /product, etc but never /guest, /order, etc. Tools that do performance monitoring (AppDyn, datadog, etc) don't grok GraphQL well. Quick example is response codes. What's the http status code of a graph response that has a partial failure? If you make it 200, then those tools won't see any errors. We put the error codes in the response body and those tools aren't parsing that for message failures.
  - filleokus 8y ago
ocfx 8y ago
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?
- boromisp 8y ago
  Edit: I don't believe GraphQL can provide any help with this. In cases like this you can always fall back to the naive solution: syncing the relevant data between microservices. Unless there is something like PostgreSQL's foreign data wrappers available.
- dustingetz 8y ago
  Datomic can fix this with cross-database queries, and I have more to talk about, email me if you are interested - email in profile
headcanon 8y ago
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.
TheAceOfHearts 8y ago
This reads like an Apollo ad. 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. 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. 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. > Secondly, as said in the second point, a GraphQL API server needs optimisations and maintenance. > Making the graph-oriented way of getting data fit over an SQL database can be tricky. 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. 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. 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. If race conditions aren't a concern, you can wrap a REST API with a small GraphQL server. The inverse is also possible. 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. [0] https://sangria-graphql.org/ https://sangria-graphql.org/
makkesk8 8y ago
Has anyone used odata? Do you prefer odata over graphql?
- WorldMaker 8y ago
  I used OData in a past life. From what I've seen GraphQL is more capable/tunable. OData feels a bit more constrained to relational models/particular ORMs, and GraphQL is more flexible to homogenize data from multiple sources. I've seen some very bad OData performance issues, and generally wouldn't recommend its use outside of intranet/enterprise/non-public projects these days. GraphQL seems at first glance worse, but the ability to name queries alone provides a lot of tuning power (making profiling easier, and allowing for the potential to performance tune individual query patterns) and most of the good GraphQL engines provide at least some basic cost estimation systems to quota high cost queries, whereas the cost estimation of OData operators is trickier. Though really a lot of it comes down to productivity needs. There's still cases where everything is on a single SQL server and Breeze against a simple OData endpoint on the SQL schema is, well, a breeze, for a simple client app. But I'm growing increasingly convinced that GraphQL is better in the long run, and I think a key need right now is much better server-side .NET GraphQL libraries that work well with EF, and have some of the profiling and cost estimation tools you see over in Apollo Engine and the like.
hn_throwaway_99 8y ago
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. Our dev process for using GraphQL: 1. Product and design come up with screen designs and workflows. 2. Importantly, the front end teams 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 much 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. 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. 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.
- toomim 8y ago
  How is that different than with REST? It sounds like the advantage you're citing is a separation of code into client and server, with a well-specified API between the two. You can write a well-specified API with either REST or GraphQL. Is there something about GraphQL in particular that is helping here?
  - tohjustin 8y ago
    I guess it's makes the front-end a whole lot easier to implement. To fetch all the data that the app needs to render on a single view, the code would only need to make a single API call to a graphql endpoint and you only have to deal with a single, neatly formatted response. As opposed to the traditional way of making multiple calls to different REST endpoints, you had to write quite a bit of code to transform & merge the data from each response before using them to render your views.
dustingetz 8y ago
OCFX, it appears you've been shadowbanned. Your question is very good so reposting it here: > 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?
- sokoloff 8y ago
  I "vouched" for that question (you also have enough karma to do that). Click on the timestamp of the question and you'll get an option to vouch for it as adding to the conversation.
- yubozhao 8y ago
  As of now, GraphQL server implementations that I know of, does not manage sort and filters for you. It is up to your resolver to handle those. In case of stitching schema together(for example, your own schema plus the GitHub one), you would need to pass the sort/filter to their services.
kodablah 8y ago
Con: Unpredictable code paths (at least in complex use cases). 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.
- ryanmarsh 8y ago
  This. Nearly every GraphQL schema I've seen is a logical representation of the domain, just like how we typically approach schema design in OO apps. This is probably fine in many contexts where your GraphQL endpoint is consumed by other internal services. However, if your GraphQL endpoint is used by consumer/public/external clients I feel like we need to give everyone permission to make a Schema matching the View Model, not the Model (proper). In practice GraphQL works quite nicely as a layer to translate the model proper into the view model. This makes MVVM much more attractive for SPA's than in object->relational worlds prior.
- boubiyeah 8y ago
  Another PRO of strict APIs is that they're dead simple to cache. Tons of customization = caching hell.
  - tylerhou 8y ago
    If you know your queries at compile time, then you can register each query with the server when you build as the hash of the query. Then clients only have to send up the hash and the server can look them up in its registry; plus you now have an easy way to cache (cache based on query hash plus user). If it's the first time you've seen a query, you can hash it and add it to the registry as well. See: https://github.com/apollographql/apollo-link-persisted-queries https://github.com/apollographql/apollo-link-persisted-queri... https://blog.apollographql.com/improve-graphql-performance-with-automatic-persisted-queries-c31d27b8e6ea https://blog.apollographql.com/improve-graphql-performance-w...
pranayairan 8y ago
Coming from Mobile developers experience : - 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. - 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. - There are companies that tried to enable Querying over rest. Though it is not as flexible as GraphQL.
- jahewson 8y ago
  I don’t see any difference between an app making making one non-optimised GraphQL request for the data it needs vs. making dozens of allegedly “optimised” REST requests for that same data. If the API designer didn’t anticipate that use case then it’s going to be slow either way. Probably slower with REST due to the extra HTTP traffic, loss of query batching, etc.
- sgk284 8y ago
  Re: specifying data - In my experience, you always want to overfetch anyway if you want your offline experience to be any level of reasonable. It's pretty lame when you're offline, see an item in a list, click on the item, and then the new view has no additional information that wasn't already in the list. That said, I've built a fairly sizable GraphQL API at my startup (https://banter.fm https://banter.fm) and am pretty happy with it, though not 100% convinced I'd use it again.
atom_arranger 8y ago
Adding to the pros: 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.
theptip 8y ago
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. Github handles this problem: https://developer.github.com/v4/guides/resource-limitations/ https://developer.github.com/v4/guides/resource-limitations/ 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?
asciimo 8y ago
Episode 27 of the Syntax podcast gives a good overview of GraphQL and its ecosystem. Demystified a lot for me. https://syntax.fm/show/027/graphql-here-is-what-you-need-to-know https://syntax.fm/show/027/graphql-here-is-what-you-need-to-...
orefalo 8y ago
It's pretty simple... do access the DB (assuming it's SQL) do you prefer SQL or PLSQL.
danpalmer 8y ago
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. Great post.
iEchoic 8y ago
> 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. What does this mean? Are these theoretical REST endpoints fetching information serially, or something? 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?
- tango12 8y ago
  This. Exactly this! I think anyone with experience will realise that you can get pretty much all the benefits of GraphQL with just a more sophisticated RESTish API. There is however, one thing that I think GraphQL backends have that REST backends don't, and that's the idea of introspection. Every GraphQL backend must be able to serve it's API data models and types. And I think the community tooling that leverages this makes it an amazing experience for app developers. No SDKs, any GraphQL client works with any GraphQL backend. Codegen esp for Android type apps to skip boilerplate of mapping APIs to POJOs. IDE autocomplete. I really think that the killer feature of GraphQL is that. We built a JSON DSL over a normal POST endpoint. Most GraphQL advantages sound "not really true" to me because you can always achieve the same thing (almost) yourself anyway.
  - iEchoic 8y ago
    Yup, agreed - the developer experience and the self-documenting nature of GraphQL is a big plus. I no longer use GraphQL, but this is something I miss about it. As you mention though, people often don't realize that GraphQL is just a way to tell an endpoint that you want information in a generic way, and a pattern for having that endpoint resolve information in a generic way. It's an abstraction on top of a normal service call, and like most abstractions, it gives you consistency and ease-of-use but not any new capabilities you didn't have before.
  - sixdimensional 8y ago
    Just wanted to chime in, OData had basically the same idea, however, from personal observation, somehow just didn't really become so popular, maybe because of its original association with Microsoft, etc. and also partially maybe its implementation. But it was pretty close, and today a lot of products support OData. I did note recently while reviewing the Microsoft API standard guidelines they share on GitHub [1], that there is a non-OData standard, but OData like recommendation for working with queries across collections, which I find to be pretty good and pretty generic. It seems like today you can do what you said - a sophisticated RESTish API without the model metadata piece pretty easily - but that metadata piece adds a lot of value. [1] https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#9-collections https://github.com/Microsoft/api-guidelines/blob/vNext/Guide... - see sections on sorting, filtering etc.
chvid 8y ago
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.
iamleppert 8y ago
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? 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.
- nicolasd 8y ago
  That's not true. "GraphQL requests" are _just_ POST requests with a JSON that contains "query" and "variables". So it's not the request itself that is not debuggable, but maybe the query interpreter on your backend with the framework you're using.
  - iamleppert 8y ago
    Have you ever seen one? They are impossible to formulate with simple tools like curl on the command line. So my original point stands.
ravitation 8y ago
Good and bad reasons to use something are not the same thing as pros and cons...
voidr 8y ago
Most GraphQL presentations I have seen tend to construct the following strawman scenario: - 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 The followup: - 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 The reality is that GraphQL has a lot of drawbacks that are overlooked: - 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 Depending on your needs, it might still be worth it, I would just wish that GraphQL presentations would be more honest about these.

186 points by vvoyer 8y ago

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? 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.

i_s 8y ago
Often, it isn't on net more complexity on the backend, because the alternative is having to maintain more endpoints.
sametmax 8y ago
It appeals to big structures, because they often have many clients but much less backend endpoints. If you have one server side code base but targets the web, the mobile, an customer api, a desktop client and embeded devices, it's a net win. However, if you just have web + mobile, the complexity may not be worth it.
chacham15 8y ago
I think the reason which the author glossed over is because it reduces the number of RTTs between the front and back end. On desktop, you typically have a much better internet connection where packets are less likely to get dropped and will generally arrive faster meaning that the performance impact of having a large number of RTTs is much less than on mobile.

dustingetz 8y ago

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" 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! 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. https://www.datomic.com/ https://www.datomic.com/

SmirkingRevenge 8y ago
Before clicking through, I never knew that datomic has dependancies on AWS specific services. That's a serious downside, for many cases.
- bhurlow 8y ago
  Datomic "on premise" version is not dependent on any AWS services and can be run on any box using vanilla java
- bpicolo 8y ago
  You can use a variety of different backends as the data store.
- dsp1234 8y ago
  There appears to be an on premesis version, which doesn't use AWS services. https://www.datomic.com/on-prem.html https://www.datomic.com/on-prem.html
- Scarbutt 8y ago
  That threw me away, worse is that the cloud version and on-premise are different products and not compatible. Is not something like RDS where you can just move your postgres setup to your own server or some other cloud service. As it just happened to you, you can see they are putting some effort in hiding on-premise from their front page. All their effor seems to be going to the cloud version.
headcanon 8y ago
I love clojure and appreciate what Datomic brings to the table, but it seems like you need the whole package (clojure backend) in order for the benefits to pay off. GraphQL is a much less risky proposal for most companies, since it can be implemented more iteratively, and is storage-layer agnostic.
- dustingetz 8y ago
  Just different risks. Adopting GraphQL without also adopting Facebook's exotic graph datastore is the unknown-unknown sort of risk that eventually leads to intractable problems as demonstrated by Hibernate and a long history of ORM related failures, and it isn't even on the radar of 90% of GraphQL adopters, if HN comment activity is any indicator.

Justsignedup 8y ago

has anyone used JSON API? How does it compare to graphql? Did you find JSON API was better until you hit a certain size?

Vinnl 8y ago
For others as confused as I was: "JSON API" is not just "an API that returns JSON". Apparently it's a spec: http://jsonapi.org/ http://jsonapi.org/
- wruza 8y ago
  Finally a graph QL that can actually return graphs. Otoh, I don’t get why it is breaking news at all. Figuring out that in some cases you better interchange graphs and implementing a simple json-query-walker is a task for a day or two. You don’t need to go through The Era of REST or The Age of RPC to do that, neither is it a stellar innovation. Where are all the hackers gone?
  - deleted 8y ago
    [deleted]
headcanon 8y ago
We maintain an Ember app that uses JSON API, as well as a graphQL schema that both touch the same data. JSON API is well suited to Ember, since it manages data relationships client-side with its heavy data layer. GraphQL makes the backend a bit more complex (but not overly so IMO), but the tradeoff is that it abstracts the backend better than JSON API and allows new clients to be spun up more quickly since the data aspect is already taken care of, and the clients only need to be a view layer.
hiccuphippo 8y ago
I think the problem with it is it solves the transport but you still have to deal with the shape of the data.
boromisp 8y ago
We are using it heavily, and with a few extensions (like a batch modification endpoint) it scales pretty well. I'm not sure what measure of size are you referring to.

krn 8y ago

Why would one choose GraphQL over gRPC for a native iOS / Android app?

masklinn 8y ago
A composable and flexible RPC query format for the client and exploratory tooling. grpc is efficient, but it's the same rpc we've ever had with inflexible static calls and a bunch of roundtrips to do deep querying.
- viiralvx 8y ago
  Yeah, I will also say that you can use gRPC with GraphQL as the API Gateway: https://iheanyi.com/journal/2018/05/12/the-g-unit-stack-go-graphql-and-grpc/ https://iheanyi.com/journal/2018/05/12/the-g-unit-stack-go-g... Kind of gives you the benefit of both.

aaronblohowiak 8y ago

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.

guiriduro 8y ago

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. 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.)

PKop 8y ago
Or for slowly changing, largely static pages, cache it all inside static html pages (Gatsby.js for example) and don't request any data on the client
headcanon 8y ago
Some GraphQL clients will create POST requests by default with the query as the data (Apollo does this), which should normally break caching, however there is no reason you couldn't append the query as a querystring param in a GET, which would help with that.
accountantbob 8y ago
I'm helping to move a big 10B per year ecommerce site to graphql. This lack of tooling support around graphql (vs REST) is a big minus currently. Some examples: CDN is a big one that you mention. Our vendor (the biggest in the industry) has no support for GraphQL beyond what they do for REST or html pages. We've talked about moving the query into the path or as a parameter but then we have to figure out how to determine what can be cached. With REST it is easy: cache /sku, /product, etc but never /guest, /order, etc. Tools that do performance monitoring (AppDyn, datadog, etc) don't grok GraphQL well. Quick example is response codes. What's the http status code of a graph response that has a partial failure? If you make it 200, then those tools won't see any errors. We put the error codes in the response body and those tools aren't parsing that for message failures.
- filleokus 8y ago

ocfx 8y ago

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?

boromisp 8y ago
Edit: I don't believe GraphQL can provide any help with this. In cases like this you can always fall back to the naive solution: syncing the relevant data between microservices. Unless there is something like PostgreSQL's foreign data wrappers available.
dustingetz 8y ago
Datomic can fix this with cross-database queries, and I have more to talk about, email me if you are interested - email in profile

headcanon 8y ago

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.

TheAceOfHearts 8y ago

This reads like an Apollo ad. 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. 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. 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. > Secondly, as said in the second point, a GraphQL API server needs optimisations and maintenance. > Making the graph-oriented way of getting data fit over an SQL database can be tricky. 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. 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. 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. If race conditions aren't a concern, you can wrap a REST API with a small GraphQL server. The inverse is also possible. 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. [0] https://sangria-graphql.org/ https://sangria-graphql.org/

makkesk8 8y ago

Has anyone used odata? Do you prefer odata over graphql?

WorldMaker 8y ago
I used OData in a past life. From what I've seen GraphQL is more capable/tunable. OData feels a bit more constrained to relational models/particular ORMs, and GraphQL is more flexible to homogenize data from multiple sources. I've seen some very bad OData performance issues, and generally wouldn't recommend its use outside of intranet/enterprise/non-public projects these days. GraphQL seems at first glance worse, but the ability to name queries alone provides a lot of tuning power (making profiling easier, and allowing for the potential to performance tune individual query patterns) and most of the good GraphQL engines provide at least some basic cost estimation systems to quota high cost queries, whereas the cost estimation of OData operators is trickier. Though really a lot of it comes down to productivity needs. There's still cases where everything is on a single SQL server and Breeze against a simple OData endpoint on the SQL schema is, well, a breeze, for a simple client app. But I'm growing increasingly convinced that GraphQL is better in the long run, and I think a key need right now is much better server-side .NET GraphQL libraries that work well with EF, and have some of the profiling and cost estimation tools you see over in Apollo Engine and the like.

hn_throwaway_99 8y ago

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. Our dev process for using GraphQL: 1. Product and design come up with screen designs and workflows. 2. Importantly, the front end teams 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 much 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. 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. 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.

toomim 8y ago
How is that different than with REST? It sounds like the advantage you're citing is a separation of code into client and server, with a well-specified API between the two. You can write a well-specified API with either REST or GraphQL. Is there something about GraphQL in particular that is helping here?
- tohjustin 8y ago
  I guess it's makes the front-end a whole lot easier to implement. To fetch all the data that the app needs to render on a single view, the code would only need to make a single API call to a graphql endpoint and you only have to deal with a single, neatly formatted response. As opposed to the traditional way of making multiple calls to different REST endpoints, you had to write quite a bit of code to transform & merge the data from each response before using them to render your views.

dustingetz 8y ago

OCFX, it appears you've been shadowbanned. Your question is very good so reposting it here: > 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?

sokoloff 8y ago
I "vouched" for that question (you also have enough karma to do that). Click on the timestamp of the question and you'll get an option to vouch for it as adding to the conversation.
yubozhao 8y ago
As of now, GraphQL server implementations that I know of, does not manage sort and filters for you. It is up to your resolver to handle those. In case of stitching schema together(for example, your own schema plus the GitHub one), you would need to pass the sort/filter to their services.

kodablah 8y ago

Con: Unpredictable code paths (at least in complex use cases). 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.

ryanmarsh 8y ago
This. Nearly every GraphQL schema I've seen is a logical representation of the domain, just like how we typically approach schema design in OO apps. This is probably fine in many contexts where your GraphQL endpoint is consumed by other internal services. However, if your GraphQL endpoint is used by consumer/public/external clients I feel like we need to give everyone permission to make a Schema matching the View Model, not the Model (proper). In practice GraphQL works quite nicely as a layer to translate the model proper into the view model. This makes MVVM much more attractive for SPA's than in object->relational worlds prior.
boubiyeah 8y ago
Another PRO of strict APIs is that they're dead simple to cache. Tons of customization = caching hell.
- tylerhou 8y ago
  If you know your queries at compile time, then you can register each query with the server when you build as the hash of the query. Then clients only have to send up the hash and the server can look them up in its registry; plus you now have an easy way to cache (cache based on query hash plus user). If it's the first time you've seen a query, you can hash it and add it to the registry as well. See: https://github.com/apollographql/apollo-link-persisted-queries https://github.com/apollographql/apollo-link-persisted-queri... https://blog.apollographql.com/improve-graphql-performance-with-automatic-persisted-queries-c31d27b8e6ea https://blog.apollographql.com/improve-graphql-performance-w...

pranayairan 8y ago

Coming from Mobile developers experience : - 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. - 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. - There are companies that tried to enable Querying over rest. Though it is not as flexible as GraphQL.

jahewson 8y ago
I don’t see any difference between an app making making one non-optimised GraphQL request for the data it needs vs. making dozens of allegedly “optimised” REST requests for that same data. If the API designer didn’t anticipate that use case then it’s going to be slow either way. Probably slower with REST due to the extra HTTP traffic, loss of query batching, etc.
sgk284 8y ago
Re: specifying data - In my experience, you always want to overfetch anyway if you want your offline experience to be any level of reasonable. It's pretty lame when you're offline, see an item in a list, click on the item, and then the new view has no additional information that wasn't already in the list. That said, I've built a fairly sizable GraphQL API at my startup (https://banter.fm https://banter.fm) and am pretty happy with it, though not 100% convinced I'd use it again.

atom_arranger 8y ago

Adding to the pros: 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.

theptip 8y ago

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. Github handles this problem: https://developer.github.com/v4/guides/resource-limitations/ https://developer.github.com/v4/guides/resource-limitations/ 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?

asciimo 8y ago

Episode 27 of the Syntax podcast gives a good overview of GraphQL and its ecosystem. Demystified a lot for me. https://syntax.fm/show/027/graphql-here-is-what-you-need-to-know https://syntax.fm/show/027/graphql-here-is-what-you-need-to-...

orefalo 8y ago

It's pretty simple... do access the DB (assuming it's SQL) do you prefer SQL or PLSQL.

danpalmer 8y ago

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. Great post.

iEchoic 8y ago

> 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. What does this mean? Are these theoretical REST endpoints fetching information serially, or something? 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?

tango12 8y ago
This. Exactly this! I think anyone with experience will realise that you can get pretty much all the benefits of GraphQL with just a more sophisticated RESTish API. There is however, one thing that I think GraphQL backends have that REST backends don't, and that's the idea of introspection. Every GraphQL backend must be able to serve it's API data models and types. And I think the community tooling that leverages this makes it an amazing experience for app developers. No SDKs, any GraphQL client works with any GraphQL backend. Codegen esp for Android type apps to skip boilerplate of mapping APIs to POJOs. IDE autocomplete. I really think that the killer feature of GraphQL is that. We built a JSON DSL over a normal POST endpoint. Most GraphQL advantages sound "not really true" to me because you can always achieve the same thing (almost) yourself anyway.
- iEchoic 8y ago
  Yup, agreed - the developer experience and the self-documenting nature of GraphQL is a big plus. I no longer use GraphQL, but this is something I miss about it. As you mention though, people often don't realize that GraphQL is just a way to tell an endpoint that you want information in a generic way, and a pattern for having that endpoint resolve information in a generic way. It's an abstraction on top of a normal service call, and like most abstractions, it gives you consistency and ease-of-use but not any new capabilities you didn't have before.
- sixdimensional 8y ago
  Just wanted to chime in, OData had basically the same idea, however, from personal observation, somehow just didn't really become so popular, maybe because of its original association with Microsoft, etc. and also partially maybe its implementation. But it was pretty close, and today a lot of products support OData. I did note recently while reviewing the Microsoft API standard guidelines they share on GitHub [1], that there is a non-OData standard, but OData like recommendation for working with queries across collections, which I find to be pretty good and pretty generic. It seems like today you can do what you said - a sophisticated RESTish API without the model metadata piece pretty easily - but that metadata piece adds a lot of value. [1] https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#9-collections https://github.com/Microsoft/api-guidelines/blob/vNext/Guide... - see sections on sorting, filtering etc.

chvid 8y ago

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.

iamleppert 8y ago

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? 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.

nicolasd 8y ago
That's not true. "GraphQL requests" are _just_ POST requests with a JSON that contains "query" and "variables". So it's not the request itself that is not debuggable, but maybe the query interpreter on your backend with the framework you're using.
- iamleppert 8y ago
  Have you ever seen one? They are impossible to formulate with simple tools like curl on the command line. So my original point stands.

ravitation 8y ago

Good and bad reasons to use something are not the same thing as pros and cons...

voidr 8y ago

Most GraphQL presentations I have seen tend to construct the following strawman scenario: - 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 The followup: - 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 The reality is that GraphQL has a lot of drawbacks that are overlooked: - 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 Depending on your needs, it might still be worth it, I would just wish that GraphQL presentations would be more honest about these.