undefined | Better HN

0 pointsTSiege11mo ago0 comments

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

0 comments

DidYaWipe11mo ago

"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-chavez11mo ago

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

DidYaWipe11mo ago

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

1 more reply

whstl11mo ago

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.

DidYaWipe11mo ago

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.

1 more reply

nawgz11mo ago

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

whstl11mo ago

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.

LinXitoW11mo ago

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.

whstl11mo ago

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.

j / k navigate · click thread line to collapse