Hasura by far, lets you point-and-click build your database and table relationships with a web dashboard and autogenerates a full GraphQL CRUD API with permissions you can configure and JWT/webhook auth baked-in.
I've been able to build in a weekend no-code what would've taken my team weeks or months to build by hand, even with something as productive as Rails. It automates the boring stuff and you just have to write single endpoints for custom business logic, like "send a welcome email on sign-up" or "process a payment".
It has a database viewer, but it's not the core of the product, so I use Forest Admin to autogenerate an Admin Dashboard that non-technical team members can use:
For interacting with Hasura from a client, you can autogenerate fully-typed & documented query components in your framework of choice using GraphQL Code Generator:
Then I usually throw Metabase in there as a self-hosted Business Intelligence platform for non-technical people to use as well, and PostHog for analytics:
This is similar to what we're doing! Hasura + AutoCRUD framework + Metabase is a great stack for putting together a solid business application in no time.
Combine Hasura (automatic GraphQL on top of PostgreSQL) with React Admin (low code CRUD apps similar to Forest) and you can build an entire back office admin suite or form app (API endpoints and admin front end) in a matter of hours.
I've taken your stack one step further, with a completely dockerised solution that uses Firebase as an authentication solution (authentication is missing from the current low-code example). It can be run locally or on a cloud provider that runs containers (e.g. GCP Compute Create-With-Container). See here: https://github.com/dvasdekis/react-admin-hasura-firebase/
This is awesome. I haven't had time to expand react-admin-low-code, so glad to see someone take the general idea and run with it. I'll update the Readme to mention your repo when I have a chance.
What we're doing in our production version of this is using Postgres and Hasura for auth following this approach in order to reduce external dependencies: https://github.com/sander-io/hasura-jwt-auth
It's really amazing how far you can get with just Postgres. Writing business logic with code in application middleware always felt hacky to me when we have these powerful and performant relation databases.
Totally agree! Although I'm one of the contributors to that repo as well, the sheer number of possible attack vectors on the JWT scheme means that I was reluctant to use it in a publicly-facing use case. Let me know how it goes!
Hey man, really cool to see you comment here! We've chatted in the Hasura Discord briefly, love your work with the React Admin adapter. RA requires more manual work to set up and the aesthetics are different (Material UI), but it also gives you more flexibility.
For anyone looking for a self-hosted solution that can be more easily whitelabeled, highly recommend cpursley's work.
I have this feeling that hasura is still "onboarding". I had this experience with Netlify that offered some amazing deals and waited for everyone to onboard then started hammering them hard. I got up to $150/mo really fast for a static site that receives only about 900req/day. Every single month they were limiting more features and shifting them on to some "premium" offering that was used to lock you in. I'm still waiting on Hasura to do the same. Forest admin is no different. I'm always tempted to try them out for new projects but I always find myself back to Django, it will be here 10 years down the road.
This and Hasura are excellent. What's on the more sophisticated end of the scale? Is there anything that will generate user/company role systems and bake those into the generated API? Generate client side SDK's from the API?
FWIW I just reproduced an API that took me 3 days to build (while learning Django rest framework) in about 5 minutes.
My time would have been much better spend modeling the domain. As a happy benefit apibakery taught me a bit about DRF permissions I didn't know.
It feels like we're finally getting back to the 90's level RAD tools like NeXT enterprise object framework, and Delphi.
I can't agree more about Hasura, I made the jump to GraphQL for my current application and it's been a dream. Their documentation is excellent, helping me get setup with auth0 jwt auth and apollo client despite being new to both.
Metabase was a game changer in my last company, it was so nice to just be able to drop a 50+ line custom SQL query in there with parameters and let users pull what they want. We'd also setup queries to be loaded via Google Sheets cron jobs. That enabled live dashboards most any spreadsheet user could create (pivot, lookups, transforms, etc.).
Tanmai, their CEO, gave a response in the Discord on this question a few weeks ago:
"The pricing depends on your team/org: what features you’re using Hasura and the uptime/response SLA that you need. If you have something running with Hasura already feel free to setup a chat with the team to get a sense of the pricing. However we will have something launching for self-serve style pricing soon for a managed HA / auto-scalable Hasura with Pro features."
I believe it's priced on a per-feature basis, so they're likely to work with you depending on what your particular needs are.
You can’t create a Discord account without doxxing yourself. Signups not from an IP that discloses your location demand a dozen captchas and a telephone number. Using a burner number is not supported, and your carrier number is reversible to name/address/location just as your IP is.
The main issue with this viewpoint and your (arguably sensationalist) article is that it just finger points & blatantly ignores the reason those protections are in place.
The number of people that consider Discord part of their threat model or an actual privacy risk is incredibly tiny compared to the number of users that get inconvenience by mass bot raids & people bypassing IP bans.
I help manage a medium-sized Discord guild and we were randomly targeted by a bot raid whereby ~100 bots joined in the span of 1 minute and proceeding to spam various channels and the DMs of our users. Enabling Discord's requirement for a verified phone number stopped the raid in its tracks and allowed us to clean up without further issue.
In the same way, Discord's automatic content scanning is designed to protect the large percentage of minors on the platform & proactively deal with potentially exploitative material + guilds (per https://blog.discordapp.com/discord-transparency-report-apri...)
Removing these features & restrictions in order to appease your extreme edge-case privacy views does not help the average Discord user in the slightest.
You're absolutely right when you offer that the majority of people are not directly harmed by practices that are discriminatory. Discrimination is almost always aimed at circumstances that affect a minority of people.
It seems that you believe that you benefit from Discord's gatekeeping. I'm glad it seems to be working out for you. If it wasn't, however, how would you know?
Sorry, but no, you don't get to play a discrimination card here, because if we do, we're almost mocking people who are under real discrimination.
You don't agree with Discord's practices and lack of privacy, something which, by the way, I agree with you, and as such, decide not to use it. They are not discriminating against you, you're the one deciding not to use their service. To me, it sounds the same as if you don't like McDonalds because it's unhealthy, then accuse them of discriminating against you because they won't serve you some lean chicken salad.
The people doing the discrimination are the groups that choose Discord as their communications tool.
They are excluding all users who can’t get Discord accounts, such as those who can’t agree to the Discord TOS, for example. Free software projects and other public benefit groups should not be discriminatory.
They’re also banning political cartoons within their group’s
communications, by implicit inclusion of the Discord TOS which bans several common, normal, reasonable types of communication.
I’m a paying member of a local nonprofit organization; they use Discord exclusively to communicate. I am excluded from all of the discussions as a result of my not being able to safely get a Discord account. That’s discrimination whether you like to acknowledge it or not.
But that's the thing: You CAN agree to the TOS, you just choose to not, unless I'm severely misunderstanding your situation and you're in real, physical danger if you create a Discord account. For the sake of a better argument, can you clarify if you're in danger, or physically unable to create an account, or if it's a privacy choice, please?
Let’s set aside my personal circumstances: why must someone be in imminent physical danger for it to not be discrimination? Everyone has a human right to privacy, regardless of whether or not they are a famous person with a stalker who wants to track them down.
The presence or absence of threats against one’s person does not legitimize or delegitimize their insistence upon personal privacy.
I agree that it doesn't delegitimize your insistence upon personal privacy, and in fact, I'm in your camp with that, privacy is vital. My issue with the term is that, when you think in historical terms about discrimination, it's people being forced out of places/positions/society because of who they are.
The difference, in this case is that you're not being forced out of participating in conversations because you're, let's say, black. Instead, you, on your own, are opting out of communication channels because of your own beliefs.
There are API services that let you identify the type of number provided by the user. VoIP lines don't identify the same way as landlines which don't identify the same way as actual SIM-backed mobiles. They blacklist lots of providers and number types.
My first account I was able to get was via a number I rented on dtmf.io. The account was suspended (across all "servers" in Discord) in a few minutes when I linked a few of my IRL friends in a Discord chat to that Discord article on my own website. I've not been able to sign up again since, despite having blown something like 40EUR on numbers from different countries/providers trying to get a new one.
Even when it works, it's at least 10 minutes of solving CAPTCHAs to log in, each and every time, and sometimes the Google CAPTCHA hits some other exit node rate limit and just tells you to fuck off entirely, making login impossible even with a working account.
We've [1] been fans of Hasura for some time -- it's a terrific piece of work.
When we were looking to extend our spreadsheet functions that read/write to/from databases, we considered integrating Hasura as a backend.
Commendable work by the Hasura team, I think really worth checking out what they've done.
-
[1] Caveat: founder of MintData (https://mintdata.com) here, where we read/write from databases both directly via our flow editor and via spreadsheet functions which wrap things like Hasura.
Are you guys Postgres-centric, out of curiosity? Really interesting product, sort of in the same ballpark of Spinoff and other Sheets-based low-code SaaS but an approach more unique than I've seen before.
I'm a big user of graphile - they've also got a pretty good starter boilerplate with auth, etc baked in: https://github.com/graphile/starter
Have you tried it / do you have comparison points? I only poked around in Hasura a bit before deciding it wasn't worth the switching cost atm, but the out of the box upserts are compelling to me.
Graphile (https://www.graphile.org/) seems to be very similar, although I discovered it just a week ago (also on HN), and haven't had a chance to explore it yet.
Whatever you like. Depending on the nature of your work, you may be a startup or working for an organization that has mockups and design assets for what your frontend needs to look like.
In that case, you'd just build the front-end as usual, but use Hasura to bang out your whole backend and then autogenerate the type-safe query components with graphql-code-generator.
When I do products myself, I typically pick a pre-made template/UI kit (Vue is my preference) and then just modify it from there to suit my needs.
TailwindUI also looks really nice and I've seen several people build beautiful looking UI's with it for smaller SaaS products in a few days (though given that they're familiar with TailwindCSS and have a knack for this type of thing already):
Hasura also has a lot of community examples for different front-ends. Ranging from web apps in React/Vue/Angular/Elm to mobile clients in Flutter or Android/iOS:
So hasura just exposes a Postgres database through GraphQL?
That sounds kinda nifty, but does it then allow you to write custom code to add business logic? Glancing through the documentation, that part wasn't clear to me.
That's one of the most common misconceptions about Hasura.
While it CAN expose an existing Postgres database, where it really shines (in my opinion) is when you're starting a brand new product. Because you can create your whole database and all the relationships, foreign-keys, triggers, permissions, etc through the web console UI incredibly rapidly.
And yeah, it takes care of all CRUD and provides an aggregation/statistics API (sum, median, standard deviation, count, mean, variance, etc), and it leaves the pieces of custom business logic up to you to write. It's entirely agnostic to what you use to write these, so long as they expose an HTTP endpoint.
I really want to like Hasura, but very quickly you'll run into limitations of its permission system. Especially when dealing with logic across relationships.
If only Hasura supported some king of Prolog / Datalog instead of their ad-hoc JSON language, then you'd be able to write nearly any possible use cases. Until then, I'll stick to building and maintaining my own backends... manually :(
One of the biggest pain points I found was modeling Organization/Team/Multi-Tenant based permissions.
Generally, the advice is to use a session variable like X-Hasura-Organization-Id to filter in permissions, but recently through a Discord conversation a means to do this without a session variable was found out and I took some time to publish it as a Gist:
Right, those are the kind of permissions I had trouble with. That gist works for reads based on membership (even if a little unintuitive), but I couldn't figure out how do writes that validate using roles & permissions.
If you’re looking for more flexibility than Hasura, I’d recommend you try out Warthog (disclaimer: I’m the author). It’s a Node Library that uses TypeORM, TypeGraphQL and some extra magic under the hood to let you spin up APIs very quickly (auto-generated schema), but you also have access to the bare metal code. You can set up CRUD essentially free, but it provides you a slew of ways to handle more complex scenarios.
Sorry, I'm a bit new to GraphQL. Can you explain why this is more existing than starting a brand new product using plain PostgreSQL?
Can you also explain how locked in you are, if you decide you want to migrate away from Hasura, or in general want more flexibility that the use-case of Hasura + ForestryAdmin?
With plain PostgreSQL you have to write your own backend logic to access the database. The whole point of Hasura is exposing your DB via a GraphQL API with some bells and whistles (like authorization).
About lock-in... it's open source software, so you're as locked in as you'd be with, say, Rails or Django. It doesn't do anything special to PostgreSQL so you can always rewrite the API later from scratch, or build something else on top of its GraphQL API.
With some frameworks (i.e. ASP.NET core) you already have authentication and authorization middleware if you need them and you can use an ORM to map data objects to tables and query the DB with ease.
What benefits would be using the DB over a GraphQL API?
Well, not having to implement and maintain anything is a huge plus, especially when you have a large number of tables :)
Also, Hasura has some bells and whistles that would be a bit of a PITA to implement using traditional MVC frameworks, like per-column authorization, and, of course, the GraphQL to SQL translator.
> What benefits would be using the DB over a GraphQL API?
And I'd say that the biggest advantage of GraphQL is allowing customized payloads.
Say you need a list of users ids + emails in one page, and a list with ids + names + emails in other. In REST you either need to waste some bytes, have two endpoints, or use some conditional to show/hide the field.
With GraphQL you just have to ask for the fields you want.
The same applies to joins: you either add extra endpoints, extra logic, or the user has to make multiple requests. With GraphQL you can have custom joins.
Btw, if you still don't think that GraphQL is an advantage to you, I recommend checking its cousin-project PostgREST :)
> does it then allow you to write custom code to add business logic
Yes! Like gavinray said, you can create HTTP services in any language of your choice. Hasura can then be configured to call HTTP endpoints when something changes in the DB. And your services can call Hasura anytime of course.
Remember that Hasura handles all the authorization for you, so there's no need to "proxy" requests made to it.
You end up writing very little compared to traditional frameworks.
What are you using for your authentication adapter? I've been looking at picking up hasura but don't like the idea of using something like Auth0. So I've been hunting on the best tool for auth.
Firebase does provide unlimited password logins for free, which mitigated my personal concerns about Auth0. The advantages of a SaaS auth provider compared to a roll-your-own have been documented elsewhere, and I personally found them compelling.
What are the reasons you 'don't like' something like Auth0?
I really need a self hosted solution. Ideally it would have an LDAP adapter so it could get login info from our internal active directory. If I were building public facing apps Auth0 would be perfect.
I don't think I'd be allowed to entrust users passwords to an external entity, despite the fact that they would probably do a much better job than I would at securing them. Also despite the fact that we trust every other external provider to store passwords...
Fully understand - I would want something self-hosted in this case as well.
Firebase does allow you to integrate with other OAuth providers (e.g. Google/Facebook/Linkedin etc.), so you could perform some kind of validation on the google account, ensuring it comes from your company's mail domain? Just a thought.
Set up of these security schemes is not easy (took me a shamefully long time to get Firebase working with React-Admin and Hasura). I'd personally try and get a SaaS provider to work within your company's constraints before trying to roll your own.
The sign-up Action bcrypt hashes the password and saves it by sending a mutation to Hasura, and the login Action queries for the user by their email and tries to bcrypt compare their password against the stored one and then return a spec-compliant token if they match.
It's fairly simple to implement your own Auth in Hasura, you just need to return a signed JWT that matches the spec:
Would be interested to know if you can do all this by using their open-source conmmunity edition, or would you need to use their paid / Pro version. Since the pricing for the paid version is not given, not sure but assuming it would be fairly expensive to use / deploy? My preference is for an open source tool so we are not locked in to a propreitary platform for the long term.
Forest Admin looks really nice, but I wish you could host the admin UI yourself. Not a fantastic impression for clients if Forest (for whatever reason) suddenly stops offering it's service and your admin panel vanishes into thin air :(
For Dev and Staging, I use a Postgres Docker container, in Production I use a managed Postgres service.
I have a starter kit that includes a ton of stuff including pre-made JWT auth configured as Hasura Actions, a standard monolith-style Node REST API skeleton, and OpenFaaS serverless handler examples in every major language (Node, Python, Ruby, Java, Go, C#, PHP) you can find here:
Appreciate the kind words! I just wanted to share these tools because I feel they're undervalued and underused, and I reach for them for every new project I start.
Thanks for the reply. Also, when I run in an microservice architecture, how does hasura handles say for example websocket across the services? Do we need to depend on any other library?
Can you share some samples for these things if available. I will be glad to look at it.
1. During the lifetime of a websocket connection, bytes should be routed to the same Hasura instance. This most service routers / load balancers should take care of automatically.
2. Subsequent connections from different clients to Hasura need not go to the same instance! This makes horizontal scaling painless.
https://hasura.io/
I've been able to build in a weekend no-code what would've taken my team weeks or months to build by hand, even with something as productive as Rails. It automates the boring stuff and you just have to write single endpoints for custom business logic, like "send a welcome email on sign-up" or "process a payment".
It has a database viewer, but it's not the core of the product, so I use Forest Admin to autogenerate an Admin Dashboard that non-technical team members can use:
https://www.forestadmin.com/
With these two, you can point-and-click make 80% of a SaaS product in almost no time.
I wrote a tutorial on how to integrate Hasura + Forest Admin, for anyone interested:
http://hasura-forest-admin.surge.sh
For interacting with Hasura from a client, you can autogenerate fully-typed & documented query components in your framework of choice using GraphQL Code Generator:
https://graphql-code-generator.com/
Then I usually throw Metabase in there as a self-hosted Business Intelligence platform for non-technical people to use as well, and PostHog for analytics:
https://www.metabase.com/
https://posthog.com/
All of these all Docker Containers, so you can have them running locally or deployed in minutes.
This stack is absurdly powerful and productive.