postgres-websockets
crystal
postgres-websockets | crystal | |
---|---|---|
1 | 28 | |
338 | 12,413 | |
- | 0.2% | |
7.2 | 9.9 | |
6 months ago | 6 days ago | |
Haskell | TypeScript | |
BSD 3-clause "New" or "Revised" License | GNU General Public License v3.0 or later |
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
crystal
-
Ask HN: What Underrated Open Source Project Deserves More Recognition?
I didn't see a v5 tag in order to know, and I have no idea what "utils/graphile" does for the project, but one will want to ensure they are aware of its licensing scheme https://github.com/graphile/crystal/blob/db8894c74eb0ec3fe96...
- v4.13.0
-
PostgREST – Serve a RESTful API from Any Postgres Database
I was about to say “but this one is!” and realized I had confused PostgREST with PostGraphile. If you’re interested in GraphQL, you can check out PostGraphile here: https://github.com/graphile/postgraphile
-
Best Orm that uses Graphql and Postgres
If you point is to abstract all the CRUD/GraphQL application, Go isn’t needed. You can go with PostgREST or Postgraphile.
- v4.12.12
-
Ask HN: Locally generate GraphQL schema and resolvers from DB
What do you mean locally? Hasura is OSS, and you can run it locally (you have autogenerated SQL statements) Here you can just use Nhost and its CLI;
Alternatives are https://github.com/graphile/postgraphile or dgraph as you mentioned. Hasura is working on support for sqlite, so you may have some blockers there, you can also look into the Prisma engine which has GQL as an intermediate (for resolvers, for example)
- v4.12.11
-
Supabase (YC S20) raises $80M Series B
I've personally found Postgraphile to be fantastic. Nicer to use than Hasura and fully OSS: https://github.com/graphile/postgraphile/
- v4.12.10
-
GraphQL is now available on Supabase
Hi all, this sounds very cool. How does pg_graphql compare to Postgraphile? https://github.com/graphile/postgraphile (besides I guess running in the DB with PLpgSQL instead of as a NodeJS server)
Did you think about integrating Postgraphile with the Supabase ecosystem or have specific limitations with it?
Thanks!
What are some alternatives?
postgrest - REST API for any Postgres database
Hasura - Blazing fast, instant realtime GraphQL APIs on your DB with fine grained access control, also trigger webhooks on database events.
graphql-api - Write type-safe GraphQL services in Haskell
pg_graphql - GraphQL support for PostgreSQL
graphql - Haskell GraphQL implementation
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
gc-monitoring-wai - a wai application to show `GHC.Stats.GCStats`
supabase - The open source Firebase alternative.
raml - RESTful API Modeling Language (RAML) library for Haskell
supabase-graphql-example - A HackerNews-like clone built with Supabase and pg_graphql
simpleconfig
tensei - 🚀 Content management and distribution with a touch of elegance.