[HN Gopher] Hasura raises $9.9M to simplify GraphQL
___________________________________________________________________
Hasura raises $9.9M to simplify GraphQL
Author : pritambarhate
Score : 301 points
Date : 2020-02-27 10:27 UTC (12 hours ago)
(HTM) web link (techcrunch.com)
(TXT) w3m dump (techcrunch.com)
| aloukissas wrote:
| I want to bet there were zero Greek VCs in the round :D (in
| Greek, "hasura" means huge loss, especially in investing context)
| bdcravens wrote:
| Odd. Google Translate says it's "encountered"
|
| https://translate.google.com/#view=home&op=translate&sl=el&t...
| aloukissas wrote:
| You're looking something more like https://translate.google.c
| om/#view=home&op=translate&sl=auto...
|
| The spelling "hasura" is in what we call "Greeklish", i.e.
| Greek in English (ASCII, really) characters. This was common
| in early 2000s, where utf-8 support was not everywhere (web,
| SMS, etc) and writing in Greek characters had a high chance
| that the recipient would receive mumbo-jumbo.
| haolez wrote:
| 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/
| xemoka wrote:
| 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.
| jamil7 wrote:
| It's also really nice, I think the appeal of Hasura is to
| leverage all the GraphQL clients. Things like Apollo save a lot
| of time in React and iOS for example since they abstract the
| whole service layer. I'm not sure if something similar exists
| for PostgREST.
| marton78 wrote:
| How do you make subscriptions work with PostgRest?
| treyhuffine wrote:
| Very excited to see this. Hasura has transformed how I build
| apps.
| k__ wrote:
| A small comparison:
|
| https://www.moesif.com/blog/graphql/technical/Ways-To-Add-Gr...
| afvictory wrote:
| Congrats to the Hasura team!
|
| Hasura is truly a marvelous piece of software when it comes to
| rapidly prototyping and getting things out into production. We
| discovered Hasura a couple years back at my previous company when
| it was still in beta and we were amazed with how easily we could
| automate most of our CRUD logic. I will definitely be using
| Hasura again when the time comes around.
|
| On a more recent note, I currently have a client who's prototype
| was built with Hasura but one of their requirements was to
| migrate to AWS and use as many of the PaaS offerings as possible.
| We ended up using AppSync[1] and it is fairly impressive. I
| highly recommend anyone who is stuck in the AWS ecosystem to
| check it out. AppSync integrates with a lot of other AWS services
| (Cognito, S3) very easily and allows you to use
| Dynamo/Aurora/RDS/Elastic as data sources. On top of this, you
| can also use Lambda to implement resolvers that need more intense
| business logic, making the service incredibly powerful.
|
| [1] https://aws.amazon.com/appsync/
| adminu wrote:
| We used appsync at my company and switched to a more classical
| approach of handwritten crud, a REST Api, a RDS (not entirely
| sure how well you can use them with appsync) away from
| dynamodb. Appsync was just not mature enough, had bugs and
| severe limitations. Without someone in the team who really
| knows Appsync, I would recommend against it and towards the
| tech you know.
| afvictory wrote:
| What was the biggest hurdle you ended up facing that ended up
| being the dealbreaker for your team?
|
| I think for us, the biggest issue so far has been figuring
| out some of the more involved Velocity templates as the
| documentation is fairly sparse and testing them can be a
| pain. Thankfully this project isn't too business logic heavy
| but due to time constraints, we ended up writing Lambdas for
| templates we could not figure out quickly.
| worldsayshi wrote:
| I often miss graphql features when working with rest APIs. But
| switching over seems very much not worth it when no one in the
| organisation knows graphql.
|
| I feel like graphql would be much easier to adopt of it just
| sticked to rest conventions as much as possible. Like have the
| query language be pure JSON.
|
| It should even be possible to design it so that you could make
| drop in replacements for most of existing rest APIs.
| kandros wrote:
| GraphQL is much easier to pickup and get productive than most
| people think, most of the times all you have to do is writing
| resolvers (functions) instead of http handlers (functions)
|
| On the client side is the same, following any getting started
| guide can explain 90% of what you need to know in a single day
| vlozko wrote:
| Client side GraphQL is harder than REST, though I wouldn't
| define it hard in general. Whereas with REST one only needs
| to update the data model for the response, GraphQL also
| requires that the request itself is also updated. It gets
| more complex if the client wants to take advantage of hashed
| queries and now there's all this work needed to upload the
| queries to some backend service. This is from my own
| experience -- I haven't worked with Apollo to know how much
| of this process is simplified for you.
| kandros wrote:
| The situation you are referring to is actually a great
| plus, If you change the data model in you backend, you
| client consume it and thus depend on it, so you still have
| to change the frontend code anyway, knowing exactly what
| you can ask and how it will come back makes it a very
| powerful developer experience with a lot of test that don't
| need to be write thanks to tooling around a type system and
| a faster feedback loop.
| vlozko wrote:
| Oh, I'm not suggesting that it's a worse way to do web
| requests at all. I genuinely enjoyed working with GraphQL
| despite all the build/CI headaches it can potentially
| cause. I was really addressing the sole point of
| difficulty of working with REST vs GraphQL and I'd
| unquestionably say REST is easier. It's not a statement
| of which one is better or worse.
| sadturnip wrote:
| I tried Hasura in the past and unfortunately found it unsuitable
| for our auth requirements. There is no way currently to hook into
| their authorization system, you get extremely basic RBAC and if
| that isn't good enough for you too bad.
|
| For example we currently are required to talk to some external
| auth services (depends on the customer) and fetch the users
| permissions based on that, (e.g. user can READ notes, and WRITE
| notes but not delete NOTES). At the time we had an extremely
| simple express middleware that handled this.
|
| Also the entire idea that i need another GraphQL or rest server
| to do any sort of custom validation/custom actions made me do a
| double take and more or less killed any interest to me.
|
| We ended up using NestJS with their GraphQL tooling and
| objection.js and never looked back. Ironically the adoption of
| the GraphQL version of our API compared to Rest is almost 0.
| tango12 wrote:
| Hasura's authz is whatever authz you can derive from the data
| within your database or from the claims embedded in the authn
| token. If you have a table that contains the claims for each
| user, then you can reference that in the authz rule for any
| other table/view/function. READ notes if user.is_note_reader =
| true.
|
| We're working on making it easy to integrate resource claims
| and rule engines that are external as well (make an IO call
| instead of embedding the rule in the SQL query itself). The
| good news is that it is possible to do at the Hasura layer
| because Hasura owns the RBAC so we'll get to it soon enough :)
|
| Over the last few months, we've seen users flip from their
| custom GraphQL servers to using Hasura because of the reduction
| in code/maintenance that Hasura brings for their use-cases.
| Especially when you have a large number of tables. Being able
| to manage authorization rules at a "type" level instead of a
| "resolver" level also makes things convenient.
|
| We've also started work on making it easy to integrate REST
| APIs for custom logic (esp writes) which also helps skip a
| bunch of GraphQL/authz boilerplate:
| https://blog.hasura.io/introducing-actions/
| sadturnip wrote:
| Unfortunately we do not have these claims defined in our auth
| token or the datasource hasura is attached to. We have an
| external session cache service in Redis. If the user isn't
| cached we need to hit an internal API to attempt to fetch
| this information for us and return it to us. No user
| information is stored in our auth token/database.
|
| Actions look painful, i don't want to write and maintain
| microservices just to do simple actions. I just want to be
| able to write code and handle the hook around the function.
| Also from the link it only seems like actions occur AFTER
| something happens, i need the ability to run before changes
| are persisted.
| headgasket wrote:
| I've been using postgraphile over hasura for while, initially
| because of some JWT business. That thing rocks. RBAC and JWTs are
| a killer feature for public facing stuff.
|
| Congrats to the folks at hasura for the raise, long live postgres
| and graphql.
| skinnyarms wrote:
| I'm excited anytime a technology comes along that makes for great
| user experience AND developer experience. I can demonstrate the
| value that Hasura provides to either side in minutes.
|
| The subscriptions are particularly interesting to me, I've never
| seen anything else that makes web sockets so easy to implement.
| I'm very optimistic for their future.
| michelpp wrote:
| A huge benefit that tools like Hasura, Postgraphile and PostgREST
| provide is using the native in-database row level security model.
|
| Consider Django. Your django app logs into the database typically
| as a user with elevated permission that is a superset of all
| permissions required by your users. Postgres has no idea that
| django is acting on behalf of many users, all it sees is this
| django super-like user. If an attacker roots your Django
| instance, they have the same privileges. If your PHB decides to
| "help" and log in with creds found in the source code, the damage
| could be catastrophic.
|
| Products like Hasura, Postgraphile and PostgREST switch databse
| roles on the fly per-request. The user that these tools logs in
| as typically has almost no privileges. You must be the bearer of
| a valid JWT token to elevate privileges, and then you only get to
| the level of the user you stole the token from. There is NO
| super-like user.
| djstein wrote:
| +1 for Django
|
| the Graphene implementation for Django brings up a Relay
| GraphQL server so fast. The best part is that at compile time
| it ensures your GraphQL schema confirms to the Relay standard,
| enforcing correct naming. You really don't have to think about
| much.
| sfilipov wrote:
| > A huge benefit that tools like Hasura, Postgraphile and
| PostgREST provide is using the native in-database row level
| security model.
|
| I agree with your overall comment. Note that Hasura doesn't use
| the native row level security in Postgres. They implement the
| layer themselves. There are two reasons: 1) Hasura is older
| than the first release of Postgres that included the row level
| security feature. 2) Their implementation scales better when
| there are a lot of users subscribed to the same GQL
| Subscription. When using row level security, every user's query
| result looks different, so they need to create a database
| subscription / polling for each user GQL Subscription. Their
| implementation allows them to have a single PG subscription
| (well they mostly do polling), get all the data back, then
| strip down on the way out to the GQL subscribers.
| awb wrote:
| 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/
| markhalonen wrote:
| 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.
| vosper wrote:
| 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.
| rattray wrote:
| Interesting; can you provide an example? Sounds like a nice
| way to compare various approaches to GQL queries, and
| general best-practices...
| marton78 wrote:
| Wow that's interesting! I chose Postgraphile exactly for
| this reason: because it lets me customize the schema to a
| degree that looks just as if I had written it by hand. I
| found the schema created by Hasura incredibly verbose.
| jannotti wrote:
| Yes, please say more. I've been idly looking that these
| both from a distance and I would not have expected
| differences along that dimension. I would expect the expose
| nearly identical GQL types from the same pg schema.
| rattray wrote:
| 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
| o1lab wrote:
| For rest apis on mysql instantly -
| https://github.com/o1lab/xmysql/
|
| (shameless plug)
| misiti3780 wrote:
| add apollo too, no?
|
| https://www.apollographql.com/
| lukaspili wrote:
| I started with Hasura and I implemented it on two business
| projects. It was a great first step but the lack of
| customization quickly became an issue. Having the logic split
| between several services was another big issue (Hasura +
| firebase auth + serverless functions for any logic). Ultimately
| it resulted in a slower development speed than what we were
| doing at my company before using Hasura (custom GraphQL backend
| development).
|
| Several months ago we switched to Postgraphile, and it solved
| the issues mentioned above. The plugin system allows us to
| implement the custom logic in a simple and performant way,
| whether it's a custom validation on a mutation or tweaking the
| GraphQL type system. And all the logic is centralized in one
| project. It's clean, fast and testable.
|
| Another big advantage is that Postgraphile relies on Postgres
| RLS for permissions, which allows us to manage it using normal
| SQL migrations. In comparison, we had a lot of pain evolving an
| existing permission schema on Hasura.
|
| Postgraphile can also automatically expose a Relay compliant
| schema, supporting Relay connections. It's not possible with
| Hasura.
|
| Except for pure read-only GraphQL APIs, I strongly recommend
| looking into Postgraphile over Hasura.
| rojobuffalo wrote:
| 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.
| awb wrote:
| Curious if you were active on the precursor to postgraphile
| why you feel Prisma is a better option. It's been my
| experience as well, but would love to hear what the deciding
| factors were for you.
| cpursley wrote:
| 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 I put together:
| https://github.com/cpursley/react-admin-low-code
| jo-m wrote:
| Looks cool! I cloned it and ran it locally. I noticed there was
| no backend running locally, and then saw it points to
| https://low-code-api.herokuapp.com/v1/graphql. Is the code
| running there available in a repo too? It would be super nice
| if you could link to it from the project README.
| cpursley wrote:
| When I have a chance I'll refactor this so that it uses a
| local docker Hasura and Postgres instance.
| [deleted]
| joshmarlow wrote:
| Tangentially related: As a side project, I've been building a
| backen-as-a-servive platform with a GQL interface derived from
| the data model and business logic.
|
| Posting here as it may be of interest to readers: l
| https://massiveinference.com
| jonatron wrote:
| Django has had an automatic admin site since 2006 or earlier,
| this isn't a game changer for me.
| alharith wrote:
| Yeah, pfft, Java EE has had this since the early 2000s too.
| What's old is new again, amirite??
| cpursley wrote:
| So has Rails via Active Admin.
|
| The advantage is React Admin is back end agnostic and you can
| tap into the huge React ecosystem. And with Hasura you get
| automatic GraphQL endpoints (Django nor Rails Active Admin do
| this - you have to create models first vs just a schema with
| Hasura) which can be used for more than just your admin
| backend.
| yen223 wrote:
| Having built and maintained large Django apps for the past
| couple of years, I personally prefer Hasura's admin console
| over Django's one, not least because you don't need to
| write any code to get it started!
|
| Hasura also ships with websocket support, something that
| Django has always struggled with.
| michelpp wrote:
| These aren't the same things. Hasura is not an admin
| interface, although it provides something like one. It's an
| application API.
|
| The django admin interface is not usable by a frontend as an
| application API.
|
| Django requires you to "meta-model" you have to write Python
| classes that map to your tables, this is usually duplicate
| work.
|
| Django's ORM must support many databases, so it produces
| "least common denominator" SQL and is (stock) oblivious to
| Postgres' many enhanced data features, you are forced to use
| various community sourced extensions to get access to
| features that have been in postgres now for many years.
|
| Django's security system is django only. You are forced to go
| through django for access control across your business.
| Eventually this abstraction leaks, and someone starts logging
| into the db from some other framework and now you have two
| problems.
|
| This is my opinion and I'm sure I'll get downvoted for it,
| but Django, Rails, Node, all the Java frameworks, all the
| meta-modeling and NIH syndroming, are all utterly obsolete.
| Everything they do can be done in 99% SQL by a data scientist
| with the help of a competent DBA. "Web application
| programming" is going to go the way of the dodo bird and devs
| who don't start learning higher level skills like complex
| SQL, statistical modeling, linear algebra, and to either be a
| competent DBA or learn how to treat them fairly with be the
| first batch of programmers "automated out of a job" by tools
| like Hasura.
| RussianCow wrote:
| > Django requires you to "meta-model" you have to write
| Python classes that map to your tables, this is usually
| duplicate work.
|
| You don't have to duplicate any work because you don't
| actually have to write any raw SQL, since it all gets
| translated by Django. So yes, there's an extra layer of
| abstraction there, but no duplication on the developer's
| part.
|
| > Django's ORM must support many databases, so it produces
| "least common denominator" SQL and is (stock) oblivious to
| Postgres' many enhanced data features, you are forced to
| use various community sourced extensions to get access to
| features that have been in postgres now for many years.
|
| Practically every Django release adds support for more and
| more database-specific features out of the box, to the
| point where I don't remember the last time I had to use a
| third-party library to take advantage of a PostgreSQL
| feature. But even if you do, so what? It's no different
| than using a Postgres extension.
|
| The HUGE advantage that ORMs like Django, Rails, etc have
| over writing raw SQL is their composability. Django
| provides lots of tools that make it VERY easy to reuse code
| relating to models and querysets, whereas SQL is
| notoriously difficult to keep DRY. And this issue gets
| significantly worse when you start to pull in data that
| lives outside of the DB.
|
| On top of that, there is the more obvious issue that good
| DBAs are rare and expensive compared to
| Python/Ruby/whatever engineers.
|
| > Django's security system is django only. You are forced
| to go through django for access control across your
| business. Eventually this abstraction leaks, and someone
| starts logging into the db from some other framework and
| now you have two problems.
|
| I do completely agree with this, and I think it's Django's
| weakest point by far. But you can always forego the ORM's
| integrity/trigger features and add those at the database
| level in your migrations.
|
| > This is my opinion and I'm sure I'll get downvoted for
| it, but Django, Rails, Node, all the Java frameworks, all
| the meta-modeling and NIH syndroming, are all utterly
| obsolete.
|
| Hasura and related projects are really great, don't get me
| wrong, but this is outright FUD. There are pros and cons to
| both approaches, and to claim that one is "utterly
| obsolete" is nonsense. There are lots of situations in
| which turning the database into your API just doesn't make
| sense.
| michelpp wrote:
| > You don't have to duplicate any work because you don't
| actually have to write any raw SQL, since it all gets
| translated by Django. So yes, there's an extra layer of
| abstraction there, but no duplication on the developer's
| part.
|
| There is still some duplication of effort, for example
| when you change the model, yes django will create the
| migration script for you, but you always have to verify
| it and often change it especially when you're merging
| branches. And since the migrator only supports a subset
| of postgres' DDL abilities, even simple things like
| renaming objects, or applying advanced indexing
| techniques you often have to write hand sql migrations
| anyway, which require you knowing sql, so why not just do
| all in sql?
|
| > Hasura and related projects are really great, don't get
| me wrong, but this is outright FUD. There are pros and
| cons to both approaches, and to claim that one is
| "utterly obsolete" is nonsense. There are lots of
| situations in which turning the database into your API
| just doesn't make sense.
|
| It was a strong statement of an unpopular opinion, but
| FUD is a fundamentally dishonest statement, and I did
| clearly prefix my statement with "This is my opinion and
| I'm sure I'll get downvoted for it". As someone who knows
| my opinions well you know I honestly believe it. But
| that's ok I appreciate you keeping me on my toes when the
| coffee gets me in an agitated state!
|
| That being said, I still do believe it. I do pick on
| Django pretty hard, but I feel the same way about many of
| the Python frameworks to a certain degree and the "web
| application framework" pattern in general. Django is just
| the one I have seen the most bloviated circumlocution of
| code to do simple tasks with, and often when I have run
| into problems with Django, it was usually Django's fault
| (ahem, autocommit) not the developers. It's a classic
| foot gun.
|
| A recent example I have had to boggle at, a half dozen
| AppEngine microservices, cross calling each other with
| http RPC all autocommiting to 3 different postgres
| databases with less than 100k rows of data total. The
| microservices were entirely responsible for maintaining
| referential integrity entirely defeating the point of
| using postgres in the first place.
|
| The whole thing could have been a set of simple
| functions, much of the heavy lifting could have been done
| with some simple triggers. But instead "microservices".
| That worked ok when there was only one instance of each
| service, but then when app engine scaled up it became a
| knot of race conditions.
| RussianCow wrote:
| For the record, I do agree with your general sentiment
| that many of these abstraction layers are unnecessary,
| and in many ways harmful. Especially when it comes to
| data integrity, trying to enforce constraints and
| triggers at the application level is always going to be
| clunky and error prone, and monolithic frameworks like
| Django and Rails actively encourage you to do everything
| at their level and give you many ways to shoot yourself
| in the foot. But I also don't think Hasura and
| Postgraphile and related projects are the silver bullet.
| Why can't we have something in the middle? How about a
| web framework that leaves data integrity up to the DB and
| just gives you an easy way to "glue" together bits of
| logic and queries, and do migrations, etc? Or even just
| use Django/Rails/whatever but don't use the footgun
| features? At least then, if/when you _do_ need to scale
| (in any sense of the word) past what a relational DB can
| offer you, you can easily do that instead of trying to
| shoehorn everything into the DB.
|
| Aside: I'm working on a GraphQL library for Python that I
| hope will fulfill these goals, but development on it has
| stalled due to lack of time. Hopefully I can pick it up
| again soon.
|
| FUD may have been strong, but in general I detest when
| people decry entire categories of technology as being
| "wrong" or unfit in an absolute sense (or, conversely,
| tout a technology as a silver bullet), when in fact
| everything has its tradeoffs and there are good reasons
| to use almost anything. Understanding those tradeoffs is
| vastly more important than searching for the universal
| answer to everything.
|
| PS: Hope you're doing well! :) Your contact info isn't on
| HN, but email me if you want to get coffee/lunch
| sometime!
| airstrike wrote:
| I don't know. I have a feeling the minute you start having to
| write complex SQL-equivalent queries outside of SQL, you're in
| trouble.
|
| I love Django, but even its amazing ORM has limitations. I
| can't imagine what it's like to deal with something similar but
| on the frontend instead...
| icemelt8 wrote:
| Wow I didn't know about React Admin, this is amazing.
|
| Now I just need a way to migrate my data from somewhere else to
| Hasura.
| rhlsthrm wrote:
| Man, there's so many cool ways to build CRUD apps nowadays, I
| wish I just found a good opportunity to write one!
| latch wrote:
| 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 a ton of
| tests to cover all the cases. It's time consuming, even
| tedious, and it's boring / simple compared to the user facing
| stuff we do.
|
| I've never touched GraphQL, so can that really save me months
| of work? Or would it save me about as much time as Rails would
| (which would be not a lot) ?
| karatestomp wrote:
| 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.
| simplify wrote:
| GraphQL by itself won't save you time, and might even
| increase it (it's a huge buy-in). You'd still have to
| implement the logic for those 4 endpoints, except now in a
| more complicated system.
|
| In contrast, tools like Hasura and Postgraphile can
| _potentially_ save you time because they _generate_ the
| GraphQL part for you. Then you only need to handle the authN
| /authZ parts - in theory, at least.
| tango12 wrote:
| 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
| benfle wrote:
| Is it a good idea to base your GraphQL schema on your database
| schema?
|
| Isn't the point of GraphQL to decouple your interface (who should
| not break) from your backend implementation details?
| linkdd wrote:
| You would never expose your database directly to the whole
| world.
|
| Either it is an internal service, only consumed by your own
| products, and then it's fine. Or you have an API gateway to
| control who and how your services are queried.
|
| The API Gateway is your interface who should not break. Your
| services communicating with your database (through Prisma,
| Hasura, any ORM, ...) can and will break.
|
| When you base your GraphQL schema on your database schema for
| your internal services, you get rid of one long and annoying
| step of putting glue everywhere. This is especially true in a
| microservice architecture, and even more in the corporate world
| where you are expected to produce code quickly.
| michelpp wrote:
| > Is it a good idea to base your GraphQL schema on your
| database schema?
|
| You don't. Hasura (and Postgraphile and PostgREST) employ in-
| database modeling tools called views. Views provide the same
| modeling abstractions that ORMs provide.
|
| https://www.postgresql.org/docs/12/sql-createview.html
|
| A view is a canned query with a name, and when you get down to
| it, all an ORM is doing is producing, usually poorly, a query
| from a named abstraction. Same thing. So why have two pieces in
| two languages when you can have one?
|
| > Isn't the point of GraphQL to decouple your interface (who
| should not break) from your backend implementation details?
|
| Views provide the same or better decoupling. They database is
| aware of them, they are type checked, you can't even make a
| view that references an unknown column, for example.
| wesleyfsmith wrote:
| Can someone explain to me how this differs from Apollo? Is it
| that it has a tighter integration with the DB layer?
| yen223 wrote:
| It's definitely cool to see Haskell projects getting used in
| industry. I am a big fan of Hasura and the value it gives in the
| GraphQL space.
| kandros wrote:
| 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 which I consider this a really good
| solution is in a CQRS system where the database attached to
| hasura is read only via graphql and the data is inserted by other
| services making it a typesafe single source of truth to read from
| tango12 wrote:
| On that last bit, we recently added actions:
| https://hasura.io/blog/introducing-actions/
|
| Writes (mutations) are delegated to a REST endpoint, the
| GraphQL mutation response can be synchronously (blocking
| mutation) or asynchronously consumed (mutation + subscription).
| kandros wrote:
| The sync part is very interesting, I like that it's happening
| after the mutation so that Im not forced to reimplement the
| graphql types myself.
|
| Will give it a try, thanks
| tango12 wrote:
| Yep! The GraphQL resolution logic and the permissions get
| reused automatically.
| kandros wrote:
| I gave it a try, to be honest, I feel it too cumbersone,
| I expected it to use already available mutations not just
| copying existing types.
|
| What I really want/need is custom logic that run IN the
| resolvers of already available query/mutations with the
| request as input and the possibility to either return an
| error or modify the payload before it hit the database
|
| but I know is still in preview, will check it again when
| released
| lukaspili wrote:
| Agree. This is one of the issue we have with Hasura and
| it's what made us switch to Postgraphile.
| betocmn wrote:
| Exactly! It could be useful for simple apps if they add a way
| to create basic validation rules with regex.
| tango12 wrote:
| The Hasura console actually makes it quite easy to manage
| check constraints and validation rules! :)
|
| Here's an example for a regex for validating email from one
| of our community calls: https://youtu.be/-9jX21PKyk0?list=PLT
| RTpHrUcSB8Dp3hk5SiVNHNP...
| yen223 wrote:
| Hasura runs on top of a plain old Postgres database. You can
| use CHECK constraints to implement validation rules,
| including regex rules
| endymi0n wrote:
| 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
| Hasura or PostgREST and then offers ,,upgrades", first via
| configuration, later via custom code hooks.
|
| That would be pretty awesome from a migration path perspective.
| [deleted]
| lurker2003 wrote:
| Check out Postgraphile, it allows you to start off with
| introspection, then customise it with comments, then add
| custom bits in node.
|
| Both Hasura and Postgraphile also support schema stitching
| from what I know, so you should be able to extend it that way
| also (more complicated obviously)
| milkanic wrote:
| Related, How does one receive a webhook in Hasura? Say I need
| to take some action on a Stripe rest webhook. All the docs show
| sending events somewhere, how about receiving and transforming
| data from 3rd parties?
| gsvclass wrote:
| Not a startup but still a very feature rich GraphQL to SQL
| compiler service works with Postgres and YugabyteDB. Written in
| GO. https://github.com/dosco/super-graph
| armatav wrote:
| Firebase, React and Hasura let me set up new app ideas in like
| negative time. Hasura is especially amazing because of it's
| authentication handling and migration management.
| elitan wrote:
| This is fantastic to see. First time I tried out Hasura back in
| late 2018 I was AMAZED.
|
| After going through multiple different stacks such as MeteorJS,
| Firebase, building my own REST/GraphQL API etc. Nothing really
| felt right.
|
| That was until I found out about Hasura.
|
| I actually had to assemble a quick meetup at the co-working space
| I was on (true story) to show everybody this software. Hasura
| Tweet:
| https://twitter.com/HasuraHQ/status/1068145251267895300?s=20
|
| They were all amazed and many use Hasura in production today in
| their apps.
|
| For myself, I was so enthusiastic about Hasura and I always had
| Google Firebase in the back of my mind. Google Firebases DX is
| really good. I really liked it. But I did not like their tech
| (noSQ / REST / vendor lock-in).
|
| So, I decided to start https://nhost.io.
|
| Nhost is like Google Firebase but with PostgreSQL and Hasura
| (GraphQL). Right now providing database, API, auth and storage.
| Here is a short demo: https://www.youtube.com/watch?v=MWB5RXzlJM8
|
| I feel very fortunate to be able to work with such awesome open
| source software and the success of Hasura makes me so happy,
| because they are, as mentioned in the comments field before me, a
| game-changer!
| rsp1984 wrote:
| Firebase user here. I love Firebase because it offers so many
| components that (usually) play well together: Databases,
| Authentication, Machine Learning, Storage, Crash Reporting,
| Analytics, Messaging etc.
|
| Which parts of Firebase is Nhost replacing?
| city41 wrote:
| I've been shopping around all the BAAS offerings and nhost is
| really intriguing. Thanks for sharing.
| elitan wrote:
| Happy to hear. Let me know if you got some advice for us to
| improve the product.
| city41 wrote:
| I'm reading through the docs now. They are pretty good! I
| assume I could just use say Apollo on the client? Maybe
| that part of the docs could use some additional info.
| elitan wrote:
| You are correct. You can use any GraphQL Client. Hasura
| has done an awesome job with tutorials here that you
| should look at:
|
| https://hasura.io/learn/
| city41 wrote:
| Ah that makes sense, didn't even think to look there.
| Awesome, thanks for the help!
| dvasdekis wrote:
| Early nhost user here! Elitan's platform is a great way to get
| started quickly with Hasura, and he was also fantastic with
| helping me out on some then-undocumented components. Always
| grateful when a developer takes time to do a 1:1 call.
|
| Thanks again!
| code-is-code wrote:
| If you love hasura and want something like firebase, please
| check out the tutorial with hasura + RxDB. It is like having a
| firebase with better offline-first and more features and of
| course without vendor lock-in.
|
| https://hasura.io/blog/building-an-offline-first-web-app-wit...
| elitan wrote:
| What I liked with Firebase was how easy and fast everything
| was. One-click create a new project and everything was ready
| to use.
|
| It's this developer experience I want to mimic with Nhost. By
| providing a managed backend with simple to use js-sdk
| (https://github.com/nhost/nhost-js-sdk).
| SkyPuncher wrote:
| I had the opposite experience with Firebase.
|
| Amazing at first, but quickly fell apart when I had to
| implement any sort of meaningful business logic.
| lucasverra wrote:
| I'm a web entrepreneur and for my project i've been using
| Parse server project (1) implementation by Back4app (2).
| For the non initiated, Parse server is a API server module
| for Node/Express + mongo + websocket and stuff you need to
| run a commercial app like auth, role management et all.
|
| We chose this because :
|
| 1.Open source (no vendor locking although now i'm sure if i
| had to move from b4a it would be a small PITA 2. Ready to
| use 3. actively maintained (graphQL have been implemented
| although we have not used it yet) (3)
|
| My question is : should i invest time on discovering nhost
| for my next POC ?
|
| (1) : https://github.com/parse-community (2) :
| https://www.back4app.com/ (3) :
| https://docs.parseplatform.org/graphql/guide/
| pramodliv1 wrote:
| I spent 3 days setting up Hasura a few weeks ago and I wish I'd
| known about Nhost.
|
| Do you know why Hasura don't provide a managed service
| themselves?
|
| Also, I wonder if Hasura will eventually move to a MongoDB-like
| license.
| elitan wrote:
| I'm sorry that we are not doing a better job marketing Nhost.
| We have been very focused on the product but we hope to get
| the word out better in the future. Because you are not alone.
| There are lots of developers with the same problem, that just
| want things to work.
|
| Hopefully, we will be mentioned in the documentation for
| Hasura.
|
| Hasura does provide a hosted version (EDIT: not a hosted
| version) (Hasura Pro). You can read more about it here:
| https://hasura.io/hasura-pro
| tango12 wrote:
| Hey!
|
| 1. We're working on adding nhost to the Hasura docs as a
| deployment guide for when you'd like authn + files + hosted
| postgres in one neat place. Johan just did a slick demo in
| the community call right now :)
|
| 2. To clarify: Hasura Pro is not a hosted version of
| Hasura. It's an agent that is added to wherever Hasura
| happens to be running for enabling monitoring/testing
| features.
| samblr wrote:
| Just tried hasura, it is amazing to get all crud graphql apis
| out of box.
|
| How do we add business logic ?
|
| Folks @hasura, where do we learn about haskell ? any helpful
| pointers much appreciated.
| elitan wrote:
| For business logic, there are a few alternatives.
|
| 1. Actions -
| https://hasura.io/docs/1.0/graphql/manual/actions/index.html
|
| 2. https://3factor.app/
|
| 3. Remote schemas -
| https://hasura.io/docs/1.0/graphql/manual/remote-
| schemas/ind...
| pyrale wrote:
| You may enjoy the work done by Julie Moronuki and Chris
| Martin. They do lots of great learning stuff related to
| haskell.
| cargoshipit wrote:
| > How do we add business logic ?
|
| Awkwardly. Good luck
| dvasdekis wrote:
| I'm running a full production algorithmic trading platform,
| and our frontend interactions are handled by Hasura. For me,
| the appeal was in writing all the business logic as
| Postgresql triggers, which (provided they're written as true
| SQL and not plpgsql), scale beautifully with load. Hasura has
| a real appeal when you're keen to do your important logic in
| SQL.
|
| Check out the result here: http://www.hedgecheap.com
| saadshamim wrote:
| @elithan this looks awesome man. The one thing keeping me in
| the firebase ecosystem is the firestore rules (basically quick
| CRUD permissions). Does nhost provide something similar?
| elitan wrote:
| Yes. Hasura handles this in their permission system and they
| do an excellent job. Super easy to get started with.
|
| Together with Nhost's auth system and Hasura, it's easier
| than Firebase.
| pier25 wrote:
| Do you offer rate and depth limiting?
| saadshamim wrote:
| Hasura has this feature, but unfortunately it seems like its
| part of their "pro/enterprise" offering and not the OS
| version. https://hasura.io/hasura-pro
| [deleted]
| caniszczyk wrote:
| Awesome to see the GraphQL community growing, there's a GraphQL
| Landscape of tools out there, if something is missing please
| contribute, the GraphQL Foundation is tracking everything now:
| https://landscape.graphql.org/
| shivekkhurana wrote:
| 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 changes.
|
| I do need a server to handle object storage, email and cron so
| it's not a 100% there, but I can see the appeal of rapid APIs at
| low cost.
|
| Also subscriptions are <3.
|
| All the best to the Hasura team.
| tirumaraiselvan wrote:
| 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
| markhalonen wrote:
| What made you choose Hasura over Postgraphile? RBAC is a
| postgres feature, not sure if that would affect the decision?
| aidos wrote:
| 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).
| erdaniels wrote:
| Disclaimer: I work on MongoDB Stitch
|
| This looks really cool and an improvement on Prisma! I
| particularly like the much less bloated schema experience (and
| the builder) along with the easy addition of actions. We've been
| working on something similar but it's great to see improvements
| in the UX of the space.
| rgbrgb wrote:
| Stitch looks cool, first time I'm seeing it (long-time happy
| mongo user via rails/mongoid). Is there a self-hosted version I
| could hook up to an existing app?
| jackdh wrote:
| Do you have anything to add about Hasura? Or is this just a
| straight plug for stitch?
| erdaniels wrote:
| Yep, I modified my comment. I meant to put it as a sub-
| comment where it contextually made more sense.
| z3t4 wrote:
| Myt pet peeve with GraphQL is, why not just use JS objects, and
| use JSON for serialization!? query = {user: {id, name}}
| tango12 wrote:
| There are quite a few ongoing attempts at creating a JS fluent
| client for GraphQL.
|
| We covered a bunch of them here:
|
| https://hasura.io/blog/fluent-graphql-clients-how-to-write-q...
| crubier wrote:
| 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!
| gketuma wrote:
| I agree. PostGraphile needs to market itself though. They need
| a Dev Rel to make more people aware of it.
| rattray wrote:
| They're a husband/wife team, purely OSS, with little funds;
| you can donate here: https://www.patreon.com/benjie
| rgbrgb wrote:
| That was my conclusion looking at them both last year. Hasura
| had an amazing first-time UX, but postgraphile felt like it was
| built with production concerns in mind (testing, integrating
| with larger codebases, easy to add custom or wrap generated
| CRUD resolvers in js/ts). The most off-putting thing to me, at
| the time, was that Hasura's solution for auth was to spin up a
| separate auth service. I prefer a flexible monolith for
| anything with less than 10 devs working on it. Looks like
| postgraphile has started paying attention to the first-time UX,
| but still not as friendly as Hasura's:
| https://github.com/graphile/starter
|
| Both feel kind of limited by forcing you to encode a ton of
| logic in SQL which must be migrated vs a mongoid model you can
| just tweak and commit, but I guess I'm old school and what's
| old is new again.
| pier25 wrote:
| Can you elaborate?
| crubier wrote:
| 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
| pier25 wrote:
| I don't have any horse in the race but other than the "it
| is made in Node" everything else applies to Hasura (except
| the VC thing obviously).
|
| Do you have any other point to sustain this comment of
| yours?
|
| > _my conclusion is that PostGraphile is way ahead of all
| this_
| crubier wrote:
| I mean:
|
| - Like Hasura, has ALL the features of Hasura
|
| - BUT really FOSS with no VC funding, supported through
| Patreon by a super nice team.
|
| - AND I have all the source, in the same language than
| the rest of my stack, the language that my developers
| know
|
| - AND it does not require to run yet-another-microservice
| but is just part of my graphQL server
|
| - AND it is extensible through plugins that blend
| seamlessly in the server (unlike Hasura where I see no
| sign of plugins, and I don't want to write plugins in
| Haskell)
|
| - AND it supports native, super-fast Postgres Row-Level-
| Security instead of rolling their own!
|
| That is very clearly compelling enough to support my
| conclusion, from my point of view.
|
| Let me also mention that I have been burnt by another VC-
| funded GraphQL server company, namely Prisma, which left
| us stuck with an old, non-maintained buggy version which
| is near impossible to patch and build ourselves, while
| they work on their pie-in-the sky Prisma v2 which is
| totally the wrong direction in my opinion.
|
| We jumped ship from prisma, considered hasura, but went
| for graphile and love it!
| pier25 wrote:
| Don't get me wrong, I agree with most of your points as
| I'd prefer to work with Node than Haskell, but I still
| don't see how it is "way ahead" of the other options
| outside of personal preference.
|
| Unless I'm missing something, Hasura is FOSS too.
|
| https://github.com/hasura/graphql-engine
|
| True, Hasura does not have plugins (AFAIK) but you can
| extend it's funcitonality via webhooks and PG views.
|
| As for authorization it may give them more flexibility to
| roll their own.
|
| Anyway, thanks for bringing up PostGraphile. I'll check
| it out!
| markhalonen wrote:
| Reading this makes me so glad I picked Postgraphile.
| k__ wrote:
| It uses many of the built-in PG features.
| mongol wrote:
| Does something like this exist for SQLite?
| ihodes wrote:
| I'm curious if anyone here has compared Postgraphile to Hasura?
| My personal difficulty in implementing these is that there aren't
| good source control and code organization tools for SQL and
| managing rollbacks and rollforwards in a sane way.
|
| (And a way that doesn't require writing rollbacks, which
| sometimes aren't even possible anyway).
| xemoka wrote:
| When I tried them a few weeks back to compare, Hasura provided
| a nice interface, but has a lot going on itself (managing
| relationships on its own, some Auth stuff on its own) and its
| own tooling. Postgraphile relies more on postgres, it embeds
| it's configuration in comments (or external to the dB). Both
| had difficulties with complex relationships and introspection
| across schema boundaries (I want a schema to house my data, and
| views in a separate schema that are accessed by the API tool).
| Both felt like I could configure this problem away, hasura
| wanted me to use their interface to do it, postgraphile wanted
| me to learn magic comments to attach to tables/columns etc
| (again, to tell a view that the table it's drawing from has a
| relationship with another table).
|
| PostGrest has none of these problems, but/and no graphql. It's
| where I landed.
|
| Also, check out dbmate for agnostic rollback management. All it
| needs is a way to template the sql and I'll be happier. Some
| folks using Postgrest use Alembic and SQL Alchemy to
| build/manage migrations--I'm not sure where I sit on that yet.
| sastraxi wrote:
| I've done exactly that with a sample food delivery project.
| Same frontend, but two different backends (one with Hasura, one
| with Postgraphile).
|
| Feel free to check it out: https://github.com/sastraxi/great-
| bear
| cpursley wrote:
| https://hasura.io/docs/1.0/graphql/manual/migrations/index.h...
|
| Their migration tool is really nice; reminds me of Rails but
| better as you can write raw SQL.
|
| https://github.com/hasura/graphql-engine/tree/master/scripts...
| learc83 wrote:
| It's pretty easy to do raw sql rails migrations. I do it all
| the time.
| MadWombat wrote:
| 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.
| rattray wrote:
| 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.
| batmansmk wrote:
| Data-driven architectures are very relevant, in particular in a
| corporate / business environment.
|
| I found all the answers in the docs.
|
| A SQL Schema can carry a custom query, it's called a view.
|
| A SQL Schema can carry a custom algorithm, it's called a
| function or a generated column.
|
| You can always deactivate permissions on a table to not expose
| it, my bet is that your backoffice will need to though.
|
| On top of that, Hasura supports custom resolvers (code driven
| endpoints).
|
| Finally you can stitch 2 GraphQL schemas together. It doesn't
| have to be one size fits all. So even if only 50% of your app
| can fit in the model of Hasura, you can always mix and match.
| It's still 50% that will be up and running in minutes.
| MadWombat wrote:
| > A SQL Schema can carry a custom query, it's called a view.
|
| This is not feasible. I might not have enough access to
| create views. I might not have access to create functions. I
| cannot deactivate permissions if I only have a single access
| account and other systems use it already. You cannot assume
| that I have full control of the database or that I can easily
| make changes to the schema.
|
| But this is not all. I am working on a web backend project on
| daily basis. I would love to offload some basic CRUD
| operations to something like postgrest or implement GraphQL
| with something like Hasura, but I need a way to a) define
| table and field name mappings b) define what tables are
| accessible b) define what columns are visible c) define what
| nested relationships are allowed d) define actions that need
| to happen on update/insert/delete operations (i.e. push a
| message into a queue every time a record is deleted from
| table T) If I could do all of this, I could implement about
| 50% of my web service and it would be useful.
| tango12 wrote:
| > 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.
|
| Hasura internally has a metadata engine that does exactly this.
| You explicitly specify what tables/views/functions you want to
| expose and how you want to expose them. You can use Hasura
| authz to further constrain what data is accessed/returned while
| a query runs. In its default configuration when you start
| Hasura against your Postgres, Hasura exposes nothing.
| MadWombat wrote:
| I will need to take a closer look. If you are right, this
| might be more useful than I thought at a casual glance.
| buhrmi wrote:
| If GraphQL needs $9.9M to be simple enough for developers to
| actually use it, why was it invented?
| bdcravens wrote:
| Probably for the same reason that companies like MongoDB,
| Citus, GitLab, Elastic, and more have taken investment money.
| SteveBash wrote:
| To be fair, some of those are full database engines; they
| have lots of inherent complexity to tackle.
|
| Hasura provides an interface to a database(/s) engine.
| GraphQL was supposed to solve the interface problem but it
| looks like it has created a lot of accidental complexity to
| tackle.
| imvetri wrote:
| Great question
| bdcravens wrote:
| If git needs $436.2M (investment in Gitlab) to be simple enough
| for developers to actually use it, why was it invented?
| crubier wrote:
| PostGraphile is free, try it!
| imvetri wrote:
| 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.
| bdcravens wrote:
| See Ruby on Rails and why Heroku was invented.
| nirvdrum wrote:
| 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.
| jayd16 wrote:
| >GraphQL doesn't fundamentally change the fact that something
| needs to be responsible for enforcing access restrictions and
| talking to a database.
|
| This is what I'm struggling with when it comes to weighing
| the pros and cons of GraphQL. I like the SQL model, ie
| pushing selects and joins and such to the DB, so why not from
| client to host too? But when you still need to enforce access
| restriction and such per user per action, how much time would
| it save me, really?
|
| Seems great for internal apis or prototyping though.
| tensor wrote:
| Hasura and Postgraphile both use row level security for
| access restriction. Anyone can still execute a query, but
| they won't get back data they don't have access to.
| nirvdrum wrote:
| While doable, you probably don't really want a web client
| talking directly to your RDBMS, if for no other reason than
| connection management would be a nightmare. The calculus
| there might be different if using something like DynamoDB,
| but I suspect you'd still find it challenging to be
| littering your code with DynamoDB calls. So, at some point
| you'd build your own little utility classes to abstract
| away the DB interaction, much like an ORM, and eventually
| it'll evolve into something with overlapping functionality
| of GraphQL.
|
| If you accept that you don't want your web client talking
| directly to the database, then you need something that will
| interface with the database. That problem has been around
| for a while with many different solutions: SOAP, ReST,
| PouchDB/CouchDB, interface with various cloud services,
| something completely custom, and many others. GraphQL is
| just one of the latest solutions to that problem and with
| it, brings some advantages around flexibility in the API
| requests and responses. It also makes it easy to stitch
| together multiple GraphQL APIs. So, by being standardized*
| you don't need to develop the client code yourself and you
| gain the ability to pull together APIs from multiple
| sources to present as a single end-point. The most popular
| clients also provide caching mechanisms so you don't have
| to keep whacking the back-end for the same data repeatedly.
| There's also graphiql [1], which gives you a really nice
| way to query or modify your data on any GraphQL API, which
| I've found to be very helpful when learning new APIs.
|
| So far, I've found GraphQL most useful for single page
| applications where the back-end really doesn't have to do
| much more than handle DB interactions. If you already have
| an application up and running with little churn in the API,
| adopting GraphQL probably wouldn't gain you much. In a
| greenfield application, I was able to use Hasura to replace
| a simple Rails CRUD application and that was handy. Hasura
| also takes care of JWT handling, so I could do my auth with
| Auth0 and not handle that in Rails either. I think GraphQL
| solves an interesting part of the serverless puzzle.
|
| Don't get me wrong, GraphQL can be downright frustrating at
| times. Or at least the popular implementations of it can
| be. We use Relay at work and while it solves a lot of
| problems, it introduces many of its own that have cost me
| hours of frustration. I tried using AWS Amplify on a side
| project, and having to write new AppSync resolvers with
| Velocity templates is just not pretty. It really took using
| Hasura for me to finally be sold on what the GraphQL
| promise could be (side note: Hasura doesn't support the
| Relay protocol, so if that's important to you, you'll need
| to find a different tool).
|
| * -- Standardized is a loose term. There is a GraphQL spec,
| but it leaves a lot available to implementation details.
| So, then there are other specs, such as Relay, built on top
| of that. Or de facto standards based on what the popular
| clients provide.
|
| [1] -- https://github.com/graphql/graphiql
| deckard1 wrote:
| 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 half a dozen 3rd
| party libraries is a fool's errand.
|
| Silicon Valley suffers great amnesia and NIH. We've had RPC
| forever now. XML RPC, SOAP, thousands of others that don't
| deserve mention. There is a reason people moved from SOAP to
| REST: you didn't need that complexity. (On a side note, it
| makes me incredibly depressed to be in this industry knowing
| how much time and effort died trying to make XML a thing. When
| was the last time you heard "XML" on Hacker News? Probably been
| awhile. Maybe 5-10 years now. As a piece of news that is, and
| not some random comment from an asshole like me.)
|
| Requesting arbitrary pieces of data on the client side
| (GraphQL's seemingly raison d'etre) is quite easy with REST. So
| easy that it makes me curious how much brain damage the
| industry has to think otherwise. Creating new endpoints even?
| Not a big deal. Not nearly as big of a deal as writing the
| mountains of boilerplate to get a new GraphQL query up and
| running. And considering we're talking about GraphQL, it's most
| likely going to be the same team members working on both sides.
| Why would that not be the case for REST as well? The mind
| boggles. All the arguments against REST that GraphQL camp makes
| are disingenuous at best.
| vosper wrote:
| > 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.
| markhalonen wrote:
| After using GraphQL with code-generated Typescript types on
| the response, I can't imagine going back to REST and it's
| "hope and pray" the JSON looks how you expect it to look
| karatestomp wrote:
| I think part of the actual, non-hyped benefit is that it
| adds type definitions to incoming and outgoing fields on
| the client side. Working directly with JSON is kind of
| fucking awful. Attempts to fix it are often of an even more
| unpleasant "now you have two problems" sort (JSON-Schema,
| for example). Any well-supported standard for typing
| interfaces for data sent to the browser & other REST-
| consuming clients, even if the underlying transport remains
| JSON or whatever, is welcome.
| JMTQp8lwXL wrote:
| Apollo is more than just GraphQL -- it has built-in caching,
| and gives you booleans for loading state, and more. If you
| were to roll your own wrapper around window.fetch, for a
| simpler facade to work with (when making network requests in
| React), you'd end up with something like Apollo's interface.
| And that really useful API surface has nothing to do with
| GraphQL as a specification.
|
| I used to roll all of this stuff from Redux, with actions,
| reducers, the whole 9 yards. Apollo let me gut all of that--
| since I was only using Redux to store data retrieved over the
| network. Now I'm not hear to preach Apollo specifically, but
| it's the only client I've worked with, and I can achieve
| higher productivity with it than working a lower level.
| tensor wrote:
| Hasura is more than just GraphQL. It maps GraphQL queries to
| single SQL statements. So you can think of it more as an ORM,
| but rather than mapping objects to the database it maps
| GraphQL statements.
|
| The advantage of this over a traditional ORM is that by
| having the entire query up front it can be smarter about how
| it does the translation.
|
| Regarding REST, this is very very different. With REST, you
| map a single "query," the REST endpoint, to an SQL statement
| (ideally one). But if you want some other query, you're out
| of luck. Either you make a new REST endpoint, or you manually
| call several endpoints and compose the data.
|
| There are some dangers to the GraphQL to SQL approach, namely
| it's harder to guarantee performance when the client can
| execute arbitrary queries.
|
| Now, GraphQL by itself, I agree it doesn't solve the hardest
| problems: getting the data for the query and doing it
| security. But something like Hasura does address those points
| and I do think it is an advancement over previous
| technologies.
| pritambarhate wrote:
| 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.
___________________________________________________________________
(page generated 2020-02-27 23:00 UTC)