[TSiege]

Experienced backend dev here who also uses Hasura for work at a successful small business. I think it's great at getting a prototype to production and solves real business problems that a solo dev could do by himself. As engineer #2 it's a mess, and it doesn't seem like a viable long term strategy.

I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns. Your entire schema is exposed. Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly. You're pushed into fake open source where you can't always run the software independently. Who knows what will happen when the VC backers demand returns or the company deems the version you're on as not worth it to maintain compared to their radically different but more lucrative next version.

I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing

[DidYaWipe]

"Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper."

Exactly. This is one of the things I never understood about Supabase's messaging: The highly-touted, auto-generated "RESTful API" to your database seems pointless. Why would I hard-code query logic into my client application? If my DB structure changes, I have to force new app versions on every platform because I didn't insulate back-end changes with an API.

Why would anyone do this?

[steve-chavez]

> If my DB structure changes, I have to force new app versions on every platform because I didn't insulate back-end changes with an API.

To avoid the above problem, it's a standard practice in PostgREST to only expose a schema consisting of views and functions. That allows you to shield the applications from table changes and achieve "logical data independence".

For more details, see https://docs.postgrest.org/en/v12/explanations/schema_isolat....

[DidYaWipe]

Thanks. If you're writing functions, though, it seems like nearly as much work as writing traditional endpoints, no?

[steve-chavez]

Not really, the work is much reduced.

1. If your function returns a table type, you can reuse all the filters that PostgREST offers on regular tables or views [1].

2. The SQL code will be much more concise (and performant, which leads to less maintenance work) than the code of a backend programming language.

3. The need for migrations is a common complaint, but you can treat SQL as regular code and version control it. Supabase recently released some tooling [2] that helps with this.

[1]: https://docs.postgrest.org/en/v12/references/api/functions.h...

[2]: https://supabase.com/docs/guides/local-development/declarati...

[whstl]

Nobody but you is forcing you to put the “business logic” in the frontend.

Both those techs might make this look convenient, but engineering rules must still be followed.

Frontend should do validation and might have some logic that’s duplicate for avoiding round-trips… but anything involving security, or that must be tamper-proof, must stay in the server, or if possible be protected by permissions.

There are whole classes of applications that can be hosted almost entirely by Supabase or Hasura. If yours isn’t, it doesn’t mean you should force it.

[DidYaWipe]

Who said anything about forcing? I asked what the value of Supabase's most highly-touted features are, when they CATER TO the movement of such things as query logic to the front end. What else are you doing with an auto-generated RESTful HTTP "API" to the database?

I also didn't mention security, let alone promote moving it to the front end.

[whstl]

You are the one mentioning “Why would I hard-code query logic into my client application?”

The answer is: you wouldn’t. That’s not the point of any of those tools.

[DidYaWipe]

Yep, I'm the one. And the question stands.

What is the point of an auto-generated HTTP API to the database, if not to let clients formulate queries? And why would you do that?

[whstl]

PostgREST creates the same type of CRUD endpoint that one would create when writing a traditional backend with an (eg) MVC framework, and it does this without requiring a developer and with complete consistency.

If "letting the client formulate queries" you mean "filter posts by DidYaWipe, sorting by date", this is also what traditional CRUD backends do.

[nawgz]

> As engineer #2 it's a mess

As a long-time Hasura stan, I can't agree with this in any way.

> Your entire schema is exposed

In what sense? All queries to the DB go thru Hasura's API, there is no direct DB access. Roles are incredibly easy to set up and limit access on. Auth is easy to configure.

If you're really upset about this direct access, you can just hide the GQL endpoint and put REST endpoints that execute GQL queries in front of Hasura.

> Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper

> Likewise you can't easily customize your API without building an API on top of your API. You're doing weird extra network hops

... How is an API that queries Hasura via GQL any different than an API that queries PG via SQL? Put your business logic in an API. Separating direct data access from API endpoints is a long-since solved problem.

Colocating Hasura and PG or Hasura and your API makes these network hops trivial.

Since Hasura also manages roles and access control, these "extra hops" are big value adds.

> You're pushed into fake open source where you can't always run the software independently

... Are you implying they will scrub the internet of their docker images? I always self-host Hasura. Have for years.

> I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing

I think your arguments pretty much sum up why people think it's just about backend engineers feeling threatened - your sole point with any merit is that there's one extra network leg, but in a microservices world that's generally completely inconsequential.

[whstl]

I completely disagree.

Backends are far messier (especially when built over time by a team), more expensive and less flexible than a GraphQL or PostgREST's api.

> I've only worked with Hasura, but I can say it's an insecure nightmare that forces anti-patterns

Writing backend code without knowing what you're doing is also an insecure nightmare that forces anti-patterns. All good engineering practices still need to apply to Hasura.

Nothing says that "everything must go through it". Use it for the parts it fits well, use a normal backend for the non-CRUD parts. This makes securing tables easier for both Hasura and PostgREST.

> Business logic gets pushed into your front end because where else do you run it unless you make an API wrapper. You're doing weird extra network hops if you have other services that need the data but can't safely access it directly

I'm gonna disagree a bit with the sibling post here. If you think that going through Hasura for everything is not working: just don't.

This is 100% a self-imposed limitation. Hasura and PostgREST still allow you to have a separate backend that goes around it. There is nothing forbidding you from accessing the DB directly from another backend. This is not different from accessing the same database from two different classes. Keep the 100% CRUD part on Hasura/PostgREST, keep the fiddly bits in the backend.

The kind of dogma that says that everything must be built with those tools produces worse apps. You're describing it yourself.

> I think the people who write this off as "backend engineers feel threatened" aren't taking the time to understand the arguments they're hearing

I have heard the arguments and all I hear is people complaining about how hard it is to shove round pieces in square holes. These tools can be used correctly, but just like anything else they have a soft spot that you have to learn.

Once again: "use right tool for the job" doesn't mean you can only use a single tool in your project.

[LinXitoW]

I've only played with these kinds of plug and play databases, but mixing and matching seems like the worst of both worlds. The plug and play is gone, because some things might me in API 1, some others in API 2, and maybe worst of all, their domains might overlap. So you need to know that the "boring" changes happen via the postgREST, but the fancier ones via some custom API. The APIs will probably also drift apart in small ways, making everything even more error prone.

[whstl]

What you say is also true for situations where you us an ORM vs queries, or some direct MVC approach vs business service libraries which are common in backend apps. Or even having two different sets of APIs.

What sounds like the worst of both words to me is forcing Supabase/Hasuea to do what it isn’t good at or force a traditional backend to do the same thing those tools can do but taking 10x of the time and cost.

My experience was super positive and saved a lot of coding and testing time. The generated APIs are consistent and performant. When they don’t apply, I was still able to use a separate endpoint successfully.