Hacker News Reader

Comment by dorianmariefr | Hacker News Reader

Using this is a code smell

Ha - I find unsubstantiated, parroted mantras like this to be a team lead smell :) In the same way that Agile development has become a mindless cult of rituals that has little to nothing left of the original manifesto's vision, code reviews peppered with thoughtless "code smell" comments have become the bane of development.

Indeed on a code review that kind of comment is bad. We have sonarcube for that kind of nonsense. The reviewer should explain why, and ideally show how it could be done better.

Maybe, an app I inherited used this as it’s interaction with the database. The main issue was that because it wasn’t really sophisticated enough to do the queries they wanted so they wrote a bunch of stored procedures (in JavaScript?!) and used it to call them. This fairly rapidly led to the database getting overloaded.

I guess it’s maybe a smell because you’re limiting the database capabilities down from SQL, which is very powerful, down to the postgrest set of abstractions. Maybe that’s okay for your app now and maybe it always will be. But in this case, it wasn’t.

what does PostgREST take away from you over SQL? Sure it has limitations in what it can API-ify, but couldn't you stick anything more exotic in a function or procedure?

Conversely, I find dismissing something like this out of hand to be an ego smell.

It's not something I'd grab quickly, but at the same time, it looks great for doing 'pure' CRUD applications. You'll probably need serious database administration skills though, I've yet to see anyone do anything with database account and permission systems that isn't straight root access from an application.

I investigated this and a few others for quickly spinning up a back office app, and settled on postgraphile. The endpoint that is exposed from the service is authenticated and a role is then set on the request object which postgraphile then uses to set the role for the database transaction. With appropriate roles set in the database, my back office users now have fine-grained permissions for reading/writing only to tables that I want them to.

It seems to me that it's the main limitation of this solution - authorization is limited to table scope so if you can update any row, you can update all rows for all users. Same for data querying.

If you completely trust your users, that's fine.

That's not true; you can use row level security (RLS) to control access (both reading and writing) on a per-row basis. You can think of it as similar to an implicit "where" clause that automatically gets added to all requests.

RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html

We built an entire system using RLS and functions. Postgraphile is frankly amazing. You can also extend the schema using Typescript or SQL.

why?

Not the author of the post, but I guess the author meant that using JavaScript to communicate directly with PostgreSQL database over PostgREST is "architectural code smell": in this case database can easily be hacked and everybody could write to/remove anything from such an unprotected database...

But Postgres has row level security, so the OP would be wrong in that case.

Who said anything about JavaScript? It's REST so you can hit it with any language, right?

Not if you setup permissions properly

Reply on news.ycombinator.com