In this tutorial we will look at 5 common mistakes we make as Spring Developers and how we can improve on them. This isn't in any specific order but just 5 mistakes that I notice often when looking at the code of Spring Boot applications.
🔗Resources & Links mentioned in this video:
GitHub Repo: github.com/danvega/spring-com...
👋🏻Connect with me:
Website: www.danvega.dev
Twitter: / therealdanvega
Github: github.com/danvega
LinkedIn: / danvega
Newsletter: www.danvega.dev/newsletter
SUBSCRIBE TO MY CHANNEL: bit.ly/2re4GH0 ❤️
thanks! writing interfaces, which are never used are waste of time. good to hear this from an experienced spring developer.
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!
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 😂
Thank you Dan. Very insightful.
as always, thanks for this Dan! You're helping beginners like me in a massive way.
Very good basic points made here. Clear and concise. Dan delivers 😊
Amazing Tutorial Dan! As someone who is exploring Spring, this was a great learning
Dan, thanks for sharing. I hope you will make this a series and add more "mistakes" to the repository and KZhead
Very good advice for a novice like me. Thanks a lot!
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 good examples
Great video, thanks Dan! Looking forward to the exception video!
#1 is going to be problematic in the long run IMO. Agree with you about all others!
Very useful content! Thanks!!
good topic and easy explanation
Keep sharing good practices about coding with Spring.
learned a lot, thanks Dan
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
Kindly continue this series.
thanks!!! please continue!!!
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.
of course, it is sounds like very good series
Great content!!
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 love the feature package organization idea, can you make a video on it?
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.
Looking forward to a video about @Transactional annotation and common mistakes while using it.
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.
Thanks!
Wow thank you so much for your generosity. I appreciate you 🤩
@@DanVega np. what intellij theme did you use for the demo?
Hi Dan, please add hexagonal architecture video
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.
please we need more
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, 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?
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 :)
Actually none of them are mistakes. I would call them tips and they are great. Thanks!
love it
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?
Dan what theme are you using for the demo. just curious
in last example. better to just return optional from repository. And then throw exception from controller.
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.
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.
Hello Dan, do you have any channel through which we can submit our code to you for a code review?
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
Have mercy on folks that watch this at night time. Light mode is a no no 😭
please to on package structuring in spring project. thanks!
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! =)
Mistake #6. Do not use streams everywhere and always, they are much slower in most cases.
I wonder would it be better instead of throwing a TodoNotFoundException create a NotFoundException with a message property and throw it?
I'm a little confused about the same mappings, how will the controller know which one to call?
In Mistake #1, how to write unit tests if service layer is private ? Do we expect to keep Unit test code in same package?
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...
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
feature based is good but still require public , moslty need to talk to different package, very rare package is restricted not needed to talk
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
245th...Thanks Dan
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.
what about summer developers?
Color theme name please
+ light 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😂😂😂
Hide the pain Dan
first viewer..''🎉🎉
🎉
I'd say "5 Common Mistakes Spring WEB Developers Make"
💖 Promo>SM
this interface mistake is not really a mistake. I do it all the time
Num 2 is why I like lombok's @RequiredArgsConstructor
The git repo is not available @DanVega
Should be now.