7 ms·

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

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 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 ago
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.
jo-m 7y ago
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 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 ago
  When 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
Django has had an automatic admin site since 2006 or earlier, this isn't a game changer for me.
- alharith 7y ago
  Yeah, pfft, Java EE has had this since the early 2000s too. What's old is new again, amirite??
- cpursley 7y ago
  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 7y ago
    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 7y ago
  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.
rhlsthrm 7y ago
Man, there's so many cool ways to build CRUD apps nowadays, I wish I just found a good opportunity to write one!
latch 7y ago
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 7y ago
  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.
- tango12 7y ago
  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
joshmarlow 7y ago
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 https://massiveinference.com
airstrike 7y ago
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 7y ago

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.

jo-m 7y ago

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 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 ago
When 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

Django has had an automatic admin site since 2006 or earlier, this isn't a game changer for me.

alharith 7y ago
Yeah, pfft, Java EE has had this since the early 2000s too. What's old is new again, amirite??
cpursley 7y ago
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 7y ago
  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 7y ago
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.

rhlsthrm 7y ago

Man, there's so many cool ways to build CRUD apps nowadays, I wish I just found a good opportunity to write one!

latch 7y ago

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 7y ago
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.
tango12 7y ago
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

joshmarlow 7y ago

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 https://massiveinference.com

airstrike 7y ago

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...