Why Everything Is CRUD

32 points by chenster 10 months ago | 30 comments
  • mrkeen 10 months ago
    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.

    • dgb23 10 months ago
      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.

      • drekipus 10 months ago
        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!

      • yetihehe 10 months ago
        > 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.

      • cryptos 10 months ago
        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.

        • bux93 10 months ago
          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.

          • frodation 10 months ago
            All computing boils down to recursive functions. No need to learn any other thechnology than lambda calculus.
            • zerodensity 10 months ago
              And all that can be done by the mov instruction no need to learn anything other than mov.
          • globular-toast 10 months ago
            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.
            • cryptos 9 months ago
              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.
          • dools 10 months ago
            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.

            • bubblyworld 10 months ago
              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.
              • matsemann 10 months ago
                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.

                • ivan_gammel 10 months ago
                  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.
                  • kwanbix 10 months ago
                    In spanish we call it ABM: Altas, Bajas, Modificaciones, or Creation, Deletion, Editing.
                    • SahAssar 10 months ago
                      Why leave out the R for reading? Usually that needs the same consideration when it comes to authorization and similar processes.
                      • kwanbix 10 months ago
                        I imagine it is a given if you are able delete/update something that you can read it?
                        • SahAssar 10 months ago
                          Yes, but the opposite is not true.
                      • ofrzeta 10 months ago
                        No updates in Spain?
                        • kwanbix 10 months ago
                          Editing/Updates
                          • ofrzeta 10 months ago
                            Ok. So no Read in Spain?
                      • cies 10 months ago
                        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...

                        • latentnumber 10 months ago
                          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.
                          • Jensson 10 months ago
                            > 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.

                            • dspillett 10 months ago
                              > 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> :-)

                            • TeeWEE 10 months ago
                              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.
                              • rapnie 10 months ago
                                Also, everything is binary, zero or one.
                                • BerislavLopac 10 months ago
                                  Zero, one, or many.
                                  • drewcoo 10 months ago
                                    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

                                • 10 months ago
                                  • mgaunard 10 months ago
                                    [flagged]
                                    • ofrzeta 10 months ago
                                      I don't know what you mean by "real software development" but ideas and technologies have certainly leaked to other domains, so many "real apps" are now web apps in some shell like Electron or Tauri.