Why Everything Is CRUD | Hacker News Reader

Why Everything Is CRUD

blog.smartclient.com

32 pointschenster30 comments

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.

To add:

If you want to do CRUD but without the headaches of U and D you can do this:

https://en.wikipedia.org/wiki/Bitemporal_modeling

It may seem scary at first and requires more thought, but the benefits are very real, even if the history is not exposed to users in any way.

My company is in the process of retroactively making our crud "ledger" into a bitemporal one.

We're all pretty keen for it. Looks great!

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

And people storing other people's personal data end up with fines if they don't remove the data on request. The whole situation got so bad, that timescale had several bugs which prevented U and D of single records, you could only delete a shard. At least C and R is fast.

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.

CRUD boils down to, Write (for the first time), Read, Write (not the first time) and Write (overwrite the thing or the pointer to it with zeroes or something).

So, really, all computing boils down to a Turing machine. No need to learn any other technology.

All computing boils down to recursive functions. No need to learn any other thechnology than lambda calculus.

And all that can be done by the mov instruction no need to learn anything other than mov.

Seeing a program written in the DDD way can be enlightening. Almost all programmers these days start with databases as a given. So they're writing code that in inseparable from the database and it's no wonder it all looks like CRUD. But a well architected program won't look like that, it will look like whatever problem it's trying to solve. Even something dead basic like a blog which is often the CRUD app tutorial shouldn't be about CRUD, it should be about "posting", "editing", "drafts", "publishing" etc.

You speak from my soul! An often underestimated fact is the future growth in features and complexity. Following the CRUD way this might easily end up in a mess, where you can hardly see domain concepts in all the technical code.

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.

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.

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.

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.

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

No updates in Spain?

Editing/Updates

Ok. So no Read in Spain?

Why leave out the R for reading? Usually that needs the same consideration when it comes to authorization and similar processes.

I imagine it is a given if you are able delete/update something that you can read it?

Yes, but the opposite is not true.

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

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.

> I always used to wonder what the "real" backend engineers do.

Think ChatGPT, people aren't there to do CRUD, they are there to talk to the model. Saving the results and what they write is a useful feature so CRUD is still needed, but not the main attraction.

Or any other kind of server that computes something, like a game server, as long as you want to write a server program instead of just storing data.

> Everything I design, I basically cast it as ER … wonder what the "real" backend engineers do.

I for one spend a fair amount of time refactoring reports and other complex requests that ER & friends generate absolute monsters for, because the data model is optimised for just plonking data in and pulling it back a few objects at a time, with no thought to larger access patterns that are going to be needed by the users later. Sometimes that means just improving the access SQL (replacing the generated mess with something more hand crafted), sometimes it is as simple as improving the data's indexing strategy, someone the whole schema needs a jolly good visit from the panel beater.

A particular specialty is turning report/dashboard (both system-wide and per-user) computations that have no business taking so long over _that_ size of data, from "takes so long we'll have to precompute overnight and display from cache" to hundreds of even tens of milliseconds, otherwise known as "wow that is quick enough to run live!".

This is exacerbated by devs working on local on-prem SQL Server instances, with dedicated many-core CPUs and blinding fast SSDs, initially, then the product being run in production on AzureSQL where for cost reasons several DBs are crammed into a standard-class elastic pool where CPU & memory are more limited and IO for anything not already in the buffer pool is several orders of magnitude slower than local (think "an elderly asthmatic arthritis-riddled ant librarian fetching you an encyclopaedia from back store" slow).

The other big "oh, it worked well in dev" cause is that even when people dev/test against something akin to the final production infrastructure, they do that testing with an amount of data that some clients will generate in days, hours, or even every few minutes (and that is ignoring the amount that will just arrive in one go as part of an initial on-boarding migration for some clients).

Glorified-Predictive-Text generated EF code is not currently helping any of this.

</rant> :-)

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.

Also, everything is binary, zero or one.

Zero, one, or many.

That's almost (Terry Pratchett's) trollish counting.

For trolls, it's quaternary to a point: one, two, three, many, many-one, many-two . . . many-many-many-three, lots

Reply on news.ycombinator.com