Live data from Hacker News

Hasura raises $9.9M to simplify GraphQL

techcrunch.com

51–60 of 199 posts

Re: Hasura raises $9.9M to simplify GraphQL

#52
post #44
post #37

If GraphQL needs $9.9M to be simple enough for developers to actually use it, why was it invented?

PostGraphile is free, try it!

The point made was, software is supposed to solve a problem. Not create a new problem and provide a paid solution. Kinda speaks the truth that something is fundamental isn't made simple yet.

Re: Hasura raises $9.9M to simplify GraphQL

#54
post #2

I tend to prefer PostgREST's[1] syntax over GraphQL for when I need flexible client-side queries. It's way more intuitive for me. [1] http://postgrest.org/

Totally agree. I recently greenfielded a new project and hasura, postgraphile and Postgrest were all tools I trialed. Hasura has the best “get up and go” but ultimately postgrest was simpler and more intuitive—graphql is cool, but for one person/small team projects it feels like complexity overkill. The added abstraction over rest is just unnecessary with postgrest’s resource embedding. I liked having an admin interface that hasura provided, but really, dbeaver is often just as usable.

Re: Hasura raises $9.9M to simplify GraphQL

#55
post #37

If GraphQL needs $9.9M to be simple enough for developers to actually use it, why was it invented?

GraphQL definitely has its warts, but it provides more flexibility on the API response than you'd get with ReST, so you're neither sending the whole world to keep your API space small nor adding new endpoints to handle each new client use case. But, GraphQL doesn't fundamentally change the fact that something needs to be responsible for enforcing access restrictions and talking to a database.

Hasura is working to simplify that layer, but developers aren't cheap and I'd imagine the work isn't terribly fun. A lot of existing web frameworks have sprung up out of consultancies to support that development cost. Raising capital is just another funding strategy.

Re: Hasura raises $9.9M to simplify GraphQL

#56
post #50
post #43

After trying Hasura, Prisma, and PostGraphile, my conclusion is that PostGraphile is way ahead of all this. Please all have a look at PostGraphile, it is amazing, even more than Hasura!

Can you elaborate?

There are so many good reasons to use it that I think I don’t make it justice. But here a few pros of graphile:

- it is made in typescript and can be integrated as a library directly in a JS project

- it is very easy to extend with plugins

- it is very easy to customize and run on an existing database

- it is « database first » in the sense that the schema is created based on the DB schema and some additional annotations

- it is really free open source software with a non-VC backed business model

- it is extremely performant

Re: Hasura raises $9.9M to simplify GraphQL

#57
post #48
post #5

Hasura is a game-changer. I'm never writing CRUD backend apps again by hand. Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours. This adaptor connects react-admin with Hasura: https://github.com/Steams/ra-data-hasura-graphql Here's a reference application…

Part of what I'm doing is working on a CRUD backend. The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client customization. There's also some neat handling around versioning and copy-on-write type behavior to provide a mix of immutability and space saving. To me, this is CRUD because: most resources literally have 4 endpoints (create, index, update and delete). We write…

Last time I looked at GraphQL it was only a time-saver if you could rely on significant amounts of automagic for the GraphQL->DB Query step. So if your use case & stack allow for that, yeah, maybe it'll save you significant time.

Its main effect is to move app logic query writing to the frontend, in something that's not SQL, which some folks seem to really like. But it's still got to get turned into whatever your data sources actually speak at some point, just like REST or anything else. If there's nothing magically doing that for you or if the magic turns out to suck, you'll be doing it manually.

[EDIT] to make it more clear, here are your possibilities:

1) a. GraphQL queries -> b. Queries for one or more kinds of datastore

2) a. REST requests -> b. Queries for one or more kinds of datastore

You shift choices about how to query kinda forward in 1, but that means you need a very general and flexible GraphQL query handler to make step 2 happen, and if that doesn't exist or is insufficient you have to write it. That is, obviously, more work than 2, in which 2b is where the choices you'd make in 1a happen, so that layer doesn't need to be as flexible.

TL;DR the apparent flexibility and responsibility-shifting of GraphQL isn't free and is in fact quite expensive (and, if I may, risky)... unless it is free because someone's already done the work, for your particular use case and stack.

Re: Hasura raises $9.9M to simplify GraphQL

#58
post #9
post #7

While I like and enjoy many aspects of code generation such as this or Prisma, In real world scenario it just doesn’t feel right. Imagine a very simple scenario, you want to add some validation based on business requirements, in order to do that you have to have a server with custom endpoints or a custom graphql server (thus copy most of what hasura generates) to implement your own validation The only situation in wh…

Often times that’s not needed if you actually use the full power of PG. CHECK constraints go a long way, and where they don‘t go, PG/PSQL goes pretty much a long way. For internal or prototypical use cases, that can be totally sufficient, however you‘re right that you‘ll eventually want good error messages, observability and much more other custom logic. What I‘m still searching for is something that works like Hasur…

[deleted]

Re: Hasura raises $9.9M to simplify GraphQL

#59
post #37

If GraphQL needs $9.9M to be simple enough for developers to actually use it, why was it invented?

As per the article, Hasura is focused on PostgreSQL now. They want to provide a similar experience for other databases also So that they can tap into multiple enterprise customers. Also, I think they are working on features to expose different REST APIs via unified GraphQL API.

It's a big enough problem space I think and it has lot of scope for innovation. Enterprise Integration is also quite a big market, so there is definitely an opportunity to create a profitable company there.

Re: Hasura raises $9.9M to simplify GraphQL

#60
post #48
post #5

Hasura is a game-changer. I'm never writing CRUD backend apps again by hand. Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours. This adaptor connects react-admin with Hasura: https://github.com/Steams/ra-data-hasura-graphql Here's a reference application…

Part of what I'm doing is working on a CRUD backend. The thing has a bunch of complex business and authorization rules. Not to mention a bunch of per-client customization. There's also some neat handling around versioning and copy-on-write type behavior to provide a mix of immutability and space saving. To me, this is CRUD because: most resources literally have 4 endpoints (create, index, update and delete). We write…

If you're up for it, I'd love to chat and see if Hasura could've worked in your case[1]! Especially on the read side, if we're able to model the authz with Hasura your API consumers get a rich read API "for free" and Hasura can delegate the CUD stuff to your existing REST APIs.

Hasura aside, GraphQL will save your API consumers time more than anything else. Like the other comment/reply to this, you still have to build a GraphQL server.

[1] I'm twitter.com/tanmaigo or tanmaig@hasura.io

Post reply on HN