Hacker News Reader

Comment by sz4kerto | Hacker News Reader

You should be aware that this is a _bad_ pattern for anything more serious than a university homework. Instead of exposing functionality that you can guarantee and that's required by the clients, you expose your database schema, essentially tightly coupling the DB with the clients.

I know it's tempting to do that, but spend some time thinking of your data and what do you want to expose.

View on HN

Aren't a lot of endpoints essentially bound to the database anyway? If you were to do any sort of major schema change, chances are you would have to create a new endpoint (i.e. /api/v2/) to handle the new schema changes. Also this handles versioning.

That's why the "official" way to deploy postgrest is to run it on views in different schema than your data is.

I share this sentiment, but this is mostly a question of organization, and not so much about whether the code is inside or outside the DB.

I personally used some prefix for that, such as "service_" or "public_". All stored procedures (in PostgreSQL speak: "user-defined functions") that have this prefix are accessed from the client. Everything else is internal. Of course, it would be even nicer if the REST framework would enforce that convention.

This is especially nice with JSON aggregation and SUB SELECTs, where you can directly aggregate your objects and lists of sub objects within the DB query, and generate the whole JSON result directly in the DB.

Reply on news.ycombinator.com