
Async-GraphQL: A GraphQL server framework - unignorant
https://github.com/async-graphql/async-graphql
======
unignorant
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
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
Juniper master has async and subscription support

~~~
jkoudys
Yeah I've been using it - took a while but pretty happy with it so far.

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

~~~
hn_throwaway_99
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.

~~~
tannhaeuser
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.

~~~
tango12
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.

------
wasd
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)?

~~~
hn_throwaway_99
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.

~~~
acjohnson55
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.

~~~
chrismorgan
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.

~~~
acjohnson55
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.

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

------
yoshuaw
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
For anyone else who doesn't know what Tide is: [https://github.com/http-
rs/tide](https://github.com/http-rs/tide)

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

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

~~~
pastrami_panda
Maybe a bit too similar to GraphiQL?

