Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hasura raises $9.9M to simplify GraphQL

techcrunch.com

Post reply on HN
Print view View original

101–110 of 199 posts

Re: Hasura raises $9.9M to simplify GraphQL

#101

Post by aidos »

markhalonen wrote: post #84
shivekkhurana wrote: post #81

I settled for Hasura in a prod app after trying Postgrest, Postgraphile and Strapi. I believe its a permanent addition to my stack. The main reason for me was RBAC. Converting db-to-api is not that hard but providing access control almost always requires some form of middlewares. Hasura does RBAC very well. Another feature that I haven't deployed but find useful is webhooks. You can trigger webhooks as your data chan…

What made you choose Hasura over Postgraphile? RBAC is a postgres feature, not sure if that would affect the decision?

Not the parent but we went with Hasura over postgraphile because they do RLS outside of the dB. It allows them to load the data for all clients subscribed in a single query. Also the subscription story is better (from memory).

Re: Hasura raises $9.9M to simplify GraphQL

#102

Post by tirumaraiselvan »

shivekkhurana wrote: post #81

I settled for Hasura in a prod app after trying Postgrest, Postgraphile and Strapi. I believe its a permanent addition to my stack. The main reason for me was RBAC. Converting db-to-api is not that hard but providing access control almost always requires some form of middlewares. Hasura does RBAC very well. Another feature that I haven't deployed but find useful is webhooks. You can trigger webhooks as your data chan…

You might like our upcoming Scheduled Triggers feature which lets you invoke webhooks according to cron or adhoc timers: https://github.com/hasura/graphql-engine/pull/3553

Re: Hasura raises $9.9M to simplify GraphQL

#103

Post by MadWombat »

One thing that bothers me about systems like this is the underlying assumption that database architecture always reflects the presentation. But what if ti doesn't? I am looking at the Hasura docs and all it really says is "we will generate everything for you based on your database schema and here is the way we do it". But what if I don't want some tables to be exposed? What if I want to expose custom queries instead of tables?

I feel that products like Hasura and postgrest would be a lot more useful if there was a way for me to specify a list of data sources on one side and get a fully formed GraphQL or REST service on the other side rather than going "I know what you need better than you" route.

Re: Hasura raises $9.9M to simplify GraphQL

#104

Post by rojobuffalo »

awb wrote: post #53

Some major players in the "GraphQL in a box" space: https://www.graphile.org/postgraphile/ https://hasura.io/ https://www.prisma.io/ There are plenty of "REST API in a box" solutions as well: https://github.com/PostgREST/postgrest https://github.com/prest/prest https://resthapi.com/

I've been working on GraphQL services since 2015. I worked on the design of the precursor to postgraphile; it was called postgraphql. Hadn't heard of Hasura before today, but it looks interesting.

The primary complaints I hear from others about GraphQL are observability and the learning curve for devs who are new to it. I think these projects add a lot of value with tools like the GraphQL playground (similar to GraphiQL but better), middleware extensibility for observation/analytics, their documentation, and most importantly the starter/boilerplate projects.

IMO, the preferred option today is Prisma. They have a non-production-ready v2 that is available for testing. But even v1 is good for an enterprise product; and they're working on migration/codemod to get onto v2 when it's ready.

But the other big piece of the puzzle is deciding on a GraphQL client. It seems like most choose Apollo + Redux, but Relay is, without a doubt in my mind, the better library/framework for consuming GraphQL in the frontend. Facebook designed React, Relay, and GraphQL to work together really nicely. Relay takes some re-learning to think about frontend data dependencies and caching, but it's really well designed.

I think GraphQL on its own has value as a centralized contract between frontend and backend services, and is a nice query and mutation language; but without Relay I don't think you get the full benefits of all the hard work that goes into the GraphQL service design. And teams/organizations that end up with Apollo/Redux designs suffer from complexities around cache management that Relay does a better job of reducing.

Re: Hasura raises $9.9M to simplify GraphQL

#105

Post by vosper »

markhalonen wrote: post #65
awb wrote: post #53

Some major players in the "GraphQL in a box" space: https://www.graphile.org/postgraphile/ https://hasura.io/ https://www.prisma.io/ There are plenty of "REST API in a box" solutions as well: https://github.com/PostgREST/postgrest https://github.com/prest/prest https://resthapi.com/

I ultimately chose Postgraphile over Hasura. Mostly because the Postgraphile codebase seemed way hackable, written in TS/JS with a plugin architecture. I've tried some Haskell and that's just a whole nother world I don't have time to learn. So far it's working great for me.

FWIW, I went the other way, mostly because I found the GraphQL queries that I wrote in Hasura to be much nicer to read than the equivalents that I got with Postgraphile.

Re: Hasura raises $9.9M to simplify GraphQL

#106

Post by rattray »

markhalonen wrote: post #65
awb wrote: post #53

Some major players in the "GraphQL in a box" space: https://www.graphile.org/postgraphile/ https://hasura.io/ https://www.prisma.io/ There are plenty of "REST API in a box" solutions as well: https://github.com/PostgREST/postgrest https://github.com/prest/prest https://resthapi.com/

I ultimately chose Postgraphile over Hasura. Mostly because the Postgraphile codebase seemed way hackable, written in TS/JS with a plugin architecture. I've tried some Haskell and that's just a whole nother world I don't have time to learn. So far it's working great for me.

I've always been a huge fan of the Graphile (aka postgraphile) approach. It's just an open-source library, that you can run as a binary when you're just getting started. But when you start getting deep in production territory, it's extensively pluggable and you can gradually swap everything out for your own code, contribute/fork if you need (it's just TS), etc. Full control.

I love the Hasura folks too, and they're a funded startup rather than a one-person operation relying on donations. Open source is hard, and benjie (creator of graphile and many other things, he's incredible) could use some help: https://www.patreon.com/benjie

Re: Hasura raises $9.9M to simplify GraphQL

#107

Post by rattray »

vosper wrote: post #105
markhalonen wrote: post #65

Earlier quoted context omitted.

I ultimately chose Postgraphile over Hasura. Mostly because the Postgraphile codebase seemed way hackable, written in TS/JS with a plugin architecture. I've tried some Haskell and that's just a whole nother world I don't have time to learn. So far it's working great for me.

FWIW, I went the other way, mostly because I found the GraphQL queries that I wrote in Hasura to be much nicer to read than the equivalents that I got with Postgraphile.

Interesting; can you provide an example? Sounds like a nice way to compare various approaches to GQL queries, and general best-practices...

Re: Hasura raises $9.9M to simplify GraphQL

#108

Post by vosper »

deckard1 wrote: post #83
buhrmi wrote: post #37

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

GraphQL is mediocre. It's luke-warm mashed potatoes from a chain diner. Having used it for a number of years now, I still don't know why people recommend it beyond other people recommending it. Out of the box, it comes with no batteries included. Which explains the cottage industry that popped up to support it (Apollo, Hasura, etc.). Simply making GraphQL as efficient as bog-standard REST without involving the use of…

> Not nearly as big of a deal as writing the mountains of boilerplate to get a new GraphQL query up and running

This is the thing Hasura (and Postgraphile) is trying to make go away. From my limited experience with Hasura, it works pretty well.

Re: Hasura raises $9.9M to simplify GraphQL

#109

Post by rattray »

MadWombat wrote: post #103

One thing that bothers me about systems like this is the underlying assumption that database architecture always reflects the presentation. But what if ti doesn't? I am looking at the Hasura docs and all it really says is "we will generate everything for you based on your database schema and here is the way we do it". But what if I don't want some tables to be exposed? What if I want to expose custom queries instead…

I think the philosophy behind this is that you're supposed to end up doing extensive presentation work in the DB itself through generated columns, views, access control, functions, etc.

It requires you to learn more arcane technologies (postgres functions are a bit less beginner-friendly than, say, ruby on rails) but these are also great technologies to know.

My guess is that a production hasura/graphile/prisma app would end up having a large number of custom resolvers by the time it's seen a few years of heavy production development as well, and that the built-in gql queries would serve more as scaffolding for prototypes, but I've never made it that far myself.

Re: Hasura raises $9.9M to simplify GraphQL

#110

Post by rattray »

gketuma wrote: post #47
crubier wrote: 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!

I agree. PostGraphile needs to market itself though. They need a Dev Rel to make more people aware of it.

They're a husband/wife team, purely OSS, with little funds; you can donate here: https://www.patreon.com/benjie
Post reply on HN