Hasura raises $9.9M to simplify GraphQL

E.g. https://github.com/reframejs/wildcard-api for JavaScript.

The neat thing about RPC is that you can tap into the full power of PostgreSQL "directly" from the frontend.

Anyways here is the use case. We have a table named model.nodes. We have various model.foo_detail tables. And views named model.foo. Every foo is a node. (Clearly this schema predates our interest in GraphQL...) We have triggers on the foos so that they can update the underlying combinations of tables correctly, and also keep an audit log. We have an external CMS running off of a different architecture which handles authentication.

There are additional complications that I am not going into, such as the fact that every client installation will have new, client specific tables, in a client specific schema.

We wanted to have all of the _detail tables hidden. To choose what to expose. To rename some things here and there. To lift the foreign key relationships from foo_details to the exposed foo. To have all authorization handled by the application that already handles it. To allow subscriptions to root objects with as little overhead as possible. To add custom pub-sub channels that were also available for customers. To have a client installation include client specific tables (albeit with a bit of renaming to guarantee no conflicts between what the client has and anything we ever will have in our core product). And to make it easy to maintain it going forward.

3 of us independently looked at all the available tools. We independently came to the same conclusion. The two most mature products were Hasura and Postgraphile. Hasura on our database presented an interface that was nothing like what we wanted to show, and we didn't see how to customize to be what we wanted. Postgraphile did a better job out of the box, and we could see how to make it give us exactly what we wanted. (Yes, we had to do things like add pg_notify statements to our stored procedures, but it was straightforward.)

And yes, the language mattered. For example neither Hasura nor Postgraphile offers an out of the box integration with the random CMS we were dealing with. But none of us know Haskell, all of us know JavaScript, and Postgraphile is not hard to integrate with passport.js. And through that we can do anything that we want.

There is an old programming rule. "Only one person gets to be clever at a time." We were already dealing with a database schema with a lot of cleverness built in. Hasura has a lot of cleverness as well. You are right that Hasura didn't want to actually control* our database, but we broke its expectations pretty badly and would have to modify it pretty extensively to make it work like we wanted.

I agree, Hasura and Wildcard have different goals. Still, the merits of each tool can be talked and discussed about.

> you aren't writing any SQL queries. You are creating your database schema and then launching the respective apps. Obviously some customization will be necessary since almost no app are 100% CRUD.

I'm not against ORMs. On the contrary, I've always been (and still am) looking for an ORM that takes care of 90% of queries (basic CRUD queries) while preserving the full power of SQL for the 10% of queries that require more powerful queries. Most ORMs do that part wrong and make writing custom SQL queries complex. I really want such ORM and I even tinkered and implemented one for a hobby project.

Also I believe that an ORM to be a wonderful combo with Wildcard, such as Prisma. (Prisma is pretty much an ORM and can be used without GraphQL.) I would argue that Prisma + Wildcard to be superior to Prisma + GraphQL. (With the exception of when you need need third-party devS to access your data -- you then need a generic API with either REST or GraphQL.)

> But I took a look at your RPC tool, and it adds a lot of boilerplate work.

I couldn't disagree more; Wildcard is deliberately designed to abstract away as much boilerplate as possible. I'd be more than happy to see a concrete example that proves me wrong. My guess is that you won't prove such example because there virtually isn't such.

> This RPC boilerplate is exactly why alternatives like Hasura, Prisma, and Postgraphile exist.

That's a vague sentence and doesn't make any sense to me.

> it is just as simple, just as much a layer on top of the database.

Wildcard is only a couple of KLOCs while Hasura & co large and complex tools developed by teams and backend by big VC money.

You can read Wildcard's whole documentation in 10 minutes. Reading Hasura's entire documentation is much larger than Wildcard's.

It speaks volumes about how much simpler Wildcard is in comparison to Hasura.

It's weird to say that Hasura is as simple as Wildcard.

> the client doesn't have to know if it's talking to a relational database, a Redis cache, a REST data server, an in-memory data model, or whatever.

Such decoupling is mostly useful for very large projects. The vast majority of apps out there don't need such decoupling. Separation of concern is important, but based on concern not on technology.

> Your tool on the other hand is just another vendor-specific ORM or manual query engine.

It's weird to call an RPC implementation an "ORM" or "query engine". I'm not sure how an Software Engineer is able to mix up "RPC" with "ORM".

Honestly, your whole post is weird to me, I'm not sure what your motive is. You seem to try to put down an open source project that is being developed by someone in his free time and without any remuneration. That's disgusting and without taste. If you only have a lack of tact then I apologize for my words.

Just to be clear I do like many aspects of Hasura. The problem is that, 95% of the time, GraphQL is not being used in the right situations. GraphQL when used correctly is a lovely tool. (Basically GraphQL = generic API for third parties. If you don't need third parties to access your data then you don't need GraphQL.)

I think if I was going to be deploying a real database (PostgreSQL), I'd want to do things with authorization and network configuration; at which point I'd be dealing with enough stuff around the user profile that I'd want my preferred query and mutation design (GraphQL + Relay).

If at any point you're going to be fetching data containing long lists, I'd also prefer to be working with GraphQL and Relay because the design is well thought-out for doing filtering, pagination, and caching.

Decoupling is good any time you want to allow different parts to change independently. Migrating architectures can take a significant amount of effort, but it just depends what you want to accomplish.