I've been using this for a small project and the feature set is far more comprehensive than anything else I've seen in Rust. In comparison to Juniper, it has much better support for subscriptions in particular. Its creator has been amazingly productive and continues to add features almost daily.
Came here to ask how it compares to juniper. Juniper has been the one part of my stack of crates that's made async difficult for a while now. Building a rust app with full futures support from top to bottom has huge benefits, but support on juniper has been slow in coming (a lot of existing code to move along with it), and the main error being GraphQLError<'a> with a lifetime and no impl of std::error::Error has been a huge nuisance to deal with.
That said, constructing the resolvers with the `#[juniper::graphql_object` macro has been incredibly easy. They used to use some clunky DSL, but since the move it's been great. Don't think I'd consider moving if async-graphql isn't as strong on that, but I won't really know until I try both.
Excuse me what's the point of GraphQL as a primary middleware/middleware protocol? I can get the use case of consolidating a number of existing "REST" services to reduce service roundtrips with HTTP/1.1 or layering problems with HTTP/2.0 or QUIC, but it's not like nobody warned against use of the "REST" spaghetti antipattern, including Roy Fielding who coined the term. So JSON and XML (de-)serialization is natively supported by browsers, but what has GraphQL going for it when you need a browser client lib for it anyway? Why not just use a regular endpoint for JSON or XML; their use isn't tied to an opinionated "REST" interpretation at all and you could just send arbitrary payloads. Or is it just because, like React, GraphQL is advertised with all the strength of the media powerhouse that is Facebook in the end?
IMO GraphQL is a far better API framework than anything REST or "REST-lite"
1. Since GraphQL is always strongly typed, it serves as the perfect contract-definition layer between front-ends and back-ends. A common pattern is to define all your endpoints with the type definition language, then expose mock endpoints that the front-end team can code against while the back-ends team implements. In practice this works much better than anything I've ever done with REST tooling.
2. The strong typing also guarantees that many classes of mistakes and errors (and potential security holes) never even make it to your running resolver code.
3. GraphQL really excels where you may have clients outside of your control running against older versions of your API. A big original impetus for developing GraphQL was supporting native mobile clients, where all clients can't be updated in tandem with the server like a web-app can. Since the client always sends the full shape of the query they're executing, it's easy to evolve endpoints slowly: just add new fields or endpoints to your schema, @deprecate the old fields, but older clients can use those deprecated fields until they can migrate onto the newer fields. Backwards compatibility is never free, but again, in practice I've found this works much better than maintaining and potentially transforming between different explicit versions of REST APIs.
4. The tooling is simply fantastic. GraphiQL/GraphQL playground are leaps and bounds beyond something like Swagger.
There are other reasons but those are some of the highlights for me.
Appreciate your response. This sounds exactly what SOAP is like, then, and also what OpenAPI/JSON schema are attempting to do (only SOAP/WSDL also adds auth, transactions, discoverability, language mappings, schema evolution, and a couple other things). My post surely wasn't meant to defend "REST" or Swagger of all things :); more like, the industry has delivered one middleware standard after another in the last 20 years since "web services" became a thing, and arguably even earlier (CORBA). So it wasn't quite clear for me where this enthusiasm was coming from all along. Please don't be offended, but your answer confirms my suspicion that GraphQL is introducing an age-old concept to a new audience that was raised in the naive "REST all the things" mood of the last decade.
From the other answers, I get there's additional practical functionality like generic sorting and filtering in a GraphQL endpoint, though as a fullstack but mostly backend guy I'm puzzled how that's supposed to work without pushing the query criteria including sorting/offset/limit down to a DB in a hands-off way without a backend team implementing it.
You're right. GraphQL definitely seems like that. There are a few nuances though:
1. GraphQL is like SOAP for JSON. JSON is important to lot of developers today, especially the frontend/javascript ecosystem
2. GraphQL also helps developers think of data as related entities in a way that fits JSON. Nested objects and arrays essentially, but not ad-hoc. Hence a "schema" of your "graph" that describes the API.
3. GraphQL has a construct called fragments that makes it easy to declare data-dependencies at a UI component level that are then automatically composed together into a single query by graphql client tooling (at build time ideally). This can be done with JSON as well, but the ergonomics with GraphQL are nicer.
None of these are truly "new" ideas perhaps. But I think all of it coming together is new.
That said, the complexity of building and maintaining a GraphQL server is definitely non-trivial in the real world. For example, health-check tools often rely on HTTP status codes in responses to check service and API health. This doesn't work well with GraphQL because GraphQL supports partial errors and responses, and the error itself is embedded inside the response. This means analysis the response is necessary. This means that the privilege required for the health-check tooling is greater. Responses should not be logged or analysed by third party services without taking a lot of explicit care.
I worked extensively with SOAP in the early 00s. I hated every living minute of having to deal with SOAP (completely overcomplicated, bad tooling), and I love programming with GraphQL.
At my previous job GraphQL was considered because the frontend team was poorly served by the API exposed by the backend team. Everything was available, but the frontend needed to join, filter, sort and and adapt it in all kinds of ways for different UI. The backend team was too busy to provide the same data in different shapes, so the frontend had to do this manually. Of course they wrote their own code to do this all the time, but what they would rather have spent their time on was UX and business logic.
> when you need a browser client lib for it anyway?
You don't need a browser client library to execute GraphQL queries on the frontend, it's just a POST request with a query string and a parameter for variables.
It's just easier and more convenient to work with.
I want xyz data. I query for xyz data. Single request.
I want to provide abc data. I put abc data in the database and expose it (don't have to write another separate endpoint plus all the related relationships). Now I can query for ranges, filter, etc. in a single request.
Aaaaarrrgggghhh! I feel like I post this same comment whenever the discussion is about GraphQL.
I love GraphQL. What I hate about GraphQL is that it has "QL" in the name, so it confuses people into thinking it's somehow comparable to SQL. The question "How is GraphQL for aggregate queries?" doesn't even make sense.
GraphQL is simply another format for APIs. E.g. you could do APIs with SOAP, using REST, or with GraphQL.
Actually, that's really helpful. Thank you! I was under the impression GraphQL was API end point and query resolver (so it knows how to do GraphQL -> SQL).
Same. I wished they didn't call it GraphQL. When I first looked into this, I had to explain to people that it was just a spec. A spec that can be implemented in different languages. It is not SQL.
I jumped into GraphQL form the PHP side. And after understanding what it was the next step was simplly exposing an endpoint. From there, https://webonyx.github.io/graphql-php/ took over.It went like: Route --> Controller/action --> Use `graphql-php`. For the resolvers, I was able to re-use the services the returned data.
The "entry barrier" to the existing legacy-ish framework we were using wasn't too hard. But the learning curve to solve problems in "GraphQL way" is much harder to push as most people are used to REST way of doing things.
Totally. As I tell people, it's neither a query language, nor particularly graph-oriented. I describe it instead as a toolkit for writing custom domain-specific languages for your services.
Eh, I’d call it a query language in the same way that I’d call XML a language. I’ve heard the term metalanguage bandied about for XML, but it never really seemed to catch on. GraphQL could perhaps be called a query metalanguage, defining grammar and language semantics.
They're both metalanguages to me. You use them to define domain-specific languages. We may as well throw JSON in the mix, too. Sure, it's a language with its own grammar, but it's only really useful when implementing the semantics of an API contract (whether that contract is explicitly specified or not).
The reason I object to the "query" part is that GraphQL has no built-in operators that true query languages invariably have. All you really get is inclusion of fields into your request and parameterization. All other semantics have to be implemented by the user in their own spec.
Yes, this caused major confusion for me for a very long time. I assumed that it was like MySQL/Postgres, with different data stores implementing a query language. That’s really only Fauna.
The two are very similar, with the difference that Postgraphile harnesses PostgreSQL's row level security for authorization and is written in JavaScript rather than in Haskell, which means a low barrier of entry for many people to write plugins.
Note that I do use React and a SPA for a big part of my SaaS (links in profile) but for the vast majority of CRUD screens, nothing comes even close to the productivity of Rails/Django.
In full support of the boring club! See my other comment but essentially, I find ActiveRecord hasn't worked great for our use case because we don't really work with individual records.
I would like to have more flexibility in the client specifying what attributes and relations it wants.
If you're not using rails to create an API server, and you've only got a single database, then I'm not sure there's any value in GraphQL.
My (limited) understanding is that GraphQL is great for writing database agnostic queries, and writing queries that will be run from an untrusted source, like a client.
Thanks for the tip. I don't need an API server (yet). Our app is driven by a lot of SQL. We end up with a lot of functions which are business_logic, business_logic_with_joins, business_logic_with_different_joins. I'm most interested in avoiding N+1 queries and letting the page ask for the attributes / relations it needs. GraphQL seemed like reasonable solution for that.
Oh cool, they've also authored a Tide integration: https://docs.rs/async-graphql-tide. As someone who works on Tide, this is really exciting!
At a glance the integration between the two looks fairly straightforward -- two lines for the integration, and five lines to define a schema. That's pretty good.
One thing I wonder with GraphQL, is usefull to use for mostly server-side without routing by JS?
I think could be use-full to use for the extra possibility of auto-get a lot of the client side utilities, but if I wish to handle all server side (like in a regular actix project), how is done?
We (fly.io) use GraphQL pretty extensively with server side clients. We have both a CLI and a Rails app that consume our API. It's pretty good if you need multiple client apps, even when those clients are server side.
