CRUD APIs are Poor Design

Typical API Design consists of building around database records and Create Read Update Delete. Making nothing more than a UI or HTTP API around a database. But that database schema was driven by business processes. But if those business processes don't live in your system, then trying to evolve your schema can be challenging. Instead of modeling data structure, model business processes and the data behind them.

🔗 EventStoreDB

💥 Join this channel to get access to a private Discord Server and any source code in my videos.

🔥 Join via Patreon

✔️ Join via YouTube

0:00 "REST"
3:18 What do you say you do?
5:29 Extend
8:46 Model Business Processes

[anikaitmakkar]

Can we have a detailed video, where you refactor a CRUD based API based on the suggested principles

[joelv]

💯. From a business perspective, we don't "create a shipment", we "SHIP an order".

[robotrabbit]

Dude, there is so much nuance in everything about business software. I read so much stuff about software development and DDD and watched a lot of videos especially from your channel. And I am honest here. A lot of the time think I understood what you and those books are telling me and then I start programming at work on a real system and I make mistakes just to realize a few weeks later down the line that I was already told the solution to the problem. I am not sure how the rest does it, but everytime this happens I realize that I do not fully understand the underlying problems of the topics you and the books are talking about. I think this is why experience matters.

I am grateful for your work on the channel. Thanks

[Rick]

Currently working on a microservices application that just crud for the most part. It's horrible, the UI around it has alot of logic in it because its basically a big leaky abstraction.

So now my team is busy consolidating the microservices and designing the endpoints around behavior instead of crud based endpoints. The UI is getting simpler every iteration and as a bonus faster.

It works for tests as well, we used to have tests for every single method but that was just dumb. Now we test behaviors and sure the tests are larger in scope but the actually test things that are of value and they give us alot of freedom to refactor.

The only one that seems to have a problem with it is weirdly enough our solution architect. This slows down our efforts a bit but we still get it done.

[majormartintibor]

I agree with you Derek, but would love to see how you design APIs that are not "CRUD/REST" for supporting business processes.

[transientwaveform]

Louder for the people in the back!!! Systems built this way are wildly irresponsibly engineered in the real world, and yet it's so pervasive now because nobody challenges it because they assume it's "best practice" due to the tutorials they followed!!

[TheCardSlayer]

What would an API example look like in these cases?

[PhillippeLevidad]

Great video as always! At the end, you asked why CRUD is so dominant in software development. I think it's because there are so many tutorials on building CRUD-based systems, and people are often just looking for step-by-step guides. The discussions you present are more philosophical and less practical in the sense that you're not always showing exactly *how* to implement something.

A good example is how people often request videos where you refactor bad examples into good ones. This isn't a critique—I love these discussions. I get why you don't always show a practical code approach: "it depends." There isn't a single right way to do things, and your channel is called "Code Opinion" for a reason. Still, the abundance of CRUD examples and the lack of non-CRUD ones might be why it's so prevalent.

[allenbythesea]

I've been opposed to the CRUD/REST paradigm since its inception. These concepts push business logic up into the UI instead of in the api/business layer. Glad to see others coming around as well.

[funkdefied]

I love the square peg round hole. It’s been my intuition for a while, but I haven’t heard someone say it.

I love thinking about my APIs as actions, RPC style

[vuhoang]

I've been learning and exposed to CRUD apps since day 1, and this opens a new horizon for me.

[adambickford]

CRUD is so predominant because many times, that's all you genuinely need. In fact, it might even be the majority and you *should* use it if it makes sense. If you're just going to essentially validate the input of your endpoint and persist it... do that. Don't invent some abstraction (DDD, OOP, etc) 'just in case' or for the sole purpose of semantic decoupling.

Sometimes a cigar is just a cigar.

[buriedstpatrick]

I think CRUD is so prevalent because the first thing a lot of developers are taught to make is a TODO list app.

[lost-prototype]

There are so many usual suspects of problems in CRUD systems, and it causes people to become so fixated on superficial DRY, high coupling, loss of context... The end is basically change data capture and never ending tack-ons to recapture lost context.

CQRS/business operations.... Those are the way to go. Simple transaction scripts. Lean flows, even if there's a bit of duplication.

You can always maintain multiple rich domain models.

The bonus once you follow all the advice? Simpler test cases, higher level of certainty in the system.

[marcwinner]

Hey Derek! Great video as always! I think it would be beneficial to some of us viewers to see the difference in actual code to really nail the idea. Could you do that?

[Leo-tfgu]

Ruby on Rails with it's Active Record ORM advocated this more than anything else.

[GabrielSoldani]

It probably doesn’t help that HTTP and REST were designed at a time that the Web that was mostly used to publish and consume documents, not to drive business processes.

[ardenfraser]

I think CRUDs prevalence speaks more to a lack of business analysis that usually comes with software projects where a businesses core focus is not on software. Also tight time frames make it difficult to argue the need for 6 endpoints were previously 1 would suffice.

[Dan-codes]

As a CRM engineer for a logistics company, this is interesting.

[commonsensedev]

He is proposing Event Driven design, but CRUD exist behind it or with it

How can you create an order without entering who made the order and list of items to order, and how will you do it without CRUD?