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)?
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.
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.
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.
I strongly recommend: http://boringtechnology.club
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.
I would like to have more flexibility in the client specifying what attributes and relations it wants.
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.