Hacker News Reader

Comment by icebraining | Hacker News Reader

Isn't GraphQL intended to be used directly by the frontend app (with direct access by any potential malicious user), whereas Postgrest is more for a backend app, that can be trusted with more control?

View on HN

There's nothing in PostgREST that stops you from limiting control so that even anonymous users can use it safely. I've used PostgREST for user-facing APIs with success, but it requires some knowledge about the postgres access control model.

EDIT: And "Just point Postgrest at your PostreSQL database" is rarely a good idea in my experience, I usually have (versioned) API-schemas containing views, so that I can change my underlying data schema at will without borking the API.

Anonymous seems easier, since you can treat them as a single user. But could you do something like HN as a frontend app talking directly to a Postgrest API?

Good point, that's true. But yes you could, using row-level security. See https://www.postgresql.org/docs/current/static/ddl-rowsecuri... and https://postgrest.org/en/v4.4/auth.html#users-and-groups

I have a GraphQL field that converts tweet-like content from the database into token lists so that individual clients don't need to implement their own tweet-parsing logic. I have many other examples.

If it was really feasible to bind our databases directly to our APIs, we wouldn't need to hire anyone except DBAs and front-end developers. But backend business logic is a thing. You may not need it, but most people do.

The database is more than just tables, for your particular example you could use a computed column https://postgrest.org/en/v5.0/api.html#computed-columns.

In general, custom business logic can be done through stored procedures/views/computed columns.

"Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."

You can do a lot in the database, a lot more than most developers realise, that doesn't mean it's a good idea.

Reply on news.ycombinator.com