Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Poor Man's API

blog.frankel.ch

Post reply on HN
Print view View original

121–127 of 127 posts

Re: A Poor Man's API

#121

Post by cpursley »

wharfjumper wrote: post #118
cpursley wrote: post #77

Earlier quoted context omitted.

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?

Either or. There are a number of server client libraries that work directly with PostgREST:

https://postgrest.org/en/stable/ecosystem.html#client-side-l...

Re: A Poor Man's API

#122

Post by alex_suzuki »

quickthrower2 wrote: post #120
alex_suzuki wrote: post #115

Earlier quoted context omitted.

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).

Yup, it’s way more than a blob. You can query it.

Re: A Poor Man's API

#123

Post by asalahli »

beachy wrote: post #113
tasuki wrote: post #86

Earlier 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…

But that makes it hard to refer to, search for or have a discussion about real REST, the architectural style. Why use a term that means a different thing when you can just invent/use a new term describing what you want to describe. REST, as Roy Fielding defined it, is an extremely interesting concept to me and I'd love to explore it more, but good luck doing any research on it without getting flooded with countless junk about "REST" or "RESTful" APIs.

Sort of like how youtube is filled with videos about "damascus steel" which is nothing more than steel of random, irrelevant composition with certain visual pattern akin to actual damascus steel. But again, good luck finding a video about the real deal.

Same can be said about ASMR, and many other misappropriated terms people throw around for clickbait.

Rant over.

Re: A Poor Man's API

#124

Post by asalahli »

falcolas wrote: post #93
siscia wrote: post #57

Maybe 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.

Did you know that databases can read from disk? Databases are huge security vulnerabilities and should always have some kind of shim over them. Never expose your relational DB publicly if you want any control over it.

So can the services providing http APIs. What does that have anything to do with security?

Re: A Poor Man's API

#125

Post by omnibrain »

GolDDranks wrote: post #40
bmn__ wrote: post #38

> PostgREST is a fast way to construct a RESTful API. That's false. The responses don't even have hyperlinks.

Just to clear things up a bit (as I remember not knowing about this side of "RESTfulness" a while ago myself): an important part of REST is relying on hypertext, that is pointing to other resources by using URLs. Just returning an ID of a referenced object/resource as a plain number isn't very RESTful, but returning an URL of that object/resource is.

Yes, but who really does this? I never encountered an API doing it. (Not saying they don't exist!)

Re: A Poor Man's API

#126

Post by boomskats »

kiwicopple wrote: post #119
boomskats wrote: post #114

Earlier quoted context omitted.

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)

I've always known that you run vanilla PostgREST, and that it evaluates RLS in-pg, and it all works great. However when I first looked at walrus[0] a while back (18 months ago?), I couldn't quite figure out what the mechanism of action was, i.e. whether the RLS rules were being evaluated in the database or being parsed in from the DDL and then (partially?) reinterpreted by your WAL subscriber. I hope that explains my comment.

I've had another brief look at that repo, and either you've clarified a few things since I last looked at it, or I didn't look at it closely enough in the first place. It makes far more sense to me now, the impersonation + re-query mechanism puts me at 100%.

Thanks for the response, I appreciate it.

[0]: https://github.com/supabase/walrus

Re: A Poor Man's API

#127

Post by steve-chavez »

bmn__ wrote: post #106
Aeolun wrote: post #74

Earlier quoted context omitted.

If you already have relationships between tables, then it shouldn't be that hard to add right?

Right. The problem is not difficulty, but motivation. The responsible programmer begriffs does not have the understanding why it is a good idea to do so, despite bug reporters on Github having spent years in discussions.

To be fair, begriffs never shut down any discussion of HATEOAS, previous contributors did - because at the time users were asking for more JSON capabilities from PostgREST and we needed to focus on those.

We're still open on adding HATEOAS, I've just opened an issue for it: https://github.com/PostgREST/postgrest/issues/2579

Post reply on HN