Hacker News new | ask | show | jobs
by wasd 2236 days 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)?

4 comments

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.
You may be interested in Hasura.
... or Postgraphile
I started using Hasura for a side project, I really like it so far. How does it compare/contrast with Postgraphile?
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.
I use Django, the equivalent of Rails for Python.

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.

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.