14 ms·

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

• 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.
  • wasd 6y ago
    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.
• silviogutierrez 6y ago
  I use Django, the equivalent of Rails for Python. I strongly recommend: http://boringtechnology.club 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.
  • wasd 6y ago
    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.
• hn_throwaway_99 6y ago
  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.
  • steveklabnik 6y ago
    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.
  • wasd 6y ago
    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).
  • acjohnson55 6y ago
    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 6y ago
      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 6y ago
        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.