......after you create a record of the shipment in your database and create additional shipment status events while it's ongoing. Cmon, stop thinking this must be one object.
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.
At its worst, it’s downright dangerous. I’ve worked at places where the data model was exposed as-is in this CRUD fashion, with nothing in place to enforce sanity. So if you had an Order entity, some other developer could come along and just PATCH it with a different customer ID. Zero encapsulation with the power entirely in the hands of the caller. It was a nightmare to work with.
@@ing50c yes! I've said the same thing many times and been shouted down. Basically with CRUD and REST you are exposing your inner structures. Its crazy to me that people are just realizing what was obvious from the start. I blame those who just follow the blogs and don't think for themselves. So many times their retort to my argument was 'well such and such does it'.
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!!
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.
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.
Can't speak for Derek, but what my company does is use CQRS. All commands are pretty much self explanatory in terms of what they do and they all are executed with POST. They all accept tailor made input parameters for that particular command. Examples: POST api/users/createUser POST api/orders/updateShippingAddress POST api/orders/cancel All queries are done via GET in typical REST fashion. Simple.
I plan on creating another video detailing that as I think it's a good idea if I can find an example that's primarily CRUD and change it to illustrate.
@@svorskemattias sure, why not? REST dogma gives nothing imo. If the command is properly named, it should be apparent what it does. We use commands (POST) for queries that are more like "computations".
@@Coburah I use POST mostly to just reduce my mental overhead. I don't need caching. There's always a body for parameters, no need to use queryparams or URL-segments for that. I only use GET when it's the browser that natively uses the URI, like for an IMG-tag.
Vendors: "Our standard system have this great API you can use." Me: "That pile of turd? That's basically an APi wrapping CRUD operations on your database"
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.
Fully agree, except on the "it might even be the majority", Not so sure about that. Let CRUD be CRUD where that's truly what it is. However in my experience, in large business systems, that's not at all what it is.
@@CodeOpinion I think it depends on the systems. I've worked on a lot of systems that have pages to essentially CRUD entities/data that are used in the actual business workflows in the app. Between that and pages of tabular/reporting views, they often end up with more 'surface area' than the business flows themselves.
@@adambickford8720 I agree with this sentiment: CRUD fits neatly when you have essentially "forms for entities". Just load the "form", update in UI, send back to backend to persist. I guess the problem is that people then reuse that "form data" for other purposes...
i like crud based systems and then distributed events based off those, but i think that defining the crud event in smaller terms is appropriate. for example, update_user is too broad, update_user_email_by_admin is much better, and also update_user_email_by_user is much better, both are updates, and follow a crud pattern but are very fine grained because different events need to transpire based off of each action, which is essentially no different than what you described (i think???)
CRUD APIs are suitable for master (clients, products ) and configuration tables. Any update is pusblshed into an event channel. Transactional APIs trigger worflows and processes that modify transactional tables. Personally, I don't like microservices because of data integrity issues, I prefer to break the system into isolated modules/services that can rely on DB transactions / commitis and rollbacks.
The real issue here is the architecture of the system and not CRUD. You should not directly expose database tables through APIs. Also from the example you gave with CURD, one would fall into that trap if they don't do proper domain modelling or do not do proper abstractions; leaving "all logic to CRUD.
@CodeOpinion like the way most resources tell you to use jwt as if it is the standard or silver bullet for all situations, without pointing out the trade-offs one should be making and the specifications for each platform and the bigger architecture of the system like how now you can have a client component, a server component, a server action and, remote backend and a 3rd party intégration all in one single small app. We need more content explaining how context is king in various topic that are victim to the crowds mentality and chasing the shiny things!
Can we have a detailed video, where you refactor a CRUD based API based on the suggested principles
Great suggestion!
@@CodeOpinion would love that, please do it!
Yeah please do this. @CodeOpinion. It works really help a lot
💯. From a business perspective, we don't "create a shipment", we "SHIP an order".
......after you create a record of the shipment in your database and create additional shipment status events while it's ongoing.
Cmon, stop thinking this must be one object.
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.
Agree'd. I advocate for hypermedia a lot to guide UI/clients but there is so much pushback or dismissal of it, I think it's too far gone.
At its worst, it’s downright dangerous.
I’ve worked at places where the data model was exposed as-is in this CRUD fashion, with nothing in place to enforce sanity.
So if you had an Order entity, some other developer could come along and just PATCH it with a different customer ID.
Zero encapsulation with the power entirely in the hands of the caller. It was a nightmare to work with.
@@ing50c yes! I've said the same thing many times and been shouted down. Basically with CRUD and REST you are exposing your inner structures. Its crazy to me that people are just realizing what was obvious from the start. I blame those who just follow the blogs and don't think for themselves. So many times their retort to my argument was 'well such and such does it'.
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!!
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.
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.
I've been learning and exposed to CRUD apps since day 1, and this opens a new horizon for me.
I think CRUD is so prevalent because the first thing a lot of developers are taught to make is a TODO list app.
What would an API example look like in these cases?
Need an end to end example
I agree with you Derek, but would love to see how you design APIs that are not "CRUD/REST" for supporting business processes.
Can't speak for Derek, but what my company does is use CQRS. All commands are pretty much self explanatory in terms of what they do and they all are executed with POST. They all accept tailor made input parameters for that particular command. Examples:
POST api/users/createUser
POST api/orders/updateShippingAddress
POST api/orders/cancel
All queries are done via GET in typical REST fashion.
Simple.
I plan on creating another video detailing that as I think it's a good idea if I can find an example that's primarily CRUD and change it to illustrate.
@@Coburah I'm even doing queries with POST.
@@svorskemattias sure, why not? REST dogma gives nothing imo. If the command is properly named, it should be apparent what it does. We use commands (POST) for queries that are more like "computations".
@@Coburah
I use POST mostly to just reduce my mental overhead. I don't need caching. There's always a body for parameters, no need to use queryparams or URL-segments for that.
I only use GET when it's the browser that natively uses the URI, like for an IMG-tag.
Vendors: "Our standard system have this great API you can use."
Me: "That pile of turd? That's basically an APi wrapping CRUD operations on your database"
Exactly
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.
Fully agree, except on the "it might even be the majority", Not so sure about that. Let CRUD be CRUD where that's truly what it is. However in my experience, in large business systems, that's not at all what it is.
@@CodeOpinion I think it depends on the systems. I've worked on a lot of systems that have pages to essentially CRUD entities/data that are used in the actual business workflows in the app. Between that and pages of tabular/reporting views, they often end up with more 'surface area' than the business flows themselves.
@@adambickford8720 I agree with this sentiment: CRUD fits neatly when you have essentially "forms for entities". Just load the "form", update in UI, send back to backend to persist. I guess the problem is that people then reuse that "form data" for other purposes...
Isn't it supposed to have another layer ? Another layer above the crud layer ?
i have a hard time modeling this
i like crud based systems and then distributed events based off those, but i think that defining the crud event in smaller terms is appropriate. for example, update_user is too broad, update_user_email_by_admin is much better, and also update_user_email_by_user is much better, both are updates, and follow a crud pattern but are very fine grained because different events need to transpire based off of each action, which is essentially no different than what you described (i think???)
CRUD APIs are suitable for master (clients, products ) and configuration tables. Any update is pusblshed into an event channel.
Transactional APIs trigger worflows and processes that modify transactional tables.
Personally, I don't like microservices because of data integrity issues, I prefer to break the system into isolated modules/services that can rely on DB transactions / commitis and rollbacks.
i like crud.
Absolutely can relate!
Big fan of all your videos!
Thanks!
Yesssir! Wholeheartedly agreed.
one of the best videos
It depends. And people are lazy to think and shied away from making crucial decisions. Cover-my-assssssets strategy implemented from top to bottom.
The real issue here is the architecture of the system and not CRUD. You should not directly expose database tables through APIs. Also from the example you gave with CURD, one would fall into that trap if they don't do proper domain modelling or do not do proper abstractions; leaving "all logic to CRUD.
Great, need a video like this about authentication flows, refresh mechanism, OIDC and OAuth
Elaborate a bit more on what you mean.
@CodeOpinion like the way most resources tell you to use jwt as if it is the standard or silver bullet for all situations, without pointing out the trade-offs one should be making and the specifications for each platform and the bigger architecture of the system like how now you can have a client component, a server component, a server action and, remote backend and a 3rd party intégration all in one single small app.
We need more content explaining how context is king in various topic that are victim to the crowds mentality and chasing the shiny things!