5 ms·

Async-GraphQL: A GraphQL server framework

134 points by unignorant 6y ago

unignorant 6y ago
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.
- jkoudys 6y ago
  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.
  - LegNeato 6y ago
    Juniper master has async and subscription support
    - jkoudys 6y ago
      Yeah I've been using it - took a while but pretty happy with it so far.
  - unignorant 6y ago
    Constructing the resolvers is very similar to Jupiter, see: https://github.com/async-graphql/examples/blob/master/models/books/src/lib.rs#L36 https://github.com/async-graphql/examples/blob/master/models... Agree that it's really nice. I wouldn't have switched either without that feature.
- sunli829 6y ago
  Thanks for your support. :)
adamnemecek 6y ago
You need to come up with a name. Graphiq comes to mind if you are edgy. Disgraphiq if you are super edgy.
- pastrami_panda 6y ago
  Maybe a bit too similar to GraphiQL?
yoshuaw 6y ago
Oh cool, they've also authored a Tide integration: https://docs.rs/async-graphql-tide 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.
- RussianCow 6y ago
  For anyone else who doesn't know what Tide is: https://github.com/http-rs/tide https://github.com/http-rs/tide
revskill 6y ago
I don't know Rust, but i think with this library i could have a chance to learn Rust by writing a production graphql server.
wasd 6y ago
I'm a GraphQL n00b. My app is a pretty vanilla monolith server rendered Ruby on Rails / Postgres (no SPA). 1.) Would I use async-graphql on top of postgres and communicate via a ruby graph ql client? 2.) Is it a bad idea for me to use a rust backend on top of postgres instead of Ruby? Is there something more common then async-graphql? 3.) How is GraphQL for aggregate queries (count, avg, etc)?
- steveklabnik 6y ago
  You may be interested in Hasura.
  - marton78 6y ago
    ... or Postgraphile
    - rhlsthrm 6y ago
      I started using Hasura for a side project, I really like it so far. How does it compare/contrast with Postgraphile?
      - marton78 6y ago
        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.
- genuine_smiles 6y ago
  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.
  - 6y ago
mamcx 6y ago
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?
- mrkurt 6y ago
  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.
  - mamcx 6y ago
    How make that work? As far I see, i need to compile js ahead of time, but never see it done inside rust or python or else...
tannhaeuser 6y ago
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?
- hazz99 6y ago
  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.
- eska 6y ago
  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.
- JSavageOne 6y ago
  > 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.
- hn_throwaway_99 6y ago
  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.

134 points by unignorant 6y ago

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.

jkoudys 6y ago
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.
- LegNeato 6y ago
  Juniper master has async and subscription support
  - jkoudys 6y ago
    Yeah I've been using it - took a while but pretty happy with it so far.
- unignorant 6y ago
  Constructing the resolvers is very similar to Jupiter, see: https://github.com/async-graphql/examples/blob/master/models/books/src/lib.rs#L36 https://github.com/async-graphql/examples/blob/master/models... Agree that it's really nice. I wouldn't have switched either without that feature.
sunli829 6y ago
Thanks for your support. :)

adamnemecek 6y ago

You need to come up with a name. Graphiq comes to mind if you are edgy. Disgraphiq if you are super edgy.

pastrami_panda 6y ago
Maybe a bit too similar to GraphiQL?

yoshuaw 6y ago

Oh cool, they've also authored a Tide integration: https://docs.rs/async-graphql-tide 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.

RussianCow 6y ago
For anyone else who doesn't know what Tide is: https://github.com/http-rs/tide https://github.com/http-rs/tide

revskill 6y ago

I don't know Rust, but i think with this library i could have a chance to learn Rust by writing a production graphql server.

wasd 6y ago

I'm a GraphQL n00b. My app is a pretty vanilla monolith server rendered Ruby on Rails / Postgres (no SPA). 1.) Would I use async-graphql on top of postgres and communicate via a ruby graph ql client? 2.) Is it a bad idea for me to use a rust backend on top of postgres instead of Ruby? Is there something more common then async-graphql? 3.) How is GraphQL for aggregate queries (count, avg, etc)?

steveklabnik 6y ago
You may be interested in Hasura.
- marton78 6y ago
  ... or Postgraphile
  - rhlsthrm 6y ago
    I started using Hasura for a side project, I really like it so far. How does it compare/contrast with Postgraphile?
    - marton78 6y ago
      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.
genuine_smiles 6y ago
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.
- 6y ago

mamcx 6y ago

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?

mrkurt 6y ago
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.
- mamcx 6y ago
  How make that work? As far I see, i need to compile js ahead of time, but never see it done inside rust or python or else...

tannhaeuser 6y ago

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?

hazz99 6y ago
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.
eska 6y ago
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.
JSavageOne 6y ago
> 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.
hn_throwaway_99 6y ago
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.