40 ms·
Hasura raises $9.9M to simplify GraphQL
- kandros 7y agoWhile 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
- betocmn 7y agoExactly! It could be useful for simple apps if they add a way to create basic validation rules with regex.
- tango12 7y agoThe 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=PLTRTpHrUcSB8Dp3hk5SiVNHNPJdKNHzFW&t=1465 https://youtu.be/-9jX21PKyk0?list=PLTRTpHrUcSB8Dp3hk5SiVNHNP...
- betocmn 7y agoGreat to know, elegant approach.
- yen223 7y agoHasura runs on top of a plain old Postgres database. You can use CHECK constraints to implement validation rules, including regex rules
- endymi0n 7y agoOften 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.
- lurker2003 7y agoCheck 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)
- deleted 7y ago[deleted]
- tango12 7y agoOn that last bit, we recently added actions: https://hasura.io/blog/introducing-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 7y agoThe 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 7y agoYep! The GraphQL resolution logic and the permissions get reused automatically.
- kandros 7y agoI 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 7y agoAgree. This is one of the issue we have with Hasura and it's what made us switch to Postgraphile.
- milkanic 7y agoRelated, 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?
- haolez 7y agoI 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/ http://postgrest.org/
- jamil7 7y agoIt'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.
- xemoka 7y agoTotally 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.
- marton78 7y agoHow do you make subscriptions work with PostgRest?
- haolez 7y agoProbably by returning an endpoint and a token to a service that will handle the perpetual session. The scope is smaller than GraphQL, but some of the interesting benefits - like smarter and more optimized requests - are available with PostgREST.
- worldsayshi 7y agoI 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 7y agoGraphQL 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 7y agoClient 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 7y agoThe 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 7y ago
- cpursley 7y agoHasura 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 https://github.com/Steams/ra-data-hasura-graphql Here's a reference application I put together: https://github.com/cpursley/react-admin-low-code https://github.com/cpursley/react-admin-low-code
- icemelt8 7y agoWow 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.
- jo-m 7y agoLooks 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 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.
- deleted 7y ago[deleted]
- cpursley 7y agoWhen I have a chance I'll refactor this so that it uses a local docker Hasura and Postgres instance.
- dvasdekis 7y ago+1 for this please! I am struggling with exactly this problem - how do I use React-Admin effectively on top of Hasura? Would really appreciate it! :)
- jonatron 7y ago
- erdaniels 7y agoDisclaimer: 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.
- jackdh 7y agoDo you have anything to add about Hasura? Or is this just a straight plug for stitch?
- erdaniels 7y agoYep, I modified my comment. I meant to put it as a sub-comment where it contextually made more sense.
- rgbrgb 7y agoStitch 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?
- ihodes 7y agoI'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).
- cpursley 7y agohttps://hasura.io/docs/1.0/graphql/manual/migrations/index.html 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/cli-migrations https://github.com/hasura/graphql-engine/tree/master/scripts...
- learc83 7y agoIt's pretty easy to do raw sql rails migrations. I do it all the time.
- xemoka 7y agoWhen 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 7y ago
- elitan 7y agoThis 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 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 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 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!
- code-is-code 7y agoIf 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-with-rxdb-hasura/ https://hasura.io/blog/building-an-offline-first-web-app-wit...
- elitan 7y agoWhat 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 https://github.com/nhost/nhost-js-sdk).
- lucasverra 7y ago
- treyhuffine 7y agoVery excited to see this. Hasura has transformed how I build apps.
- k__ 7y agoA small comparison: https://www.moesif.com/blog/graphql/technical/Ways-To-Add-GraphQL-To-Your-Postgres-Database-Comparing-Hasura-Prisma-and-Others/ https://www.moesif.com/blog/graphql/technical/Ways-To-Add-Gr...
- gsvclass 7y agoNot 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 https://github.com/dosco/super-graph
- buhrmi 7y agoIf GraphQL needs $9.9M to be simple enough for developers to actually use it, why was it invented?
- crubier 7y agoPostGraphile is free, try it!
- imvetri 7y agoGreat question
- nirvdrum 7y agoGraphQL 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 7y ago>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.
- skinnyarms 7y agoI'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.
- yen223 7y agoIt'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.
- z3t4 7y agoMyt pet peeve with GraphQL is, why not just use JS objects, and use JSON for serialization!? query = {user: {id, name}}
- tango12 7y agoThere 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-queries-like-a-boss/ https://hasura.io/blog/fluent-graphql-clients-how-to-write-q...
- crubier 7y agoAfter 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 7y agoI agree. PostGraphile needs to market itself though. They need a Dev Rel to make more people aware of it.
- rattray 7y agoThey're a husband/wife team, purely OSS, with little funds; you can donate here: https://www.patreon.com/benjie https://www.patreon.com/benjie
- pier25 7y agoCan you elaborate?
- crubier 7y agoThere 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 7y agoI 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
- awb 7y agoSome major players in the "GraphQL in a box" space: https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/ https://hasura.io/ https://hasura.io/ https://www.prisma.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/PostgREST/postgrest https://github.com/prest/prest https://github.com/prest/prest https://resthapi.com/ https://resthapi.com/
- markhalonen 7y agoI 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 7y agoFWIW, 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 7y agoInteresting; can you provide an example? Sounds like a nice way to compare various approaches to GQL queries, and general best-practices...
- jannotti 7y agoYes, 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.
- marton78 7y agoWow 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.
- aloukissas 7y agoI want to bet there were zero Greek VCs in the round :D (in Greek, "hasura" means huge loss, especially in investing context)
- bdcravens 7y agoOdd. Google Translate says it's "encountered" https://translate.google.com/#view=home&op=translate&sl=el&tl=en&text=hasura https://translate.google.com/#view=home&op=translate&sl=el&t...
- aloukissas 7y agoYou're looking something more like https://translate.google.com/#view=home&op=translate&sl=auto&tl=en&text=%CF%87%CE%B1%CF%83%CE%BF%CF%8D%CF%81%CE%B1 https://translate.google.com/#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.
- afvictory 7y agoCongrats 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/ https://aws.amazon.com/appsync/
- adminu 7y agoWe 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 7y agoWhat 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.
- benfle 7y agoIs 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 7y agoYou 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 7y ago> 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 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 7y agoCan someone explain to me how this differs from Apollo? Is it that it has a tighter integration with the DB layer?
- caniszczyk 7y agoAwesome 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/ https://landscape.graphql.org/
- miles-po 7y agoNot clear how to add or notify anyone to add. Missing Prisma (https://www.prisma.io/ https://www.prisma.io/) and Postgraphile (https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/) in the Databases section.
- armatav 7y agoFirebase, 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 7y agoThat's super fast!
- shivekkhurana 7y agoI 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.
- markhalonen 7y agoWhat made you choose Hasura over Postgraphile? RBAC is a postgres feature, not sure if that would affect the decision?
- aidos 7y agoNot 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).
- shivekkhurana 7y agoWith Hasura, you can create arbitrary roles (like admin, manager, etc) and restrict access to data on the basis of these roles. These roles can be assigned to a frontend session by generating signed JWTs. With Postgres RBAC, you'd need something to lift the roles to be consumed by the frontend. With Hasura it works out of the box. Also, I did consider using Postgraphile, but it was easier to get started with Hasura, so I went ahead with it. I don't have enough info to make a comparison.
- tirumaraiselvan 7y agoYou 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 https://github.com/hasura/graphql-engine/pull/3553
- headgasket 7y agoI'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.
- michelpp 7y agoA 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.
- sfilipov 7y ago> 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.
- djstein 7y ago+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.
- sadturnip 7y agoI 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 7y agoHasura'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/ https://blog.hasura.io/introducing-actions/
- sadturnip 7y agoUnfortunately 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.
- MadWombat 7y agoOne 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 7y agoI 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 7y agoData-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 7y ago
- mongol 7y agoDoes something like this exist for SQLite?
- hn_throwaway_99 7y agoI looked at Hasura a while back, and to be honest I thought it was the antithesis of all the things I loved about GraphQL so I moved on. Perhaps someone can convince me differently? The thing I love most about GraphQL is that serves as the perfect contract layer between the front end and the backend. A very productive development method I've used is to have the front end and back end teams agree on the GraphQL types (often times having the front end folks actually write the types), quickly mock things out, then have the front end folks go implement the front end and the back end folks provide the real resolver implementations. The things I love about this is that it really simplifies and hides the backend details from the front ends. With things like Hasura, you are directly exposing your DB schemas to the front end, essentially tightly coupling them together. That has always been a recipe for disaster whenever a project gets sufficient scale or complexity in my opinion. Again, it was a long time ago when I dug into Hasura, but this whole concept of "Directly expose my DB schema as GraphQL" is the exact opposite of what I love about GraphQL in the first place.
- brillout 7y agoDo you really need to decouple frontend and backend in the first place? Why not separating concerns instead of separating technologies? Tight coupling of UI with database but decoupling of e.g. admin UI/backend from end-user UI/backend. I'm the author of a Node.js RPC implementation (https://github.com/reframejs/wildcard-api https://github.com/reframejs/wildcard-api) and the idea is the exact opposite of what you are prescribing: highly coupled frontend business logic with database schema/queries. Makes things so much simpler, in my experience.
- rayraegah 7y agoTooling around Hasura is starting to mature. People have already mentioned nhost, I’d also like to point out a terraform module [0] to put Hasura on AWS [0]: https://registry.terraform.io/modules/Rayraegah/hasura/aws https://registry.terraform.io/modules/Rayraegah/hasura/aws
- brillout 7y agoInstead of Hasura and GraphQL, you can use RPC and directly write SQL queries to retrieve and mutate data. One way to think about this is that with RPC you remove the whole API layer and directly write SQL queries instead, while permissions are defined programmatically on a case-by-case basis. This is much simpler than Hasura! For Node.js there is https://github.com/reframejs/wildcard-api https://github.com/reframejs/wildcard-api. For other backends you can implement JSON endpoints (https://github.com/reframejs/wildcard-api/blob/master/docs/blog/rest-rpc.md#json-endpoints https://github.com/reframejs/wildcard-api/blob/master/docs/b...) While scaling to a large company, you progressively migrate from RPC to GraphQL (with or without Hasura).
- miles-po 7y agoI appreciate your zeal in marketing this product, but you're comparing apples and oranges. You are speaking of the ease of how you can write SQL queries. With Hasura, Postgraphile, Prisma, and their generated REST counterparts, 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. But I took a look at your RPC tool, and it adds a lot of boilerplate work. This RPC boilerplate is exactly why alternatives like Hasura, Prisma, and Postgraphile exist. Also you can't add an RPC layer and magically call it simpler. If you add Postgraphile, Prisma, Hasura in front of the database, it is just as simple, just as much a layer on top of the database. Only in this case you're writing to a published open spec (GraphQL) so 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. Your tool on the other hand is just another vendor-specific ORM or manual query engine. If that works for you, great. It is not a good alternative or answer to what is being discussed here.
- brillout 7y ago> you're comparing apples and oranges 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.)