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.
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.
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.
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
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?
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.
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.
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.
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
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
}
}
}
}
query Comments {
user {
comments {
message
}
}
}
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 requiredI'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
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.