5 ms·

Have you ever build a complex app like this? In particular, have you have to do testing, security (eg. row level security), manage migrations, change managemen

Have you ever build a complex app like this? In particular, have you have to do testing, security (eg. row level security), manage migrations, change management (eg. for SOC2 or other security frameworks), cache offloads (Redis, and friends), support for microservices, etc. Comments like this give me a vibe of young developers trying out Supabase for the first time feeling like that approach can scale indefinitely.

rbees 1y ago
> Comments like this give me a vibe of young developers I don’t think so. The context is about avoiding joining in memory, which is fairly awful to do in a application, and should be avoided, along with uninformed use of ORMs, which often just add a layer of unwarranted complexity leading to things like the dreaded N+1 problem that most inexperienced Rails developers had when dealing with ActiveRecord. If anything, what you’re talking about sounds like development hell. I can understand a database developer having to bake in support for that level of security, but developing an app that actually uses it gets you so far in the weeds that you can barely make progress trying to do normal development. A developer with several years of experience or equivalent will have pride in developing complexity and using cool features that make them feel important. After a developer has maybe twice that many years experience or equivalent, they may develop frameworks with the intent to make code easier to develop and manage. And beyond that level of experience, developers just want code that’s easy to maintain and doesn’t make stupid decisions like excessive complexity. But, they know they have to let the younger devs make mistakes, because they don’t listen, so there is no choice but to watch hell burn. Then you retire or get a different job.
- tossandthrow 1y ago
  I don't know what I am talking about that sounds like hell? I am merely talking about properties of developing complex web applications that have traditionally not been easy to work with in SQL. I am in particular not proposing any frameworks. How can that sound like hell?
lurking_swe 1y ago
Not the person you replied to, but I have! A java project I worked on a couple years ago used a thin persistence layer called JOOQ (java library). It basically helps you safely write sql in java, without ORM abstractions. Worked just fine for our complex enterprise app. Sql migrations? This is a solved problem: https://github.com/flyway/flyway https://github.com/flyway/flyway What about micro services? You write some terraform to provision a sql database (e.g. aws aurora) just like you would with dynamo db or similar. What does that have to do with ORMs? What about redis? Suddenly we need an ORM to query redis, to check if a key exists in the cache before hitting our DB? That’s difficult code to write? I’m confused reading your comment. It has “you don’t do things my way so you must be dumb and playing with toy projects” vibes.
- tossandthrow 1y ago
  From what I can se jooq is only really type safe with pojo mappings, to what point it is an orm with an expressive query dsl. Alternatively you use record style outputs, but that is prone to errors if positions are changed. Regardless, even with jooq you still accept that there is a sizable application layer to take responsibility of the requirements I listed.
  - lurking_swe 1y ago
    i guess it’s semantics, but i agree with you actually. After all ORM = object relational mapping. However it’s certainly the most lightweight ORM i’ve used in the java and c# world. With JOOQ you are in complete control of what the SQL statements look like and when those queries happen (avoids the common N + 1 risk). _Most_ ORMs i’ve seen attempt to abstract the query from the library user. In our project we generated pojo’s in a CI pipeline, corresponding to a new flyway migration script. The pojos were pushed to a dedicated maven library. This ensured our object mappings were always up to date. And then we wrote sql almost like the old fashioned way…but with a typesafe java DSL.
- __MatrixMan__ 1y ago
  As a previous user of alembic I was surprised that flyway's migrations only go forward by default and that reversing them is a premium feature. That's like having the luxury trim being the one with seatbelts.
cpursley 1y ago
Guessing you are a Rails dev?
Yokohiii 1y ago
I don't understand why all these problems should be easier handled with an ORM then with raw sql?
- tossandthrow 1y ago
  It is a granluarity tradeoff. With SQL you need to explicitly test all queries where the shape granularity is down to field level. When you map data onto an object model (in the dto sense, not oop sense) you have bigger building blocks. This gives a simpler application that is more reliable. Obviously you need to pick a performant orm - and it seems a lot of people in these threads have been traumatized. Personally, I run a complex application where developers freely use a graphql schema and requests are below 50ms p99 - gql in translated into joins by the orm, so we do not have any n+1 issues, etc.
  - deleted 1y ago
    [deleted]
  - radlad 1y ago
    The issue with GraphQL tends to be unoptimized joins instead. Is your GraphQL API available for public consumers? How do you manage them issuing inefficient queries? I've most often seen this countered through data loaders (batched queries that are merged in code) instead of joins, or query whitelists.
    - tossandthrow 1y ago
      While this api in particular is not publicly exposed, that would not be a concern. The key is to hold the same schema on the database as on the graphql and use tooling that can translate a gql query into a single query.
      - radlad 1y ago
        The issue I've seen with GraphQL isn't necessarily the count of queries run, but rather the performance or said queries (i.e. most SQL queries are not performant without proper indexes for the specific use case, but GraphQL allows lots of flexibility in what queries users can run.)

rbees 1y ago

> Comments like this give me a vibe of young developers I don’t think so. The context is about avoiding joining in memory, which is fairly awful to do in a application, and should be avoided, along with uninformed use of ORMs, which often just add a layer of unwarranted complexity leading to things like the dreaded N+1 problem that most inexperienced Rails developers had when dealing with ActiveRecord. If anything, what you’re talking about sounds like development hell. I can understand a database developer having to bake in support for that level of security, but developing an app that actually uses it gets you so far in the weeds that you can barely make progress trying to do normal development. A developer with several years of experience or equivalent will have pride in developing complexity and using cool features that make them feel important. After a developer has maybe twice that many years experience or equivalent, they may develop frameworks with the intent to make code easier to develop and manage. And beyond that level of experience, developers just want code that’s easy to maintain and doesn’t make stupid decisions like excessive complexity. But, they know they have to let the younger devs make mistakes, because they don’t listen, so there is no choice but to watch hell burn. Then you retire or get a different job.

tossandthrow 1y ago
I don't know what I am talking about that sounds like hell? I am merely talking about properties of developing complex web applications that have traditionally not been easy to work with in SQL. I am in particular not proposing any frameworks. How can that sound like hell?

lurking_swe 1y ago

Not the person you replied to, but I have! A java project I worked on a couple years ago used a thin persistence layer called JOOQ (java library). It basically helps you safely write sql in java, without ORM abstractions. Worked just fine for our complex enterprise app. Sql migrations? This is a solved problem: https://github.com/flyway/flyway https://github.com/flyway/flyway What about micro services? You write some terraform to provision a sql database (e.g. aws aurora) just like you would with dynamo db or similar. What does that have to do with ORMs? What about redis? Suddenly we need an ORM to query redis, to check if a key exists in the cache before hitting our DB? That’s difficult code to write? I’m confused reading your comment. It has “you don’t do things my way so you must be dumb and playing with toy projects” vibes.

tossandthrow 1y ago
From what I can se jooq is only really type safe with pojo mappings, to what point it is an orm with an expressive query dsl. Alternatively you use record style outputs, but that is prone to errors if positions are changed. Regardless, even with jooq you still accept that there is a sizable application layer to take responsibility of the requirements I listed.
- lurking_swe 1y ago
  i guess it’s semantics, but i agree with you actually. After all ORM = object relational mapping. However it’s certainly the most lightweight ORM i’ve used in the java and c# world. With JOOQ you are in complete control of what the SQL statements look like and when those queries happen (avoids the common N + 1 risk). _Most_ ORMs i’ve seen attempt to abstract the query from the library user. In our project we generated pojo’s in a CI pipeline, corresponding to a new flyway migration script. The pojos were pushed to a dedicated maven library. This ensured our object mappings were always up to date. And then we wrote sql almost like the old fashioned way…but with a typesafe java DSL.
__MatrixMan__ 1y ago
As a previous user of alembic I was surprised that flyway's migrations only go forward by default and that reversing them is a premium feature. That's like having the luxury trim being the one with seatbelts.

cpursley 1y ago

Guessing you are a Rails dev?

Yokohiii 1y ago

I don't understand why all these problems should be easier handled with an ORM then with raw sql?

tossandthrow 1y ago
It is a granluarity tradeoff. With SQL you need to explicitly test all queries where the shape granularity is down to field level. When you map data onto an object model (in the dto sense, not oop sense) you have bigger building blocks. This gives a simpler application that is more reliable. Obviously you need to pick a performant orm - and it seems a lot of people in these threads have been traumatized. Personally, I run a complex application where developers freely use a graphql schema and requests are below 50ms p99 - gql in translated into joins by the orm, so we do not have any n+1 issues, etc.
- deleted 1y ago
  [deleted]
- radlad 1y ago
  The issue with GraphQL tends to be unoptimized joins instead. Is your GraphQL API available for public consumers? How do you manage them issuing inefficient queries? I've most often seen this countered through data loaders (batched queries that are merged in code) instead of joins, or query whitelists.
  - tossandthrow 1y ago
    While this api in particular is not publicly exposed, that would not be a concern. The key is to hold the same schema on the database as on the graphql and use tooling that can translate a gql query into a single query.
    - radlad 1y ago
      The issue I've seen with GraphQL isn't necessarily the count of queries run, but rather the performance or said queries (i.e. most SQL queries are not performant without proper indexes for the specific use case, but GraphQL allows lots of flexibility in what queries users can run.)