Hacker News new | past | comments | ask | show | jobs | submit login

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




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


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.


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


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


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!


Curious, what do you think of RPC instead of GraphQL?

E.g. https://github.com/reframejs/wildcard-api for JavaScript.

The neat thing about RPC is that you can tap into the full power of PostgreSQL "directly" from the frontend.


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.


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.


Yeah, pfft, Java EE has had this since the early 2000s too. What's old is new again, amirite??


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


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.


When I have a chance I'll refactor this so that it uses a local docker Hasura and Postgres instance.


+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! :)


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) ?


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.


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.


Auth is about 15 lines in an SQL function exposed via the api w/postgraphile, plus whatever lines necessary to define your RLS policies and grants.


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


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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: