Hacker Newsnew | past | comments | ask | show | jobs | submit | steve-chavez's commentslogin

> PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over

Do note that by default in PostgreSQL/PostgREST, RLS is the third layer of AuthZ defense, you have table and column level security before and these are closed by default.

> In Supabase's model, it's a breach.

Supabase is currently working on being closed by default.


You're right, the GRANT layer is closed by default in PostgreSQL and PostgREST respects that. But in practice with Supabase, the very first thing you do is `GRANT ALL ON table TO authenticated` (and often `anon`) because nothing works through the client SDK without it. Every tutorial does this, every LLM-generated scaffold does this. At that point the first two layers are effectively gone and RLS is what's left. That's what I meant — not that PostgreSQL lacks defense in depth, but that Supabase's typical workflow collapses it down to one layer pretty quickly. Good to hear they're working on closed-by-default though. Kind of proves the point that the current model has been a problem in practice.

I played starcraft2 13 years ago on Linux, the wizard installer worked just fine.


Yes, it does many-to-many joins automatically: https://docs.postgrest.org/en/v12/references/api/resource_em....


Thanks for the reference. I'll check it out!


> My server is going to provide an API that isolates the application from the DB structure.

The same can be achieved with "schema isolation". See https://docs.postgrest.org/en/v12/explanations/schema_isolat....


Thanks for the reference. I'll take a look.


> If my DB structure changes, I have to force new app versions on every platform because I didn't insulate back-end changes with an API.

To avoid the above problem, it's a standard practice in PostgREST to only expose a schema consisting of views and functions. That allows you to shield the applications from table changes and achieve "logical data independence".

For more details, see https://docs.postgrest.org/en/v12/explanations/schema_isolat....


Thanks. If you're writing functions, though, it seems like nearly as much work as writing traditional endpoints, no?


Not really, the work is much reduced.

1. If your function returns a table type, you can reuse all the filters that PostgREST offers on regular tables or views [1].

2. The SQL code will be much more concise (and performant, which leads to less maintenance work) than the code of a backend programming language.

3. The need for migrations is a common complaint, but you can treat SQL as regular code and version control it. Supabase recently released some tooling [2] that helps with this.

[1]: https://docs.postgrest.org/en/v12/references/api/functions.h...

[2]: https://supabase.com/docs/guides/local-development/declarati...



So cool! For some reason navigating to Github/Discord by clicking the links is slow on my phone (old galaxy s20fe). The click highlight of the button is normal, just going to the sites is slow.


I also got one of these. AFAICT for Linux, we need to wait for kernel 6.12, which is still at the rc stage but should be ready at the end of this month. As a NixOS user, I'm keeping track of this repo [1] for support.

[1]: https://github.com/kuruczgy/x1e-nixos-config


What makes 6.12 the necessary version for this machine?


I have to imagine there's a whole bunch of patches in that tree for this chipset.


The TLDR is that Nginx offers about x2 more throughput than Caddy.


That's false. On the same youtube channel there's a video [1] comparing Nginx vs Envoy and Nginx offers higher throughput.

Besides that, from what I've seen Envoy has a higher dependency footprint:

- It comes bloated with GRPC functionality.

- Configuration requires running python.

I'd be glad to be proven wrong on the performance side of Envoy but so far I've only heard rumors and never seen a conclusive benchmark.

[1]: https://www.youtube.com/watch?v=0Q9I-x--np4


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: