Yes, buuut: If your interface is exactly used by one class, ever, what difference does it make? You have one unecessary file, which clutters things and makes readability worse.
0:00 Intro 1:27 Making everything public 4:48 Field dependency injection 7:19 Interface when it’s not needed 10:33 Improper REST API design 13:40 Improper exception handling
Thanks for the great video. Please continue the posting about common mistakes and best practices. About the interfaces, some architectures (e.g. ports and adapters) require (recommend) the definition of interfaces though, even if they are implemented only once.
Pretty good video. I am a pretty stubborn developper and I don't usually implement things that do not improve that much on my coding time or make my code easier to understand. I am with you for theses 3 : - REST API recommendations should be followed. - Using constructor based dependency injection is BAE - Custom exceptions should always be implemented. I usually use a Controller Advisor to map my exceptions to Http Responses so that i can still you the Java exceptions and then transform the message into the body of a 4xx error code depending on the exception. - Using interfaces when you really need them (50/50) -> if you are doing more than CRUD transactions interfaces are a good way to show what methods you have implemented instead of reading all the code to find out. Not really with you on this: - For the way to structure your code (you should chose package by layer or package by feature depending on the project)
I'll engage with you. Could you elaborate on your using interfaces point? What's the problem that an interface solves in your example? And why do you disagree with package by layer or package by feature? Do you usually organize your code another way?
You're right. I've never made a mistake, but now if I do, I'll check back here for help. Thanks man. You put out consistently helpful tech content. I recently inherited a Spring project and I have a lot to learn.
My opinion is that it is wrong for the TodoFiveRepository to throw an exception (even a custom one), but instead, return an Optional. Reason being that it is not the repository's responsibility to determine whether this is an exceptional case or an expected scenario. Instead, it is the caller of the repository (direct or indirect) to figure out that, depending upon the scenario. Exceptions are to be used for exceptional cases, not for expected functional behavior. The repository should only throw an exception when there's a problem accessing the database.
#3 I always thought it was right to use interfaces, but there's nothing right or wrong with that, personal habits? I agree with your point. Using interfaces without multiple implementations wastes time.
To me number one is a design choice, having all the controllers in the controller package allows the developer to go straight to the package whereas creating packages based on functions lends itself to being able to pull that function out and turn it into a micro service with a lot less hassle. However, you will still end up having some common code in something like a utils package that all or most of the functions leverage it. Number five is an improper use of exceptions in that just because a piece of data wasnt found doesnt constitute something exceptional. It would be better to return an Optional and let the calling class figure out what to do. I believe its good practice to avoid throwing exceptions as much as possible because unwinding them and dealing with them slows down processing and Ive seen in high throughput applications where milliseconds count that less "throws" makes a difference.
Agree with you on both points. Just because java doesn't have extended ability of hiding classes between packages doesn't mean you should design as such. Having controllers in the same package as the service/models/repo doesn't make design sense to me. Second point is dependent on convention: in the old days of ejb getXXX would throw exceptions whereas findXXX would not. In the end, most usage will use the find approach since it should be left up to the caller to decide on what to do. Throwing the exception here makes no sense to me. It is not exceptional.
very useful, i think some of those mistakes are more general and not just to spring, be restful, excepcion hanlder, and everything is public is more about encapsulation in object oriented
I really love the functional way to throw errors, we at our company we use a functional way to do Try and catch, which makes it readable and clean, we also dont throw an error if its needed by the user, we use a type Either and then return to left part which we defined an error with msg etc... we use Vavr for handling things with FP
I agree with most ..a few points of refinement id make though..if you are writing published spring libs that are used elsewhere I would lean in favor of always providing interfaces or coding to a contract. I really didn't quite understand the point of arranging code in packages as prescribed although this isn't the first time I've seen this idea... I've never really seen a realistic advantage and if you are doing microservices and have so many different domains that your crossing wires and it's confusing perhaps you've misdrawn your context boundaries ? I like this series though and to add to common errors ...I have often come into projects that don't properly use http status codes , a good.example is rest calls that return 200 with an error payload you need to check for..yuck but I see it consistently. Exposing dB entities directly and not using dtos is another..and on that note manual mapping between the entity/dto layers when great tools exist for this. Another common mistake I see frequently is manual validation and not fully understanding the power of spring validation... Prob a dozen others but ...cheers I look forward to your next installment!
Hello Dan Vega, thank you amazing video! REST API standard has a lot of problem on developers. We see in corporate projects also. When I describe the problem people does not care. API should be standard and have rules, but people always trying to use method names. Resources seperated by rest api architecture principle but they are accessing via different resources. Also on the courses trainers they using method names in order to explain better. But developers think about it is correct. API structure is needed trained as an course and we need to focus like clean code. Clean API is success of work. Could you please provide the best practices in a video? Perhaps this could be make a recognition on training , tutorial videos.
I'm so proud this video wasn't useful to me. I'm still not a junior, but I've had 2 internships. This is how I do stuff. But all of the bad examples show how I did things at some point in the past two years during my learning path
A previous tech lead I had disagrees on the useless-interface mistake. They believe it's good pattern to ALWAYS have an interface and an impl for everything. I don't see any value on that if there's never going to be alternative implementations.
Hi Dan, I recently came across an article highlighting Java vulnerabilities. In light of this, I believe it would be beneficial to create a playlist outlining the steps for: (1) Upgrading to the latest version of Java (2) Updating JAR files (3) Transitioning to the most recent dependencies. This playlist would serve as a valuable resource for us, subscribers, to proactively address potential security risks associated with outdated Java environments. Would you be available to create such a playlist? Thanks in advance.
What so interesting in case of mistake 3 Intellij in case of lone class implementation with only one method will suggest to make an interface from it :) This is the example, that actually not all the time IDE is suggesting the right thing :)
Making everything package private and then putting into Spring context is not a great example of "don't make everything public". If something is in the context then it's available anywhere anyway...
Great video. There is something I changed recently, because I believe it is a better approach, according to Clean Architecture. Instead of making conversions between DTOs and Entities classes in the controller, I started creating a mapper in an isolated package and letting the services layer request these conversions. What do you think of the idea?
I put the conversions in the DTOs themselves, as they've got the data and it makes testing easy. According to Clean or Hexagonal architecture, the service layer should not be aware of those DTOs.
@@JitterTed Thanks for commenting. I'm not sure if I understood your suggestion correctly, but who asks to convert the DTOs? Is it the controllers or services layer?
@@pedrolobo9835The Controllers obtain (Domain) Objects from the Service layer, and then ask the DTO to convert them to the DTOs. This way the Service layer doesn't have to conform to any particular Controller's needs (it supplies Domain Objects). Typically I have DTOs specific to a Controller (or set of related Controllers).
Dan, Thank for sharning! In exception handling, what if we have the controller, service, and repository. Where would be the best place to handle the exception? What would you recommend? Controller or service? My throught is controller though.
thanks, now I know my mistakes :D In my org I also see a lot of circular dependencies, all done through field autowiring. Could you explain if it is the correct way? should we avoid it?
Isnt patch usually the one used to update resources and put the one to add? And post usually for non-standard/more complex operations (e.g. triggering an sms)?
Great video that tells me that I'm on the right track, but I have a doubt about point 1. By using private classes and having everything in the same package (something that is done a lot in spring projects) if we talk about feature architecture. Wouldn't it be a disadvantage in this case? Since we would surely have a shared domain between all the features and would we break with this encapsulation? What do you think or what alternative do you use for these cases?
Hi Dan, what is your opinion about putting business logic in config files like application yaml to make it extensible. Recently there was a requirement where data had to be filtered based on some fields and these fields could change in future. Someone suggested to put them in configuration files to make it future proof.
Mistake 6 improper medieatype or missing mediatype. All rest controllers should produce json mediatype and consume it for post/update/patch. There are clever hacks that use improper media type handling.
unnecessary interfaces we see in the corporate projects everywhere, sometimes people does not put methods too. because they learned by rote. I am disagree and removing when I see. delete like a butcher!
What about the "Resource Oriented design principle" used for designing the REST endpoints? It says that the endpoints should be named after the resources that they are dealing with. But when we are dealing with multiple resources, it says we should use nested endpoints following the resource hierarchy? Is it necessary to follow these?
thanks! writing interfaces, which are never used are waste of time. good to hear this from an experienced spring developer.
But using interfaces also hides the implementation details, right? The caller can use the functionality without caring about the details.
Yes, buuut: If your interface is exactly used by one class, ever, what difference does it make? You have one unecessary file, which clutters things and makes readability worse.
0:00 Intro
1:27 Making everything public
4:48 Field dependency injection
7:19 Interface when it’s not needed
10:33 Improper REST API design
13:40 Improper exception handling
Thanks for the great video. Please continue the posting about common mistakes and best practices. About the interfaces, some architectures (e.g. ports and adapters) require (recommend) the definition of interfaces though, even if they are implemented only once.
Can't wait for exception handling video. It has has always been bit of a mystery to me :) Or more like what is the proper way of doing it.
This was great. #2 and #3 are what was drilled into years ago and ive never questioned them.
Pretty good video.
I am a pretty stubborn developper and I don't usually implement things that do not improve that much on my coding time or make my code easier to understand.
I am with you for theses 3 :
- REST API recommendations should be followed.
- Using constructor based dependency injection is BAE
- Custom exceptions should always be implemented. I usually use a Controller Advisor to map my exceptions to Http Responses so that i can still you the Java exceptions and then transform the message into the body of a 4xx error code depending on the exception.
- Using interfaces when you really need them (50/50) -> if you are doing more than CRUD transactions interfaces are a good way to show what methods you have implemented instead of reading all the code to find out.
Not really with you on this:
- For the way to structure your code (you should chose package by layer or package by feature depending on the project)
I'll engage with you. Could you elaborate on your using interfaces point? What's the problem that an interface solves in your example? And why do you disagree with package by layer or package by feature? Do you usually organize your code another way?
It would be amazing to see something similar for spring data jpa
I think using JPA when you don't need the complexity is a mistake. 😄
Thank you for the interesting video, and number 6: not dropping by the Spring office hours.
Ohh that’s a good one haha 😂
Amazing Tutorial Dan! As someone who is exploring Spring, this was a great learning
thank you first all, it worth also to mention that using controllerAdvice we can handle the exceptions also much better in spring
Thanks for creating this video Dan. Looking forward to more additions on the common mistakes series. Cheers!
Dan, thanks for sharing. I hope you will make this a series and add more "mistakes" to the repository and RUclips
You're right. I've never made a mistake, but now if I do, I'll check back here for help. Thanks man. You put out consistently helpful tech content. I recently inherited a Spring project and I have a lot to learn.
as always, thanks for this Dan! You're helping beginners like me in a massive way.
My opinion is that it is wrong for the TodoFiveRepository to throw an exception (even a custom one), but instead, return an Optional. Reason being that it is not the repository's responsibility to determine whether this is an exceptional case or an expected scenario. Instead, it is the caller of the repository (direct or indirect) to figure out that, depending upon the scenario. Exceptions are to be used for exceptional cases, not for expected functional behavior. The repository should only throw an exception when there's a problem accessing the database.
Definitely! Use Optional instead of throwing exception for missing entity.
#1 is going to be problematic in the long run IMO. Agree with you about all others!
This is great, ... Keep them coming
Very good basic points made here. Clear and concise. Dan delivers 😊
Thank you Dan. Very insightful.
Keep sharing good practices about coding with Spring.
#3 I always thought it was right to use interfaces, but there's nothing right or wrong with that, personal habits? I agree with your point. Using interfaces without multiple implementations wastes time.
But using interfaces also hides the implementation details, right? The caller can use the functionality without caring about the details.
To me number one is a design choice, having all the controllers in the controller package allows the developer to go straight to the package whereas creating packages based on functions lends itself to being able to pull that function out and turn it into a micro service with a lot less hassle. However, you will still end up having some common code in something like a utils package that all or most of the functions leverage it.
Number five is an improper use of exceptions in that just because a piece of data wasnt found doesnt constitute something exceptional. It would be better to return an Optional and let the calling class figure out what to do. I believe its good practice to avoid throwing exceptions as much as possible because unwinding them and dealing with them slows down processing and Ive seen in high throughput applications where milliseconds count that less "throws" makes a difference.
Agree with you on both points. Just because java doesn't have extended ability of hiding classes between packages doesn't mean you should design as such. Having controllers in the same package as the service/models/repo doesn't make design sense to me. Second point is dependent on convention: in the old days of ejb getXXX would throw exceptions whereas findXXX would not. In the end, most usage will use the find approach since it should be left up to the caller to decide on what to do. Throwing the exception here makes no sense to me. It is not exceptional.
very useful, i think some of those mistakes are more general and not just to spring, be restful, excepcion hanlder, and everything is public is more about encapsulation in object oriented
I really love the functional way to throw errors, we at our company we use a functional way to do Try and catch, which makes it readable and clean, we also dont throw an error if its needed by the user, we use a type Either and then return to left part which we defined an error with msg etc... we use Vavr for handling things with FP
Great video. Thanks
Please continue along these line of topics!
Kindly continue this series.
Great video, thanks Dan! Looking forward to the exception video!
of course, it is sounds like very good series
I agree with most ..a few points of refinement id make though..if you are writing published spring libs that are used elsewhere I would lean in favor of always providing interfaces or coding to a contract.
I really didn't quite understand the point of arranging code in packages as prescribed although this isn't the first time I've seen this idea... I've never really seen a realistic advantage and if you are doing microservices and have so many different domains that your crossing wires and it's confusing perhaps you've misdrawn your context boundaries ?
I like this series though and to add to common errors ...I have often come into projects that don't properly use http status codes , a good.example is rest calls that return 200 with an error payload you need to check for..yuck but I see it consistently.
Exposing dB entities directly and not using dtos is another..and on that note manual mapping between the entity/dto layers when great tools exist for this.
Another common mistake I see frequently is manual validation and not fully understanding the power of spring validation...
Prob a dozen others but ...cheers I look forward to your next installment!
Actually none of them are mistakes. I would call them tips and they are great. Thanks!
Hello Dan Vega, thank you amazing video! REST API standard has a lot of problem on developers. We see in corporate projects also. When I describe the problem people does not care. API should be standard and have rules, but people always trying to use method names. Resources seperated by rest api architecture principle but they are accessing via different resources. Also on the courses trainers they using method names in order to explain better. But developers think about it is correct. API structure is needed trained as an course and we need to focus like clean code. Clean API is success of work. Could you please provide the best practices in a video? Perhaps this could be make a recognition on training , tutorial videos.
Learned some good stuff
Looking forward to a video about @Transactional annotation and common mistakes while using it.
I'm so proud this video wasn't useful to me. I'm still not a junior, but I've had 2 internships. This is how I do stuff.
But all of the bad examples show how I did things at some point in the past two years during my learning path
In Mistake #1, how to write unit tests if service layer is private ?
Do we expect to keep Unit test code in same package?
A previous tech lead I had disagrees on the useless-interface mistake. They believe it's good pattern to ALWAYS have an interface and an impl for everything. I don't see any value on that if there's never going to be alternative implementations.
good topic and easy explanation
in last example. better to just return optional from repository. And then throw exception from controller.
Great tips @DanVega regarding handling errors video you mentioned at 13:40, is that one already published? tnx
Hi Dan, I recently came across an article highlighting Java vulnerabilities. In light of this, I believe it would be beneficial to create a playlist outlining the steps for: (1) Upgrading to the latest version of Java (2) Updating JAR files (3) Transitioning to the most recent dependencies. This playlist would serve as a valuable resource for us, subscribers, to proactively address potential security risks associated with outdated Java environments. Would you be available to create such a playlist? Thanks in advance.
What so interesting in case of mistake 3 Intellij in case of lone class implementation with only one method will suggest to make an interface from it :) This is the example, that actually not all the time IDE is suggesting the right thing :)
please we need more
Thanks for good examples
learned a lot, thanks Dan
great content thank u
thanks!!! please continue!!!
Hi Dan, please add hexagonal architecture video
Very useful content!
Thanks!!
i love the feature package organization idea, can you make a video on it?
So in a package by feature approach, where do you put, for example, your Utility classes? Example DateTimeUtil. Since its not a part of any feature
As per Interface usage, what about unit testing? How do we test a service if we cannot decouple its dependency via using Interfaces?
Making everything package private and then putting into Spring context is not a great example of "don't make everything public". If something is in the context then it's available anywhere anyway...
feature based is good but still require public , moslty need to talk to different package, very rare package is restricted not needed to talk
Great video.
There is something I changed recently, because I believe it is a better approach, according to Clean Architecture. Instead of making conversions between DTOs and Entities classes in the controller, I started creating a mapper in an isolated package and letting the services layer request these conversions. What do you think of the idea?
I put the conversions in the DTOs themselves, as they've got the data and it makes testing easy. According to Clean or Hexagonal architecture, the service layer should not be aware of those DTOs.
@@JitterTed Thanks for commenting. I'm not sure if I understood your suggestion correctly, but who asks to convert the DTOs? Is it the controllers or services layer?
@@pedrolobo9835The Controllers obtain (Domain) Objects from the Service layer, and then ask the DTO to convert them to the DTOs. This way the Service layer doesn't have to conform to any particular Controller's needs (it supplies Domain Objects). Typically I have DTOs specific to a Controller (or set of related Controllers).
@@JitterTed OK. Thanks for that! =)
Thanks!
Wow thank you so much for your generosity. I appreciate you 🤩
@@DanVega np. what intellij theme did you use for the demo?
Dan, Thank for sharning!
In exception handling, what if we have the controller, service, and repository. Where would be the best place to handle the exception? What would you recommend?
Controller or service? My throught is controller though.
thanks, now I know my mistakes :D
In my org I also see a lot of circular dependencies, all done through field autowiring. Could you explain if it is the correct way? should we avoid it?
Isnt patch usually the one used to update resources and put the one to add? And post usually for non-standard/more complex operations (e.g. triggering an sms)?
Great content!!
Mistake #6. Do not use streams everywhere and always, they are much slower in most cases.
great tutorial, I think you should make a LinkedIn Course for spring boot where you cover all aspects of spring such as web, security, data etc
Great video that tells me that I'm on the right track, but I have a doubt about point 1. By using private classes and having everything in the same package (something that is done a lot in spring projects) if we talk about feature architecture. Wouldn't it be a disadvantage in this case? Since we would surely have a shared domain between all the features and would we break with this encapsulation? What do you think or what alternative do you use for these cases?
Hi Dan, what is your opinion about putting business logic in config files like application yaml to make it extensible. Recently there was a requirement where data had to be filtered based on some fields and these fields could change in future. Someone suggested to put them in configuration files to make it future proof.
Concerning the mistake 5: is there a way to also set response message (not only response code) for spring to render by some annotation?
Mistake 6 improper medieatype or missing mediatype. All rest controllers should produce json mediatype and consume it for post/update/patch. There are clever hacks that use improper media type handling.
JSON is not a requirement of REST. You can use other formats.
I wonder would it be better instead of throwing a TodoNotFoundException create a NotFoundException with a message property and throw it?
please to on package structuring in spring project. thanks!
Num 2 is why I like lombok's @RequiredArgsConstructor
Hello Dan, do you have any channel through which we can submit our code to you for a code review?
Aren't repositories interfaces instead of classes?
great
Wait... some people arent using dark mode?
Not using constructor injection for @ConfigurationProperties.
I'm a little confused about the same mappings, how will the controller know which one to call?
it is combination of path and http method (get, post etc.)
I'd say "5 Common Mistakes Spring WEB Developers Make"
Dan what theme are you using for the demo. just curious
Hi, Dan! The github repo is private... =/
Fixed. Thank you for letting me know.
@@DanVega Thank you, Dan!
Mistake #1 making everything public… makes the repo private😂 I lol‘d
@@zombi1034 hahaha!
@@zombi1034😂😂😂
love it
245th...Thanks Dan
Color theme name please
Hide the pain Dan
💖 Promo>SM
this interface mistake is not really a mistake. I do it all the time
unnecessary interfaces we see in the corporate projects everywhere, sometimes people does not put methods too. because they learned by rote. I am disagree and removing when I see. delete like a butcher!
this are lousy recommendations. review what you are saying. most of them are bad practices
What about the "Resource Oriented design principle" used for designing the REST endpoints? It says that the endpoints should be named after the resources that they are dealing with. But when we are dealing with multiple resources, it says we should use nested endpoints following the resource hierarchy? Is it necessary to follow these?
Have mercy on folks that watch this at night time. Light mode is a no no 😭
what about summer developers?
Very good advice for a novice like me. Thanks a lot!
+ light mode.
I've been guilty of most of these because that's how I learned from other developers to do it. You've given me some fuel for thought - thanks Dan!
I have done the same by just copying what others do without asking why they did it.
The git repo is not available @DanVega
Should be now.