CRUD API + Complexity = Death by a 1000 Papercuts

[@FlaviusAspra]

Takeaway: change your mindset from technically-oriented to business-oriented to figure out use cases. Naming those use cases is what it boils down to. I think programmers are just too focused on tooling like frameworks or ORMs instead on pure coding of the domain model without any framework or tool. This kind of thinking (crud) twists ones mind in strange ways. How to force yourself: make different compilation units, assemblies, jars, dlls, etc. And then watch your dependencies, be strict about them. The single most important rule: your domain model is not allowed to depend on anything but itself - no framework, no library, nothing, just pure business rules as code.

[@CodeOpinion]

That is a lot of the inspiration of this channel is to put focus on things other than purely technical concerns such as frameworks/libraries/etc. I do show them and various patterns but I try to do it in relation to the problem they solve.

[@MarkDeibert]

This is super smart. Really got me thinking about my app

[@yobofunk5689]

I may be missing the point. But the closer I worked with crud, was by using a 3rd party wsdl soap file, hence nothing should be touch in this entity file and it became sacred (potential update). Then the way was to work with "responses" in a "modelview", which seems here to be the entity. Then it's death by hammer with toEntity/fromEntity with a potential level of check here too.

[@wenas5]

My man always spiting bars. I fell for that trend along with REST APIs. Let's crud this, I can create the endpoints to manage that table with just some commands!! I quickly realized that If mapping tables to endpoints were enough we would be sending excel sheets back and forth (don't let management know)

[@CodeOpinion]

I'd say that most apps that are based in CRUD aren't much better than spreadsheet.

[@alansinoracki8508]

Sending Excel sheets back and forth. Oh i love it, some clients would propably love that as well.

[@mohamedsalman3205]

Thank you for this. Your contents have made me a better software engineer. I only wish there is a way for me to get the code that you are demoing.

[@kunaljoshi8038]

His code is available for his Patreon subs i think

[@marna_li]

You can join his KZbin channel as a paying member, as I did. He will then post the links afterwards.

[@herrjohanh]

Great demo! 👏 Small and short examples like this really gets the point across I think.

[@CodeOpinion]

Glad you liked it!

[@evilroxxx]

Your example shows checking domain logic directly at the controller action level. Probably because you’re sending the actual domain model in and out as request and response. However how do you think is the best way to handle this if you’re going through layers of request, dto, service and then do all domain models? Where should this logic be handled? Every level or few levels downstream or still at the domain model? And if at the domain model how do you communicate that info back to the client?

[@evilroxxx]

Also would appreciate if you actually walked us through one of those scenarios of product availability or adjustment like what changes the api route goes through, how do you still keep route name restful, what http method to choose, input request params, output response params and jsons, and finally what actually occurs inside the action to for it to return the appropriate response.

[@evilroxxx]

Lastly it would also help to know which business logic should be handle entirely on the client side, entirely on the server side and when to write logic in both

[@Rick-mf3gh]

@@evilroxxx All necessary validation *must* be done on the server side - we must keep the system's data valid. You can then also design the UI to head off any validation errors by doing checks on the client side and showing the user helpful validation messages while they are inputting the data. Yes, it is duplication of validation, but we must protect the system's data from bad data sent by the client.

[@lost-prototype]

I keep getting such good videos of yours suggested to me. Coworker of mine is learning C#, been sharing your videos a lot with him.

[@CodeOpinion]

Thanks for sharing! Hopefully they are helpful.

[@lost-prototype]

@@CodeOpinion Very much so. A lot of your stuff is affirming for things I've known or done for a bit now, but there are often little gaps I can fill in by seeing someone else in practice. What I would give to bump into you at a conference and talk architecture...

[@CodeOpinion]

Hopefully again soon enough back at conferences.

[@AdGerrits]

Excellent explanation why CRUD is not a silver but a bronze bullet.

[@br3nto]

It’s all in the name really. Representational state transfer. The common misconception about RESTful APIs is that resources map to entities/models. They can, but that’s a subset. The best REST API examples are like the one you just gave. Another would be updating an address where the change might be a correction or moving location, the RESTful resource is the address history.

[@vindecode5837]

Thank you for sharing your knowledge, these really helps us juniors/mid level developers the thought process about this.

[@CodeOpinion]

Glad it was helpful!

[@hernandosierra8759]

Thank you and happy new year.

[@romanlunin386]

well that's a pretty good example, though I have to admit that you changed the UI to match your business logic, but in practice it works the other way - you'are working in a project where you have to implement a feature approved by UI/UX team, most likely they would provide you with the design similar to the one you started with, other than that the first option is closer to what people used to see all over the internet today. but thanks for the video, this channel is underestimated, I wish more people watch it.

[@marcoandretta5366]

Amazing, i'm thinking of subscribing to your channel because your videos are very helpfull. I've been a developer for one year and in the project I've done instead of the controllers, the logic ended up fragmented between a service that use EF core and blazor components. Then you have to add another project maybe a phone app and now what? I've tried extracting the business logic in yet another service that is shared but it seems hacky and keeps adding more indirection. Throwing custom exceptions and try catching them in order to show the user a more helpfull error is expensive, so you just return true or false and log what happened. If I'm guessing correctly you would put the business logic /behaviours in entities (isn't that the point of OOP, why have the model anemic?) in projects that are still kinda small but then switch to clean architecture where you have business objects separated from entities for more complex scenarios?

[@yossiyaari3760]

Interesting. One note: I find that keeping the data stupid, and moving the functionality out to logic classes. This will allow different behaviors for the same data type, in different scenrios, such as users with different permissions/roles, or at different stages.

[@CodeOpinion]

In OO (C# version) land I generally find core logical code to be more about encapsulating data. On the outer edge it's more procedural.

[@rafaelcascalho4180]

Great vídeo! Although, I have a question: considering that the entrity is the abstraction of all those files and methods, I'm more used to the idea of a single controller class, and calling the entity as services (functions or classes), therefore is quite strange for me to throw or return errors such as BadRequest from there. Am I missing something here or am I getting it wrong?

[@br3nto]

Controller actions just map exceptions or errors or data to an appropriate response format. How you do that is up to you. But the domain model you use should be designed in a way that the public api layer could also be something other than an html api. Eg if you provided three methods of accessing your domain model, REST api, gRPC, and CLI, each of those will likely use a common internal api for your domain model and then maintain the responses of the internal api to the response required.

[@tomheijtink8688]

Just as it is often a misconception to map crud to http methods. It’s also a misconception to map errors, warnings and result to http status codes. Http status codes only say something regarding the http communication itself. Not the business logic. Sure there are some codes which can easily be mapped when a entity can’t be found based on a route value. Or a json property not matching the dto contract. But if all else goes fine, you should return an ok. Even when the business code wouldn’t allow you to perform certain actions. Just return a result model in a 200 result explaining what went wrong.

[@xoca7171]

Very informative! Thank you

[@jesusantoniomartinezhernan2791]

Wow, your content is amazing. Im really convinced that ddd really works, but, in mi country, a few of people implements good practice, and little less, does ddd. Thanks for your videos.

[@CodeOpinion]

DDD isn't for everything. CRUD has it's place but for things that are generally more in a supporting role than the core domain. If you have complexity and the core of your domain, DDD is a good solution.

[@Scratchmex]

How do you overcome the fact tha now the front-end will need more JavaScript than the crud approach that could be only post forms? I sometimes go with the crud approach only because it makes it easier to not use JavaScript on the front-end and to avoid managing state in it. Thanks

[@CodeOpinion]

Depends how your building the responses. There are a lot of options, take a look at htmx for example

[@ramonennik2536]

I have a question. How would you implement this but keeping the existing crud put/post request bodies intact to be backward compatible? Would you make some class in between which determines which commands to send based on what fields are changed? And what should it be called? I'm asking because i'm working on a very large api which is used by many customers and I can't change it any time soon but I can already rework the backend code.

[@CodeOpinion]

You can try to infer it, depending what it is so you can break things apart.

[@JOHNDATGOONV2]

Could you make a video on Hosted Blazor WASM project architecture?

[@CodeOpinion]

Possibly, I'll add it to my list of topic ideas. Thanks for the comment!

[@jbeaudoin11]

Been bashing my head all day on an upsert endpoint.. Legit searched "crud api sucks" and that video came up.. Thanks to confirm I'm not alone in this

[@CodeOpinion]

Confirmed 👍

[@jbeaudoin11]

​@@CodeOpinion Do you have a good standard for building none CRUD apis ? I've started to implement my own but i would much rather have a standard. I've looked at JSON:API, JSON hyperschema and a couple others but they don't seem to be official standards and don't look all that great. The best one so far seems to be HAL and HAL-FORMS but im not 100% convinced. I somewhat like what Stripe built, but it does feel a little too CRUD for me.. Might be a good compromise idk.

[@sirg7573]

Good video! Isn't this very similar to "Task Based UIs" that you described in an earlier video here: kzbin.info/www/bejne/epu9lqONp6Z-sK8 Just trying to understand the difference. This applies the same philosophy to the API rather than the UI, right?

[@CodeOpinion]

Yes! Just tackling the topic from a different perspective.

[@MdAshiquzzaman]

Thank you for your great video.

[@marna_li]

I like the idea of putting logic in your entities/models, actions and validation. To some it is horror, depending on where they come from. But with every design decision you have to think of the consequences. It might not work well in every project. There is not just one right way to design a system. You sure have told us that. Btw. Entity Framework is a great framework for modelling a domain and abstracting away storage concerns. You should not think about storing and retrieving data from a database, the actual details should be hidden. It seems like a beginner thing to not understand abstractions in code.

[@CodeOpinion]

CRUD works on the fringe or outer edge for supporting boundaries that are generally used for more referential to the core domain. Once you get into the heart of the domain however, this is where complexities lies and how you attempt to model and manage it. If you think of the core as purely technical (CRUD) while that can work, you're leaving a lot on the table (and peoples minds) and you aren't overly different than running everything in spreadsheets.

[@m1dway]

I think one of the great use case for CRUD is something like update address, update names, and something similar to that. Other than that you have to think carefully on what you are doing

[@CodeOpinion]

@@m1dway Actually this is a great example of why context matters. If you were building a system for postal/mail, a change of address isn't just CRUD. It's something very specific that has implications like mail forwarding etc. In one context it may be a supporting role and CRUD is fine, in others, as I'm pointing out here, CRUD isn't at all what you want.

[@marna_li]

@@CodeOpinion I was first introduced to CRUD about 10 years ago. Then it was the new ideal having Web APIs and CRUD operations. I never really came about to seriously use it. But now I know how limiting it is. Somehow I used to think that not following the ideal (CRUD) was bad. It shows your other point from earlier, a HTTP Post does not have to mean that you are pushing an entity. To the one who is used to certain ideas, these are radical but useful changes when thinking of capabilities. In a way, capabilities is more like procedural programming - dividing logic around one or many domain entities into procedures at a system-level, each with a specific purpose. But I think that, if you as a developer regard your evolving and eventually complex programs as input output operations mapping to a database, then you are limited. You have to learn patterns and abstractions to handle that complexity, or else you inevitably end up with technical debt much sooner. I’ve seen that when inexperienced programmers have taken on such big projects. One project was written in PHP, using a web framework with its own ORM. CRUD ofc. It had to do network configuration for devices, so it was put into the “CRUD” events of the actual entity models. Always having been a .NET developer so I have always learned about separating the concerns. I was into MVVM and “services” back then. So I questioned it. But frameworks are different. Anyway, end of rant 🙂

[@thatoneuser8600]

@@marna_li what is your quick list of the top 3 books that most influenced your way of thinking about architecture or codebase maintainability?

[@FilthySnob]

I dont get it lol the alternative is still crud but with improved UX, what did i miss?

[@CodeOpinion]

CRUD is generally about creating and updating an entire entity (and more) in a single request. There is not intent defined and code isn't explicit in any way.

[@stanislauyan3204]

There is other way - do it at Frontend. Users hate the interface you represented. Making validations is better for users, but makes duplication of validations.

[@singernooneheard6967]

If we dont do CRUD are we still restful?

[@CodeOpinion]

CRUD and being restful are totally different things.

[@Mixesha001]

Discovered your channel today. I regret not finding it before. Nice content, keep it up. Sub +1

[@CodeOpinion]

Thanks 👍

[@adambickford8720]

Model your business, not your database.

[@CodeOpinion]

👍

[@mabdullahsari]

Just use Excel in the first example, lol. Such a waste of potential. People generally pay money to solve specific problems they're facing, not to implement an Excel sheet in a web interface.

[@LeviRamsey]

Smart UI is something of an antipattern.