from Hacker News

Why Everything Is CRUD

by chenster on 8/26/24, 5:34 AM with 30 comments

• by mrkeen on 8/26/24, 8:29 AM

  CRUD is good, except for maybe U and D, which are the proverbial erasers in "Accountants don't use erasers or they end up in jail".

  It's all fun and games in the greenfield happy path. Do the wrong modification to someone's bank account? Just update the code so you no longer do the wrong modifications. Leave the bad data in-place. Or if you want to fix the bad data, maybe reach out to the customer to ask what his balance should be. Or check the dev-logs, you do make your dev-logs a better source-of-truth than the database, don't you? Once you 'know' what the balance should be, just use your CRUD operation to set things right, aka "create money".

  I agree with the article that exposing R and U interfaces on all entities is a completely natural, human way of think about it. It allows for completely intuitive patterns like "check-then-act" and "read-modify-write", (which are also the names of race conditions.)

  EDIT: I forgot to comment on the obvious fallback here. If you really screw things up, it might be possible to restore your database to an earlier state, and just disappear all the money which moved through the system after the database snapshot was created.

• by cryptos on 8/26/24, 8:19 AM

  The statement that everything boils down to CRUD is not wrong, but also not very useful. Whether you should think of some operation in CRUD terms or not depends on the level of abstraction you are thinking in. Create, Read, Update, and Delete are mostly technical terms that might not have a well defined or understood meaning in a certain domain.

  Therefore, I would suggest to use "CRUD" terminology mostly the more technical parts of the application (e.g. some adapter to communicate with a database) and to use business terms (from the "ubiquituos language", as it is called in domain-driven design) otherwise.

  I once had a coworker argueing against DDD ideas with the killer argument that it would be only "CRUD". But it was in no way useful to think about the problem in these terms. Later it turned out that we had quite some business logic and that "CRUD" wouldn't have been very helpful to express that.

• by dools on 8/26/24, 8:19 AM

  Hmmm ... it seems that CRUD has become synonymous with "forms that look like the database into which they write stuff", possibly because RoR and Django made "scaffolding" the admin interface so popular.

  Of course everything that works with a database is CRUD because what else can you do with a database apart from create, retrieve, update and delete data?

  I think that if you're doing your job right in interface design the structure of your database shouldn't be immediately apparent to the user. The database design process and the interface design process should be completely separate.

• by bubblyworld on 8/26/24, 8:23 AM

  I think it's true that CRUD is a universal way to compute stuff, since you can represent basically any state state machine (plus memory) as a read/process/write loop. But sometimes you have better primitives available to you, like queues or pub/sub systems, even if technically you could implement those as CRUD under the hood if you wanted to.

• by matsemann on 8/26/24, 8:35 AM

  I'm not sure I'm following the leap, here. Yes, a background process can be seen as CRUD, as you create it and all that. But it's what's creating it that's the problem with many frameworks. If I do a POST to /user, I don't also want to do a POST to /background-tasks/send-sign-up-email. I want both those to happen due to my request to sign up a new user.

  All business logic must happen somewhere. In a CRUD framework, much of that is just pushed to the edges of those consuming the CRUD API, in order to keep the CRUD part clean. A trade off I'm not sure I agree with.

• by ivan_gammel on 8/26/24, 8:19 AM

  This is a valuable exercise in a sense that it demonstrates how a mental model or a design pattern can be adapted to a problem. There can be reasons for that, like e.g. with asynchronous processing where CRUD adds value by offering consistent representation of processing state. What is important, is that very often many different representations of domain exist and it always makes sense to look at the problem from different angles and choose the most beneficial one.

• by kwanbix on 8/26/24, 7:58 AM

  In spanish we call it ABM: Altas, Bajas, Modificaciones, or Creation, Deletion, Editing.

• by cies on 8/26/24, 9:08 AM

  The article says: everything that is CRUD is CRUD.

  That's true. But NOT everything is CRUD.

  Validation is not CRUD (you do not want your DB to validate your data in most cases -- and even whet the DB does validation: the V is not in CRUD). Form submissions are not CRUD. Queues (AMQP, SQS, pub-sub) are notoriously not CRUD. Scaling you cluster is not CRUD. Deploying your software is not CRUD.

  I could go on...

• by latentnumber on 8/26/24, 7:57 AM

  Absolutely! Everything I design, I basically cast it as ER. I'm not even a backend developer but this is such a useful and universal framing (for me, at least, or so I thought) that I always used to wonder what the "real" backend engineers do.

• by TeeWEE on 8/27/24, 4:53 AM

  This person doesn’t seem to know about table stream duality. Crud is just an immutable event stream. All crud systems use this in their journaling system.

• by rapnie on 8/26/24, 8:57 AM

  Also, everything is binary, zero or one.