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
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.
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.
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.
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
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.
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)?
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?
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.
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.
#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.
About the interface mistake. In cases of services, I like to use to have more flexibility on refector. But i noticed some projects that the developers uses interfaces on controllers just to use annotations for springdoc. About the first one, if the project is a micro-service with only one responsibility domain, it still a mistake?! Thinking about one MS that manager a Shopping Cart, it probably have many model class and some external client call. Isn't made the package bigger and difficult to notice it interactions?!
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).
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?
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!
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.
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
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.
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...
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!
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
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.
Please continue along these line of topics!
Thanks!
Wow thank you so much for your generosity. I appreciate you 🤩
@@DanVega np. what intellij theme did you use for the demo?
This was great. #2 and #3 are what was drilled into years ago and ive never questioned them.
Amazing Tutorial Dan! As someone who is exploring Spring, this was a great learning
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.
Thanks for creating this video Dan. Looking forward to more additions on the common mistakes series. Cheers!
as always, thanks for this Dan! You're helping beginners like me in a massive way.
Thank you for the interesting video, and number 6: not dropping by the Spring office hours.
Ohh that’s a good one haha 😂
Dan, thanks for sharing. I hope you will make this a series and add more "mistakes" to the repository and UA-cam
Very good advice for a novice like me. Thanks a lot!
Very good basic points made here. Clear and concise. Dan delivers 😊
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. 😄
Great tips @DanVega regarding handling errors video you mentioned at 13:40, is that one already published? tnx
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.
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.
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.
Thank you Dan. Very insightful.
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
thank you first all, it worth also to mention that using controllerAdvice we can handle the exceptions also much better in spring
Great video, thanks Dan! Looking forward to the exception video!
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
Keep sharing good practices about coding with Spring.
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.
#1 is going to be problematic in the long run IMO. Agree with you about all others!
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)?
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?
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.
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.
As per Interface usage, what about unit testing? How do we test a service if we cannot decouple its dependency via using Interfaces?
#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.
of course, it is sounds like very good series
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.
About the interface mistake. In cases of services, I like to use to have more flexibility on refector. But i noticed some projects that the developers uses interfaces on controllers just to use annotations for springdoc. About the first one, if the project is a micro-service with only one responsibility domain, it still a mistake?! Thinking about one MS that manager a Shopping Cart, it probably have many model class and some external client call. Isn't made the package bigger and difficult to notice it interactions?!
In Mistake #1, how to write unit tests if service layer is private ?
Do we expect to keep Unit test code in same package?
That's a good question and I hope Dan Vega can give us an answer.
Dan what theme are you using for the demo. just curious
Concerning the mistake 5: is there a way to also set response message (not only response code) for spring to render by some annotation?
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! =)
Actually none of them are mistakes. I would call them tips and they are great. Thanks!
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?
This is great, ... Keep them coming
i love the feature package organization idea, can you make a video on it?
Kindly continue this series.
Looking forward to a video about @Transactional annotation and common mistakes while using it.
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!
Thanks for good examples
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.
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.)
good topic and easy explanation
Great video. Thanks
thanks!!! please continue!!!
feature based is good but still require public , moslty need to talk to different package, very rare package is restricted not needed to talk
learned a lot, thanks Dan
Very useful content!
Thanks!!
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
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.
Hi Dan, please add hexagonal architecture video
Learned some good stuff
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 :)
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!
please we need more
great content thank u
Great content!!
thanks!
in last example. better to just return optional from repository. And then throw exception from controller.
what about summer developers?
Not using constructor injection for @ConfigurationProperties.
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...
Have mercy on folks that watch this at night time. Light mode is a no no 😭
Aren't repositories interfaces instead of classes?
Wait... some people arent using dark mode?
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😂😂😂
Mistake #6. Do not use streams everywhere and always, they are much slower in most cases.
Color theme name please
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.
love it
I'd say "5 Common Mistakes Spring WEB Developers Make"
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
245th...Thanks Dan
+ light mode.
Hide the pain Dan
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!
💖 Promo>SM
this interface mistake is not really a mistake. I do it all the time
Yagni
this are lousy recommendations. review what you are saying. most of them are bad practices
The git repo is not available @DanVega
Should be now.
Num 2 is why I like lombok's @RequiredArgsConstructor