postgres-websockets
graphile-engine
postgres-websockets | graphile-engine | |
---|---|---|
1 | 6 | |
338 | 752 | |
- | 0.0% | |
7.2 | 5.8 | |
6 months ago | 7 days ago | |
Haskell | JavaScript | |
BSD 3-clause "New" or "Revised" License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
postgres-websockets
-
PostgREST – Serve a RESTful API from Any Postgres Database
At work, we've finally replaced a large part of a custom (mostly-)web backend with PostgREST recently, and that's quite a relief: considerably less code to maintain in that project now, and that was a rather awkward code. Something akin to PostgREST's "Embedding with Top-level Filtering" [1] had to be provided for all the tables, with OpenAPI schema and a typed API (Haskell + Servant); I avoided manually writing it all down, but at the cost of poking framework internals, and maintainability suffered. It was particularly annoying that the code doesn't really do anything useful, except for standing between a database and an HTTP client, and simply mimics the database anyway. Whenever a change had to be introduced, it was introduced into the database, the backend, and the frontend simultaneously, so it wasn't even useful for some kind of compatibility.
Now PostgREST handles all that, and only a few less trivial endpoints are handled by a custom backend (including streaming, which I'm considering replacing with postgrest-websocket [2] at some point).
During the switch to PostgREST, the encountered minor issues were those with inherited tables (had to set a bunch of computed/virtual columns [3] in order to "embed" those), and with a bug on filtering using such relations (turned out it was an already-fixed regression [4], so an update helped). Also a couple of helper stored procedures (to use via /rpc/) for updates in multiple tables at once (many-to-many relationships, to edit entities along with their relationships, using fewer requests) were added (though the old custom backend didn't have that), the security policies were set from the beginning, the frontend was rewritten (which allowed to finally switch without adding more work), so it was only left to cleanup the backend.
Not using views, since as mentioned above, database changes usually correspond to frontend changes, and the API doesn't have to be that stable yet.
Happy with it so far.
[1] https://postgrest.org/en/stable/api.html#embedding-with-top-...
[2] https://github.com/diogob/postgres-websockets
[3] https://postgrest.org/en/stable/api.html#computed-virtual-co...
[4] https://github.com/PostgREST/postgrest/issues/2530
graphile-engine
- Sketch of a Post-ORM
-
Business Logic Inside Database - How Evil Is It?
But it doesn’t have to work this way. Some modern databases support a feature called "row-level security". It allows you to define access control policies at the row level based on the current user’s attributes (id, role, group membership, etc.). As long as the application can securely pass the current user’s identity to the database, it can leave all authorization checking to the database. And since the rules are defined at the table level instead of the API level, it has a much smaller surface to protect. The "row-level security" feature is the foundation of products like PostgREST, PostGraphile, and Supabase.
- PostgREST – Serve a RESTful API from Any Postgres Database
-
You may not need an SQL query builder or ORM
I really love the way pg-sql2 is going about that.
-
Ask HN: Solo Dev Stack of 2022?
I've been enjoying developing on top of PostGraphile. https://www.graphile.org/
Good starter: https://github.com/graphile/starter
I can add a column the the db, and my frontend gets that autimagically (in dev mode, it generates a graphql schema out of the db, and from that it creates composables for my frontend wiht graphql-codegen). On the frontend I use Vue 3, the starter is build with nextjs/react.
-
Best resource to learn PL/pgSQL?
I don't much direct knowledge on the internals, but here's a snippet from the graphile-engine repo README:
What are some alternatives?
postgrest - REST API for any Postgres database
starter - Opinionated SaaS quick-start with pre-built user account and organization system for full-stack application development in React, Node.js, GraphQL and PostgreSQL. Powered by PostGraphile, TypeScript, Apollo Client, Graphile Worker, Graphile Migrate, GraphQL Code Generator, Ant Design and Next.js
graphql-api - Write type-safe GraphQL services in Haskell
pgsql-http - HTTP client for PostgreSQL, retrieve a web page from inside the database.
graphql - Haskell GraphQL implementation
annuaire-entreprises-sirene-api
gc-monitoring-wai - a wai application to show `GHC.Stats.GCStats`
postgrest-starter-kit - Starter Kit and tooling for authoring REST API backends with PostgREST
raml - RESTful API Modeling Language (RAML) library for Haskell
sqlc - Generate type-safe code from SQL
simpleconfig
datasette - An open source multi-tool for exploring and publishing data