[HN Gopher] PostgREST: Providing HTML Content Using Htmx
___________________________________________________________________
PostgREST: Providing HTML Content Using Htmx
Author : brodo
Score : 95 points
Date : 2023-12-18 20:47 UTC (2 hours ago)
(HTM) web link (postgrest.org)
(TXT) w3m dump (postgrest.org)
| WhatsName wrote:
| While cool as a proof of concept and kudos for execution, this
| looks like a nightmare to maintain for any non-trivial webapp.
| robertlagrant wrote:
| It's definitely for websites or light apps only. There's a lot
| of mileage in that, though.
| leptons wrote:
| The "light apps" that also require a database that don't have
| a more capable front-end framework seem to make HTMX look
| like a solution in search of a problem.
| brodo wrote:
| I'm experimenting with it right now using Squitch [1] to make
| maintenance easier. It still feels like a hack and I also still
| have my doubts about the viability of this for real-world use.
| It's fun though and I'm learning about all kinds of advanced
| Postgres features.
|
| [1] https://sqitch.org/
| rudasn wrote:
| Is this kind of functionality / coding pattern used in new or
| modern applications?
|
| Couchdb, a (json) document database, whose api is http-based, had
| built-in list and detail methods that allowed you to respond with
| any type of format you could generate within their javascript
| interpreter. In other words, no need for a server as the client
| can directly hit the database and get html and/or json back.
|
| After v1 they stopped working on that front as it makes for
| nightmare maintenance work.
|
| I think many here remember the good old days of php or asp files
| having sql statemts mixed with html all in a single file. This
| doesn't look very different.
| throwup238 wrote:
| Oh man, those really were the good old days"; DROP TABLE users;
| WM6v wrote:
| Related Show HN: Render HTML in SQL with pg_render
| https://news.ycombinator.com/item?id=38677852
| steve-chavez wrote:
| Really cool! I was working on something similar on
| https://github.com/PostgREST/plmustache.
| claytongulick wrote:
| I'm currently in the process of evaluating PostgREST via Supabase
| for replacing the CRUD aspects of our legacy PHP/Laravel code
| base.
|
| It's a compelling option, but there are already a lot of sharp
| edges.
|
| For example, PostgREST doesn't really highlight this, but for any
| non-trivial and sane application you have to create a separate
| schema ("api" or similar) to carefully pick what's exposed.
| PostgREST has a scary "allow by default" permission model which
| is nearly enough to turn me off of the whole project.
|
| To help mitigate this, I'm evaluating only using PostgREST for
| reads in the "api" schema via access-restricted views, and having
| all writes go through supabase edge functions. This should
| simplify the RLS permissions (hopefully).
|
| RLS has some pitfalls too, and it's the only mechanism you have
| to secure your data.
|
| Serving assets from Postgres seems like a bad idea aside from
| some simple edge use cases. In general, you want to treat your DB
| as a precious resource and minimize the amount of work it has to
| do.
|
| Nginx and similar are built and optimized for serving assets.
| Using your database to do this doesn't seem like a great idea if
| your application needs to scale.
| steve-chavez wrote:
| > PostgREST has a scary "allow by default" permission model
| which is nearly enough to turn me off of the whole project.
|
| PostgREST follows Postgres' "deny by default", you have to
| explicitly grant permissions for tables and views to be used.
| This is noted on the first tutorial[0].
|
| Supabase overrides this default via `ALTER DEFAULT PRIVILEGES
| .. GRANT`[1]. This is done for easier onboarding of new users
| but you can turn this off with `ALTER DEFAULT PRIVILEGES ..
| REVOKE`.
|
| PostgREST also encourages you to create a dedicated schema for
| your api[2].
|
| [0]:
| https://postgrest.org/en/stable/tutorials/tut0.html#step-4-c...
|
| [1]: See an example of this on
| https://supabase.com/docs/guides/api/using-custom-schemas.
|
| [2]:
| https://postgrest.org/en/stable/explanations/schema_isolatio...
| boomskats wrote:
| > Supabase overrides this default
|
| Ah, thank you for this clarification. I was wondering what
| that comment was referring to.
|
| (and keep up the great work <3)
| bsdpufferfish wrote:
| > you have to create a separate schema ("api" or similar) to
| carefully pick what's exposed.
|
| Yep, but it's a CREATE VIEW instead of writing a route in
| python or ruby which also will likely hit an ORM...
|
| > Serving assets from Postgres seems like a bad idea aside from
| some simple edge use cases. In general, you want to treat your
| DB as a precious resource and minimize the amount of work it
| has to do.
|
| The database should still be the source of truth (of generated
| assets). An easy solution is to configure NGINX to cache those
| asset requests, or write a script to unpack them to the file
| system.
| boomskats wrote:
| Just to address some of your points:
|
| > PostgREST doesn't really highlight this, but for any non-
| trivial and sane application you have to create a separate
| schema ("api" or similar) to carefully pick what's exposed.
|
| That recommendation is highlighted here:
| https://postgrest.org/en/stable/explanations/schema_isolatio...
|
| > PostgREST has a scary "allow by default" permission model
| which is nearly enough to turn me off of the whole project.
|
| I assume you're talking about access via the db-anon, without
| authenticating your users. I can't think of what else you could
| be referring to. If you rely on JWT-based authentication, as
| any non-trivial and sane application would do, you'd have
| access to transaction-scoped impersonated roles.
| https://postgrest.org/en/stable/references/auth.html#overvie...
|
| > having all writes go through supabase edge functions
|
| Why is this necessary, what are you unable to achieve with JWT
| + RLS/RBA? Again, I have to assume you don't have auth
| configured correctly.
|
| > RLS has some pitfalls too, and it's the only mechanism you
| have to secure your data.
|
| You also have role-based access, and the JWT auth to start
| with. However I have found RLS to be flexible enough,
| especially as you can define policies using subqueries into
| which you can embed UDFs. What are you trying to do that you
| can't do with it?
|
| > Serving assets from Postgres seems like a bad idea aside from
| some simple edge use cases.
|
| I instinctively agree in terms of devex, although I'm reluctant
| to just dismiss it. I think the performance hit with a database
| is the data retrieval, not the templating. I can see a
| possibility of this evolving into something very usable with
| some packaging of templates, especially once you realise the
| approach eliminates the need for more services, simplifies
| auth, and reduces rendering latency. The memory footprint of
| PostgREST is trivial compared to most middleware you'd have to
| add to the mix just to do some SSR.
| statusfailed wrote:
| I used postgrest (without htmx) on an old project; it's
| impressive how far you can push it. HTMX seems like a perfect fit
| for it too, although I'm not sure how much I really want to
| maintain htmx templates _inside_ SQL functions...
| kreetx wrote:
| What a neat web development stack, just html & database! No back-
| end and no front-end required.
| smegsicle wrote:
| crud without the cruft
| markbnj wrote:
| Years ago, mid-90's, I visited Compuserve in Ohio. The web was
| just getting going and one of the engineers I met there showed
| off a music store he was building by returning html from SQL
| stored procedures :).
| bsdpufferfish wrote:
| The quality of open source databases with views, partitions,
| etc as well as improvements in server hardware have made this
| approach much more appealing.
| turtlebits wrote:
| You still need to run PostgREST, so still 3 servers.
| (web/app/db)
___________________________________________________________________
(page generated 2023-12-18 23:00 UTC)