4 ms·

Basically re-inventing MySQL / PG but worse. Next step, we don't have auth over the network, let's bake in RBAC into SQLite.

by Thaxll 4y ago

vidarh 4y ago
From what else they're doing, it appears the point is to be able to use sqlite in serverless setups where MySQL/Postgres would be way too heavy to deploy on a per-customer or per-function basis.
- matesz 4y ago
  Honestly I don't get the point of edge. Do people really care whether their website loads in 50ms vs 300ms?
  - maxmcd 4y ago
    Sure it's on a bit of a hype wave at the moment, but yes, most internet users are mobile users that don't live in major metropolitan areas with robust internet infrastructure? I think at least having the option to serve some things at the edge can dramatically improve the browsing experience for those users (and many others!).
  - mirzap 4y ago
    Of course they care. It directly impacts on conversion rates. I'm still stunned with simple fact that most people think 100ms doesn't make a difference (for their business). https://www.globaldots.com/resources/blog/how-website-speed-affects-conversion-rates/ https://www.globaldots.com/resources/blog/how-website-speed-...
    - matesz 4y ago
      Can't they just cache let's say these 1000 marketing, sales and customer support pages into cdn then?
      - travisjungroth 4y ago
        It applies to applications as well. My general beliefs on the topic: most improvements that people come up with don't move the needle for the business. Doing the same thing but a little better will sometimes have an impact, generally not. The exception to this is speed. Speed improvements deliver more consistently than anything else, and they keep delivering as you improve. Improving speed is the surest bet you can make.
    - billythemaniam 4y ago
      While it matters, +-100ms doesn't matter in the vast majority of web use cases. There is even such a thing as too fast. If a user doesn't notice the page updated due to speed, that is also a poor experience. 300ms would actually feel incredibly fast to most web users for most websites. Less than 1 second is a good guideline for page load though as shown by your link.
      - jamil7 4y ago
        > There is even such a thing as too fast. If a user doesn't notice the page updated due to speed, that is also a poor experience. If you're relying on your app's execution time to demonstrate this to a user, then you have poor UX. Instant changes and updates have been the norm in mobile apps forever and optimistic UI is becoming pretty standard on the web too, see Linear for example.
  - VWWHFSfQ 4y ago
    One request being 50ms or 300ms probably doesn't really matter. But 10,000 requests _per second_ being 50 or 300ms matters a lot
  - vidarh 4y ago
    To take a different tack then the other two (at time of writing) replies to this: It's not just at the edge. Being able to add databases with wild abandon and just provide a key to an S3 compatible bucket to replicate it to, and not have to worry about any server setup or replication is appealing whether or not your setup is otherwise centralised. For some setups you do want to share data across user accounts, but for others, isolation along customer or individual user boundaries is not just fine but an advantage (no accidentally writing a query that returns too much data). And then, it's a plus if having a million databases and selectively spread them out over your servers is trivial.
matesz 4y ago
I never thought people take restricting access from within database seriously. Like row security policies [1] in postgres. But now as I look at it, it must be taken seriously, just because those features exist. Is anybody here using it in production with success? [1] https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html
- aobdev 4y ago
  If I understand correctly, it seems to be a cornerstone of Supabase’s Authorization features. https://supabase.com/docs/guides/auth/row-level-security https://supabase.com/docs/guides/auth/row-level-security
- pphysch 4y ago
  > But now as I look at it, it must be taken seriously, just because those features exist. You can do pretty much everything within Postgres, from ETL to Authz to serving HTML templates and GIS apps. However, that doesn't mean you should, or that anyone is seriously using it in production on a large scale (after evaluating alternatives).
- sally_glance 4y ago
  Jep, my company uses Postgres RLS for a pretty big project for a client in the finance sector. It's the foundation of our multi-tenant setup there. We connect with a single DB user, but set a session variable at the start of each transaction. This session variable is then used by the RLS policies to filter the data. Works like a charm, you basically get to build your app like it was dealing with a single tenant DB. Just make sure it's as hard as humanly possible for application developers to forget setting that tenant ID when they query... In our case we have a custom JPA base repository which takes care of that, and some PMD rules to catch rogue repos/queries.
- giraffe_lady 4y ago
  Yes I've used it a bunch in production it's great. It is highly valued in some PII-conscious fields for compliance reasons that I don't fully understand, but becoming competent with postgres RLS has been a huge benefit for my career. The main practical downside is that it is more precise and rigorous than your app- or business-level auth logic is likely to be, and has no real escape hatches. If you're trying to drop it on an existing system you're going to spend a lot of time going back and forth with whoever to shake out edge case ambiguities in your rbac policy that weren't obvious or relevant before.

Basically re-inventing MySQL / PG but worse. Next step, we don't have auth over the network, let's bake in RBAC into SQLite.

by Thaxll 4y ago

Basically re-inventing MySQL / PG but worse. Next step, we don't have auth over the network, let's bake in RBAC into SQLite.

vidarh 4y ago

From what else they're doing, it appears the point is to be able to use sqlite in serverless setups where MySQL/Postgres would be way too heavy to deploy on a per-customer or per-function basis.

matesz 4y ago
Honestly I don't get the point of edge. Do people really care whether their website loads in 50ms vs 300ms?
- maxmcd 4y ago
  Sure it's on a bit of a hype wave at the moment, but yes, most internet users are mobile users that don't live in major metropolitan areas with robust internet infrastructure? I think at least having the option to serve some things at the edge can dramatically improve the browsing experience for those users (and many others!).
- mirzap 4y ago
  Of course they care. It directly impacts on conversion rates. I'm still stunned with simple fact that most people think 100ms doesn't make a difference (for their business). https://www.globaldots.com/resources/blog/how-website-speed-affects-conversion-rates/ https://www.globaldots.com/resources/blog/how-website-speed-...
  - matesz 4y ago
    Can't they just cache let's say these 1000 marketing, sales and customer support pages into cdn then?
    - travisjungroth 4y ago
      It applies to applications as well. My general beliefs on the topic: most improvements that people come up with don't move the needle for the business. Doing the same thing but a little better will sometimes have an impact, generally not. The exception to this is speed. Speed improvements deliver more consistently than anything else, and they keep delivering as you improve. Improving speed is the surest bet you can make.
  - billythemaniam 4y ago
    While it matters, +-100ms doesn't matter in the vast majority of web use cases. There is even such a thing as too fast. If a user doesn't notice the page updated due to speed, that is also a poor experience. 300ms would actually feel incredibly fast to most web users for most websites. Less than 1 second is a good guideline for page load though as shown by your link.
    - jamil7 4y ago
      > There is even such a thing as too fast. If a user doesn't notice the page updated due to speed, that is also a poor experience. If you're relying on your app's execution time to demonstrate this to a user, then you have poor UX. Instant changes and updates have been the norm in mobile apps forever and optimistic UI is becoming pretty standard on the web too, see Linear for example.
- VWWHFSfQ 4y ago
  One request being 50ms or 300ms probably doesn't really matter. But 10,000 requests _per second_ being 50 or 300ms matters a lot
- vidarh 4y ago
  To take a different tack then the other two (at time of writing) replies to this: It's not just at the edge. Being able to add databases with wild abandon and just provide a key to an S3 compatible bucket to replicate it to, and not have to worry about any server setup or replication is appealing whether or not your setup is otherwise centralised. For some setups you do want to share data across user accounts, but for others, isolation along customer or individual user boundaries is not just fine but an advantage (no accidentally writing a query that returns too much data). And then, it's a plus if having a million databases and selectively spread them out over your servers is trivial.

matesz 4y ago

I never thought people take restricting access from within database seriously. Like row security policies [1] in postgres. But now as I look at it, it must be taken seriously, just because those features exist. Is anybody here using it in production with success? [1] https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html

aobdev 4y ago
If I understand correctly, it seems to be a cornerstone of Supabase’s Authorization features. https://supabase.com/docs/guides/auth/row-level-security https://supabase.com/docs/guides/auth/row-level-security
pphysch 4y ago
> But now as I look at it, it must be taken seriously, just because those features exist. You can do pretty much everything within Postgres, from ETL to Authz to serving HTML templates and GIS apps. However, that doesn't mean you should, or that anyone is seriously using it in production on a large scale (after evaluating alternatives).
sally_glance 4y ago
Jep, my company uses Postgres RLS for a pretty big project for a client in the finance sector. It's the foundation of our multi-tenant setup there. We connect with a single DB user, but set a session variable at the start of each transaction. This session variable is then used by the RLS policies to filter the data. Works like a charm, you basically get to build your app like it was dealing with a single tenant DB. Just make sure it's as hard as humanly possible for application developers to forget setting that tenant ID when they query... In our case we have a custom JPA base repository which takes care of that, and some PMD rules to catch rogue repos/queries.
giraffe_lady 4y ago
Yes I've used it a bunch in production it's great. It is highly valued in some PII-conscious fields for compliance reasons that I don't fully understand, but becoming competent with postgres RLS has been a huge benefit for my career. The main practical downside is that it is more precise and rigorous than your app- or business-level auth logic is likely to be, and has no real escape hatches. If you're trying to drop it on an existing system you're going to spend a lot of time going back and forth with whoever to shake out edge case ambiguities in your rbac policy that weren't obvious or relevant before.