Hacker News new | ask | show | jobs
by whstl 417 days 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.

1 comments

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.

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.

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?

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.

I wouldn't write a back end with an MVC framework, since it's not doing any presentation whatsoever.

If PostgREST auto-generates three-table joins automatically to resolve many-to-many relationships and presents an appropriate endpoint, that's interesting.

Yes, it does many-to-many joins automatically: https://docs.postgrest.org/en/v12/references/api/resource_em....