Ask HN: How has GraphQL panned out for your organization?

40 pointsby brundolf5 tahun yang lalu19 comments

I'm curious to hear anecdotes from people about real-world usage of GraphQL. Did the added complexity get offset by the benefits? Are you glad or regretful that you made the jump? Did you encounter any little-discussed benefits or costs? What kind of services architecture do you have behind it that influenced how useful it was?

20 comments

radu_floricica5 tahun yang lalu

You're likely to get a lot of selection bias in the answers - people using it likely made a decision that it's worth the hassle for their use case. To add a counter point: GraphQL was a non starter for our company, because we work with _very_ heterogenous clients who need to implement our API and the extra learning curve would be a killer. If you have to implement a simple REST API you just look at it and in a few hours the job is done. If it would be GraphQL, lots of people would have to learn a new paradigm just to implement a few calls.

eurasiantiger5 tahun yang lalu

You can call a GraphQL API using any HTTP client.

radu_floricica5 tahun yang lalu

I don't know any GraphQL, and when it came time to implement a GraphQL client, I spent half an hour trying to figure out what it's about, and then simply chose another supplier. It may be "self-documenting", but not for those that didn't go through the learning curve.

The learning curve may be short, or worth it, or fun if you're that kind of person. But don't tell me that all you need is a http client because that's simply not true, not "out there". And I'm certainly not about to subject hundreds of my clients' clients to having to learn something new just to implement a simple API.

eurasiantiger5 tahun yang lalu

But it is true. You can call it even with cURL and get a JSON string back.

https://www.apollographql.com/blog/graphql/examples/4-simple...

Of course, you need a GraphQL API first. Apollo is good if you want to resolve all your entities manually, but there are novel integrated database approaches like Dgraph that generate everything based on the schema.

radu_floricica5 tahun yang lalu

I hope you're joking. What is this "resolving all your entities manually" you speak of? Apollo? Dgraph? Is it Klingon?

What you're telling me that it's doable... once you go through the learning curve. And if you'll allow me a testy comment (not personal), it's exactly this lack of empathy toward end users that doesn't make me wanna try it.

What would help would be an already generated REST API I can use as an alternative.

brundolf5 tahun yang lalu

Technically all you need is a TCP port

I think the other person's point is that a GraphQL API is not a trivial leap from normal http; it's a significant abstraction layer of its own that requires its own learning process

peterohler5 tahun yang lalu

It's worked out great for us. We use it as a flexible way to get exactly what is needed in a single request that ends up pulling data from a mongo database. It has not added any extra complexity. On the contrary it has simplified out backend and front end apps. We use go and https://github.com/UHN/ggql.

brundolf5 tahun yang lalu

I've been told one of the main reasons to use it is when you have lots of granular endpoints or databases that you want to stitch together for consumption; do you benefit from that with a single Mongo database?

On the other hand, Mongo data already has a very similar structure to what GraphQL exposes, so it's a probably very straightforward to plug in

I guess my question is: what benefit is it really giving you if it's just forwarding requests to your DB? Is it just the fact that your payloads on the wire can be made smaller sometimes?

peterohler5 tahun yang lalu

A mongo database can have multiple collection or tables. Data from multiple tables can be joined together and then just what the user asks for is returned. We also include fields that calculate values based on data from the database. The caller need not be aware of the layout or structure of the data in the database. GraphQL queries allow for just the requested data to be returned and not a complete record from a database.

brundolf5 tahun yang lalu

Fair enough, that makes sense. It's been a while since I used Mongo and I used an ORM at the time so I forgot about how much joining can be required.

speedgoose5 tahun yang lalu

I currently work on a project using GraphQL from the start and we are happy with this choice. It's sometimes a bit complex but when I listen to some friends debating about how to build the most beautiful RESTful API for their use case, I don't regret GraphQL at all.

We have some queries that are a bit slow because it's easy to ask a lot in GraphQL, but the alternative would be to do hundreds of HTTP queries if we were using REST for example.

The tooling is particularly good nowadays. My company use it in NodeJS with Apollo and TypeScript and it's very good and stable. I also did some side projects in Rust and it was very pleasing to use too.

One common problem is the caching, you can't easily cache using normal HTTP CDN software for example, but since our API requires to be authenticated for anything, it's not a problem for us. We just do cache in other places.

We have some simpler API not using GraphQL but I would strongly recommend GraphQL as soon as your API is not tiny.

jayy-lmao5 tahun yang lalu

That sounds a lot like our experience. We use GraphQL as a gateway to like 20 different rest endpoints. Places where we have hammered an underlying endpoint are _usually_ places where we would have done so from the client or SSR instead. We do also have all these talking within an internal network which is a huge help.

Have also done Rust and really enjoyed GQL in it, both as hobby and "innovation projects" at work. Feels good.

WRT CDN Caching: Akamai has a pretty good GraphQL caching module that can also do POST requests. Cache directives are marvellous. I'd like to see explore the "private" directive to see if it disables certain queries from being cached.

jayy-lmao5 tahun yang lalu

Oh and also: If you use typescript in the frontend GQL codegen is super simple to set up and can type all your queries

jelling5 tahun yang lalu

At a minimum, GraphQL skips the problem of having one or few engineers re-invent the wheel of how to pass queries to an API. Or if you’re lucky, how to document it.

REST Api design is probably one of the least value-add activities a company can involve itself in. Any standard that defines a standard way of performing set operations, GraphQL or even the ancient ODATA, is superior.

knlam5 tahun yang lalu

I have been using graphql since 2019 and it has been great for me. Overall if you have a big team, it is much more easier to manage. The graphql ecosystem is growing and tooling are standadized (nowadays the N+1 can be easily solved)

But one thing will always remain and you have to remember is that graphql is slow by design. If performance is critical to you, don't use it

travisd5 tahun yang lalu

I used it to built my startup (currently bootstrapping, just me) and I have no regrets. The data model is relatively complex and the frontend makes very heavy use of Apollo features. I think the number one benefit in the backend is just having a well documented data model that isn’t tied to specific (arbitrary routes). For the frontend, using Apollo makes things like consistency very easy in a SPA since it normalizes all the data it receive (there’s no “data tearing” that tends to come when you load initial data from source A then update from source B). Also, using codegen for the frontend is chefs kiss (I hate manually creating TypeScript interfaces for API response shape, especially since they can get out of date easily).

waffleau5 tahun yang lalu

I didn't choose to adopt GraphQL, but I joined a company where an ex-developer had integrated into what was at that point a core codebase. They didn't add it due to any particular merit, they just wanted to play with shiny new technology. The codebase also had REST endpoints, but GraphQL made up the majority of the API, so we decided to just run with it and deprecate REST. At the time the decision we made was arbitrary.

This turned out in retrospect to be a good call. The primary consumers of the API were a set of Android and iOS apps, and integrating GraphQL into mobile apps is a pleasant experience. You can generate your data models from the graph schema. Tools like GraphiQL allow developers to explore and play with your API, substantially reducing the amount of documentation needed. The mobile team much preferred working with GraphQL over REST.

On the backend, GraphQL has a bit of a learning curve. The resolver pattern is powerful once you understand how to use it properly, but also easy to misuse. The most common source of problems is developers not understanding Graph's batch resolution mechanism. Developers accustomed to building REST APIs rely on preloading data, which is the wrong approach when dealing with GraphQL.

As a simple example, maybe you initially build a Graph query where you load comments like this:

  query Comments {
    user {
      posts {
        comments {
          message
        }
      }
    }
  }

But later on, you decide you want to allow a user to load their comment history directly:

  query Comments {
    user {
      comments {
        message
      }
    }
  }

In the first example, an equivalent REST API might load comments via something like posts.preload(:comments), and when the second query is built you'd use user.preload(:comments). But the way to solve this problem in Graph is batch resolution - get a list of comment IDs you want to load, then call Comment.where(id: comments_ids). Your comment loading is now context agnostic.

Another related problem is that it is easy to create N+1 queries. This also stems from a misunderstanding of batch resolution - reusing the above example it would be the equivalent of calling Comment.find(comment_id) for each ID instead of Comment.where(id: comments_ids). My first few months working with Graph were often spent fixing N+1 queries. As much as I try to explain this problem to new developers, it's one of those things that doesn't click for them until they cause the problem and end up having to fix it.

Once you understand GraphQL it's a nice technology to work with. In the early stages it can be fairly easy to shoot yourself in the foot, you just need to build up enough knowledge to avoid the common pitfalls. In general, GraphQL APIs are harder to build than REST APIs (mostly because REST is the default for most frameworks). If I had to start a new project today, my decision on whether to use GraphQL would be be determined by questions such as:

  1. How much control do I have over the clients
  2. Are the primary consumers native mobile applications 
  3. Is flexibility important
  4. Will API documentation be required

brundolf5 tahun yang lalu

Good stuff.

I'm surprised about the native mobile thing; is working with REST that arduous on mobile? I come from a web background so I don't really know

waffleau5 tahun yang lalu

It definitely requires more work. If you're starting from scratch, you need to either read the API documentation or makes calls to the API to understand the data you're getting back. You then need to build correctly typed data models that match what you're expecting the API to give you. There's plenty of room to make mistakes as it's a manual process.

With GraphQL you can take the schema file from the server and use it to generate your data models. You get the data models for free, everything is correctly typed, and as long as the schema you're using is up to date you have a guarantee on correctness. It also makes finding changes to the schema easier in the future, as you can effectively do a diff.

We also use GraphQL on web (the exact same API as mobile) but we don't realise nearly as many of these benefits. This is probably in part because we haven't invested a lot in tooling, but also the team that maintains the API also maintains the web product, so some of the discoverability benefits of Graph aren't as valuable.

uberofrape5 tahun yang lalu