......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.
@@glhays6832 Think about the domain of a shipping or freight company. Off the top of my head- You might pack a single container with one or more orders from one or more customers. Or a situation where a shipment could consist of many containers that need to be tracked individually AND collectively.
You highlight a thing that Derek talks about again and again: Developers being data-centric, rather than behavior centric. Or technology-centric. And that divorces the code solution from the reality and how users look at the domain.
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
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.
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!!
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'.
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.
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?
Your DB or ORM already implements the CRUD interface, what I've found while working is that sometimes REST APIs act just like proxies to a DB, there is little to no logic in the app and is mostly plagued of conversions between HTTP to the DB driver or ORM, and because of this basically all the logic is spread but mostly living in the UI. When using something like CQRS you create a proper interface for your business and internally you call all the CRUDy like interfaces. In Spanish CRUD sounds similar to the word "crudo" which means "raw" and that is basically the idea I have about CRUD in my mind. They are just raw interfaces which you need to compose to build your business interfaces. Don't expose raw interfaces directly to your clients.
@ArcRCG that's the point of CRUD API, direct mapping to DB, for simple non message queue app, this is a good easy to follow/maintain approach For processing outside standard CRUD, I just use something like POST api/order/proceed-to-payment Since it is related to order, it is under api/order end-point, this way the next guy will have an easy time searching things Kindly explain what is difficult or downside of using this approach
@@rommellagera8543 yeah but why develop a CRUD API in the first place, I mean, why code it if you are just going to replicate the behavior of the next layer? Just put a software that already automatically maps that like Prisma or PostgREST and call it a day, you'll probably need another layer in front of it but why make it CRUDy again? I had a coworker that was in charge of creating a new version of a backend API, he knew the business really well but he didn't map the business logic to proper commands and queries, and just delegated another coworker to create a skeleton of a CRUD interface for each table. He missed the design part, so what happened later is that all tables and fields where exactly mapped to the endpoints and fields of the API, and because we had to start working in another stuff, the API rapidly started being polluted with unplanned endpoints and the CRUD endpoints just started to serve no purpose and begin growing in size with each requirement that it just made for a franken-CRUD-CQ like interface. He had the opportunity to make a good interface but he just followed the CRUD mentality and everything was fckdup quickly. What really blows my mind is that it was a GraphQL API and GraphQL already provides the separation between Commands(mutations in GQL) and Queries(well, this has the same name in GQL). I'm not saying CQRS is a silver bullet and CRUD serves no purpose, but please think carefully how you are going to design your API, most of the time there is no way to go back after clients start using the API
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"
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.
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.
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
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?
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...
As for me we need crud too. What about process: "manager create order with many mistakes". Describe how it work in our approach. Or what about fake order created by someone... Maybe we still need some crud api?
another end of the spectrum is full blown RPC with hundreds of methods to support each business process operation, which is also bad because it overwhelms clients with interface scale. as always truth is somewhere in between…
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.
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.
It would be great if you will extend your comment on Entity Service pattern. Some enterprise consulting companies promote "Entity Service API" concept or "API Led Conectivity" concept. They promise that move 3-layer Architecture (Presentation, Logic, Data) to API world (Experience API, Process API, System/Data API) is silver bullet idea. For me, it adds another technology layer with same coupling problems and spaghetti move from database to Entity Service APIs.
0:43 Actually a PUT request is an upsert operation. If the resource exists, it replaces it, otherwise it inserts it. This makes it different from a PATCH request when updating. A PUT request always carries the whole data of the resource since it may end up being an insert operation, while a PATCH request usually carries partial data since it only modifies a part of the resource. A PUT request will always succeed, while a PATCH request may fail if the resource does not exist.
I think I'm missing something, because to me it sounds like you're just describing a pub-sub system. Which if that's the case, yeah. But it's also like saying that a microwave isn't very good for cooking because it doesn't Cook steak very well. The problem isn't the microwave, the problem is trying to cook a steak in it
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???)
Not entirely get it, business processes come in many different terms, ways or path (different apps or UI): user/admin cancel shipment, user/admin amend shipment, add shipment, split shipment, shipment status change.... etc. At the end of the day, they translate to Create, Update or Delete.
So if I want to cancel a shipment in your API do I call DELETE /shipment/id or PATCH /shipment/id? You are forcing your service clients to know how a business operation maps to your database record. Maybe the business at first thought it was fine to remove the shipment record from the database immediately when shipment are canceled but later decided they would rather not delete it but mark it as canceled. Would have been better to encapsulate the concept in the first place with an API like /cancelshipment/id where clients don't have to know if this operation actually deletes or updates a record (and if an update, they don't need to know what status field on the record means canceled). This makes it obvious to service clients what business capabilities your service actually supports and encapsulates how it works so that internal changes don't ripple out to all clients.
@@stingray5 Ok thanks I understand it better now. Then lets say I have different kinds of cancel shipment with slightly different logics: Customer Cancel - update status to Cancel Staff Cancel - update status to Cancel Logistics Cancel - update status to "Not yet shipped" Manager Cancel - internal log and DELETE IT Cancel - IT audit log and DELETE Shall I create different endpoints and call UPDATE or DELETE inside the endpoint logic?
I think CRUD caught on because REST caught on, and REST caught on because HTTP won. All the HTTP verbs lend themselves to working on a certain resource, and these resources map pretty well to database objects.
I think I might be one of the few people who actually prefers the old SOAP APIs instead of REST APIs, but being able to define your own methods always made more sense to me than just having the CRUD actions of REST.
Entities can have status property which could easily control the flows for different shipment stages. A PUT is supposed to update or create (if record doesn't exist). So you could easily use PUT and control the flow with status.
They could but you are coupling your service clients to how you represent state in your database. What if shipments later become complex enough that "status" is better represented by several different fields on the shipment record. Now your clients have to change to account for this. It would have been better to have an API that represents what you are actually trying to do (like /cancelshipment) and let the service decide how to represent the underlying state change. This type of encapsulation allows your services to evolve independently.
CRUD is useful to learn when you're a beginner, but it's not how a good production server operates. The front-end should have flexibility on how it talks to the backend, establishing a good contract is important and it should be evolved from time to time.
It seems like a very important principal. Personally for me, an actual concrete example would be very helpful for understanding the idea and it's benefits
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 think you are addressing an archicetural problem and mix it up with an implementation technology. Your event driven solution can be fed by a crud api as well. I only agree with the fact that over time your api needs to change as the world changes around you. So what? Then change it. The api should not be written in stone…
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!
Meh. This is just about where the business logic is. If you are able to update your APIs and deploy quickly, then putting business processes in here is fine. If you cannot... Many non-tech businesses are trying to limit the need to involve programmers in business rules. CRUD APIs are merely a symptom of a problem of limited programmer resources.
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
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
Second this.
i don't think it's refactoring, it's adding a domain layer and hiding the CRUD access behind a repository
💯. 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.
Dont forget about domain. You might create a shipment if youre a logistics company.
What type of perspective is that. "I got order" , "ship it". Nothing more nothing less. What do you need a system for, with that perspective. 😂
@@glhays6832 Think about the domain of a shipping or freight company. Off the top of my head- You might pack a single container with one or more orders from one or more customers. Or a situation where a shipment could consist of many containers that need to be tracked individually AND collectively.
You highlight a thing that Derek talks about again and again: Developers being data-centric, rather than behavior centric. Or technology-centric. And that divorces the code solution from the reality and how users look at the domain.
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
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.
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!!
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'.
Dude I just found out that this is exactly one of those problems i facing with an app we have.
Pushing business logic into the UI seems like a very bad idea. What if there are more than just one client.
What would an API example look like in these cases?
I've been learning and exposed to CRUD apps since day 1, and this opens a new horizon for me.
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.
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?
Your DB or ORM already implements the CRUD interface, what I've found while working is that sometimes REST APIs act just like proxies to a DB, there is little to no logic in the app and is mostly plagued of conversions between HTTP to the DB driver or ORM, and because of this basically all the logic is spread but mostly living in the UI.
When using something like CQRS you create a proper interface for your business and internally you call all the CRUDy like interfaces.
In Spanish CRUD sounds similar to the word "crudo" which means "raw" and that is basically the idea I have about CRUD in my mind. They are just raw interfaces which you need to compose to build your business interfaces. Don't expose raw interfaces directly to your clients.
@ArcRCG that's the point of CRUD API, direct mapping to DB, for simple non message queue app, this is a good easy to follow/maintain approach
For processing outside standard CRUD, I just use something like POST api/order/proceed-to-payment
Since it is related to order, it is under api/order end-point, this way the next guy will have an easy time searching things
Kindly explain what is difficult or downside of using this approach
@@rommellagera8543 yeah but why develop a CRUD API in the first place, I mean, why code it if you are just going to replicate the behavior of the next layer? Just put a software that already automatically maps that like Prisma or PostgREST and call it a day, you'll probably need another layer in front of it but why make it CRUDy again?
I had a coworker that was in charge of creating a new version of a backend API, he knew the business really well but he didn't map the business logic to proper commands and queries, and just delegated another coworker to create a skeleton of a CRUD interface for each table. He missed the design part, so what happened later is that all tables and fields where exactly mapped to the endpoints and fields of the API, and because we had to start working in another stuff, the API rapidly started being polluted with unplanned endpoints and the CRUD endpoints just started to serve no purpose and begin growing in size with each requirement that it just made for a franken-CRUD-CQ like interface. He had the opportunity to make a good interface but he just followed the CRUD mentality and everything was fckdup quickly.
What really blows my mind is that it was a GraphQL API and GraphQL already provides the separation between Commands(mutations in GQL) and Queries(well, this has the same name in GQL).
I'm not saying CQRS is a silver bullet and CRUD serves no purpose, but please think carefully how you are going to design your API, most of the time there is no way to go back after clients start using the API
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
I think CRUD is so prevalent because the first thing a lot of developers are taught to make is a TODO list app.
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.
What does your API look like with CQRS? Action endpoints, like /api/createUser?
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.
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
RPC gets a bad name and I don't really think of it as RPC so much really.
Need an end to end example
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?
Yes good suggestion, I will!
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...
As for me we need crud too. What about process: "manager create order with many mistakes". Describe how it work in our approach. Or what about fake order created by someone... Maybe we still need some crud api?
another end of the spectrum is full blown RPC with hundreds of methods to support each business process operation, which is also bad because it overwhelms clients with interface scale. as always truth is somewhere in between…
namespaces my friend
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.
Isn't it supposed to have another layer ? Another layer above the crud layer ?
As a CRM engineer for a logistics company, this is interesting.
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.
It would be great if you will extend your comment on Entity Service pattern. Some enterprise consulting companies promote "Entity Service API" concept or "API Led Conectivity" concept.
They promise that move 3-layer Architecture (Presentation, Logic, Data) to API world (Experience API, Process API, System/Data API) is silver bullet idea.
For me, it adds another technology layer with same coupling problems and spaghetti move from database to Entity Service APIs.
Ruby on Rails with it's Active Record ORM advocated this more than anything else.
0:43 Actually a PUT request is an upsert operation. If the resource exists, it replaces it, otherwise it inserts it. This makes it different from a PATCH request when updating. A PUT request always carries the whole data of the resource since it may end up being an insert operation, while a PATCH request usually carries partial data since it only modifies a part of the resource. A PUT request will always succeed, while a PATCH request may fail if the resource does not exist.
This has nothing to do with the video.
I think I'm missing something, because to me it sounds like you're just describing a pub-sub system. Which if that's the case, yeah. But it's also like saying that a microwave isn't very good for cooking because it doesn't Cook steak very well. The problem isn't the microwave, the problem is trying to cook a steak in it
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???)
Not entirely get it, business processes come in many different terms, ways or path (different apps or UI):
user/admin cancel shipment, user/admin amend shipment, add shipment, split shipment, shipment status change.... etc.
At the end of the day, they translate to Create, Update or Delete.
So if I want to cancel a shipment in your API do I call DELETE /shipment/id or PATCH /shipment/id? You are forcing your service clients to know how a business operation maps to your database record. Maybe the business at first thought it was fine to remove the shipment record from the database immediately when shipment are canceled but later decided they would rather not delete it but mark it as canceled. Would have been better to encapsulate the concept in the first place with an API like /cancelshipment/id where clients don't have to know if this operation actually deletes or updates a record (and if an update, they don't need to know what status field on the record means canceled). This makes it obvious to service clients what business capabilities your service actually supports and encapsulates how it works so that internal changes don't ripple out to all clients.
@@stingray5 Ok thanks I understand it better now. Then lets say I have different kinds of cancel shipment with slightly different logics:
Customer Cancel - update status to Cancel
Staff Cancel - update status to Cancel
Logistics Cancel - update status to "Not yet shipped"
Manager Cancel - internal log and DELETE
IT Cancel - IT audit log and DELETE
Shall I create different endpoints and call UPDATE or DELETE inside the endpoint logic?
I think CRUD caught on because REST caught on, and REST caught on because HTTP won. All the HTTP verbs lend themselves to working on a certain resource, and these resources map pretty well to database objects.
I think I might be one of the few people who actually prefers the old SOAP APIs instead of REST APIs, but being able to define your own methods always made more sense to me than just having the CRUD actions of REST.
Entities can have status property which could easily control the flows for different shipment stages. A PUT is supposed to update or create (if record doesn't exist). So you could easily use PUT and control the flow with status.
They could but you are coupling your service clients to how you represent state in your database. What if shipments later become complex enough that "status" is better represented by several different fields on the shipment record. Now your clients have to change to account for this. It would have been better to have an API that represents what you are actually trying to do (like /cancelshipment) and let the service decide how to represent the underlying state change. This type of encapsulation allows your services to evolve independently.
CRUD is useful to learn when you're a beginner, but it's not how a good production server operates.
The front-end should have flexibility on how it talks to the backend, establishing a good contract is important and it should be evolved from time to time.
It seems like a very important principal. Personally for me, an actual concrete example would be very helpful for understanding the idea and it's benefits
In OO, this is where a bridge pattern shines.
i have a hard time modeling this
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.
Big fan of all your videos!
Thanks!
I think you are addressing an archicetural problem and mix it up with an implementation technology. Your event driven solution can be fed by a crud api as well. I only agree with the fact that over time your api needs to change as the world changes around you. So what? Then change it. The api should not be written in stone…
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.
It depends. And people are lazy to think and shied away from making crucial decisions. Cover-my-assssssets strategy implemented from top to bottom.
one of the best videos
Yes yes this is the quintessential issue with some systems!
i like crud.
Yesssir! Wholeheartedly agreed.
this video really opened my eyes lol
Absolutely can relate!
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!
Yea..much talk but little example
lol what?
lol what?
Meh. This is just about where the business logic is. If you are able to update your APIs and deploy quickly, then putting business processes in here is fine. If you cannot... Many non-tech businesses are trying to limit the need to involve programmers in business rules. CRUD APIs are merely a symptom of a problem of limited programmer resources.