No post body was provided.
A Poor Man's API
111–120 of 127 posts
Re: A Poor Man's API
#112Maybe I am biased, but at this point I would find simpler to just give access to the DB. Let user write their own SQL queries and meter how much time they use for billing or abuse prevention.
At that point you might as well just let them download the .sqlite file ;)
Or (as is the fashion recently) compile sqlite to wasm and run it in browser.
Re: A Poor Man's API
#113Earlier quoted context omitted.
If you're talking about HATEOAS (which many zealots equate one to one with REST) you may be pleased to know there is no reference to it whatsoever in this article.
Perhaps I'm a zealot: HATEOAS is one required part of REST as per Roy Fielding, who came up with both. What does "REST" mean to you?
"When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean — neither more nor less."
To me, like most people, REST means an http-based API where we use GET, POST, PUT, DELETE etc. to interact with resources. This in full understanding that under a literal interpretation of the enlightened one's (Roy Fielding's) utterances, REST mandates HATEOAS, meaning that there are only a few true REST APIs to be seen in the wild.
I also usually use the term RESTful, this seems to be a somewhat widely accepted middleground.
Re: A Poor Man's API
#114Earlier quoted context omitted.
Neon is fresh out of private beta (or should be soon). I can't wait to play with it. However they're all about Hasura lately rather than PostgREST, which this article talks about. Nikita, their CEO, was a guest on the Changelog[0] podcast a month or so ago. Well worth a listen, great episode. [0] https://changelog.com/podcast/510
Supabase requires Postgres logical replication which Neon doesn't quite have yet have (but it's on the roadmap) https://community.neon.tech/t/plans-for-logical-replication/... I'm also really excited about Neon. My dream stack is Neon (Postgres) + ReadySet (database caching proxy) + Supabase.
Interesting. I assume Supabase requires it because supabase/realtime depends on it?
Personally I'm more interested in vanilla PostgREST than Supabase's implementation of it, or their realtime implementation. It seems really cool but I'm not 100% sold on their ability to evaluate complex RLS rules, which is an important one for me.
ReadySet looks cool, I'll check it out. Thanks!
Re: A Poor Man's API
#115Earlier quoted context omitted.
I would go the other way around. Why start with an SQL database? When I start something new, I don't want to fiddle around with tables every time I change my model.
I agree but the baby of “joins” is often thrown out with the bathwater of “schemas” Is there a relational schemaless DB I wonder?
Most of my tables have a column called “metadata”, “extra” or “ payload” with jsonb type… for the data i don’t want to model the rigid way.
It’s no longer relational vs. NoSQL, you can get the best of both worlds. Assuming of course you don’t need “planetscale”.
Re: A Poor Man's API
#116Earlier quoted context omitted.
Supabase requires Postgres logical replication which Neon doesn't quite have yet have (but it's on the roadmap) https://community.neon.tech/t/plans-for-logical-replication/... I'm also really excited about Neon. My dream stack is Neon (Postgres) + ReadySet (database caching proxy) + Supabase.
Interesting. I assume Supabase requires it because supabase/realtime depends on it? Personally I'm more interested in vanilla PostgREST than Supabase's implementation of it, or their realtime implementation. It seems really cool but I'm not 100% sold on their ability to evaluate complex RLS rules, which is an important one for me. ReadySet looks cool, I'll check it out. Thanks!
That's right (regarding listening to the WAL - replication). I actually just stole that part of the Supabase realtime code for my own lib (so I can do logic in Elixir).
I haven't used their role based stuff but it looks pretty good.
Re: A Poor Man's API
#117Earlier quoted context omitted.
Perhaps I'm a zealot: HATEOAS is one required part of REST as per Roy Fielding, who came up with both. What does "REST" mean to you?
"When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean — neither more nor less." To me, like most people, REST means an http-based API where we use GET, POST, PUT, DELETE etc. to interact with resources. This in full understanding that under a literal interpretation of the enlightened one's (Roy Fielding's) utterances, REST mandates HATEOAS, meaning that there are o…
Fair!
Re: A Poor Man's API
#118Earlier quoted context omitted.
At some point CRUD goes from being pure CRUD to mostly CRUD with a few special requirements - e.g. complex RBAC rules, decorating data, API versions, integrating third-party APIs, scaling. They're easy to do in most app frameworks (Laravel, Django, Rails), tricky in something like Postgrest. I haven't use Hasura.
You can get really far with database views (decorating data, especially), functions (all sorts of biz logic) and Postgres roles for RBAC. But I hear you on integrating with 3rd party APIs, etc. Fwiw, there's a number of PostgREST backend client libraries to help with that.
I presume you mean postgres client libraries? Or have I missed a postgrest feature?
Re: A Poor Man's API
#119Earlier quoted context omitted.
Supabase requires Postgres logical replication which Neon doesn't quite have yet have (but it's on the roadmap) https://community.neon.tech/t/plans-for-logical-replication/... I'm also really excited about Neon. My dream stack is Neon (Postgres) + ReadySet (database caching proxy) + Supabase.
Interesting. I assume Supabase requires it because supabase/realtime depends on it? Personally I'm more interested in vanilla PostgREST than Supabase's implementation of it, or their realtime implementation. It seems really cool but I'm not 100% sold on their ability to evaluate complex RLS rules, which is an important one for me. ReadySet looks cool, I'll check it out. Thanks!
> I'm not 100% sold on their ability to evaluate complex RLS rules
You don’t need to be sold on our ability - all rules are run on the database itself. Supabase is just Postgres, we don’t run any forks. We run vanilla PostgREST too (behind a proxy)
Re: A Poor Man's API
#120Earlier quoted context omitted.
I agree but the baby of “joins” is often thrown out with the bathwater of “schemas” Is there a relational schemaless DB I wonder?
Most of my tables have a column called “metadata”, “extra” or “ payload” with jsonb type… for the data i don’t want to model the rigid way. It’s no longer relational vs. NoSQL, you can get the best of both worlds. Assuming of course you don’t need “planetscale”.
Nice, and by the looks of it you can still do joins to what is inside the jsonb. I presume indexes are possible too (or if not just pull that data out to actual columns).