5 Common Mistakes Spring Developers Make
Vložit
- čas přidán 11. 07. 2024
- 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 ❤️ - Věda a technologie
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.
This was great. #2 and #3 are what was drilled into years ago and ive never questioned them.
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
Please continue along these line of topics!
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.
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 😂
as always, thanks for this Dan! You're helping beginners like me in a massive way.
Thank you Dan. Very insightful.
Amazing Tutorial Dan! As someone who is exploring Spring, this was a great learning
Very good basic points made here. Clear and concise. Dan delivers 😊
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!
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?
Dan, thanks for sharing. I hope you will make this a series and add more "mistakes" to the repository and CZcams
#1 is going to be problematic in the long run IMO. Agree with you about all others!
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.
Very good advice for a novice like me. Thanks a lot!
Great video, thanks Dan! Looking forward to the exception video!
good topic and easy explanation
Thanks for good examples
Keep sharing good practices about coding with Spring.
This is great, ... Keep them coming
thanks!!! please continue!!!
Very useful content!
Thanks!!
learned a lot, thanks Dan
of course, it is sounds like very good series
Kindly continue this series.
Great content!!
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'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.
Learned some good stuff
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 content thank u
#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.
Looking forward to a video about @Transactional annotation and common mistakes while using it.
Actually none of them are mistakes. I would call them tips and they are great. Thanks!
please we need more
Thanks!
Wow thank you so much for your generosity. I appreciate you 🤩
@@DanVega np. what intellij theme did you use for the demo?
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 :)
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 love the feature package organization idea, can you make a video on it?
Great tips @DanVega regarding handling errors video you mentioned at 13:40, is that one already published? tnx
love it
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.
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.
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?
Hi Dan, please add hexagonal architecture video
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!
great
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.
Have mercy on folks that watch this at night time. Light mode is a no no 😭
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
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?
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! =)
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.
in last example. better to just return optional from repository. And then throw exception from controller.
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?
Mistake #6. Do not use streams everywhere and always, they are much slower in most cases.
Dan what theme are you using for the demo. just curious
In Mistake #1, how to write unit tests if service layer is private ?
Do we expect to keep Unit test code in same package?
Concerning the mistake 5: is there a way to also set response message (not only response code) for spring to render by some annotation?
245th...Thanks Dan
Hello Dan, do you have any channel through which we can submit our code to you for a code review?
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
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
please to on package structuring in spring project. thanks!
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...
I wonder would it be better instead of throwing a TodoNotFoundException create a NotFoundException with a message property and throw it?
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.
feature based is good but still require public , moslty need to talk to different package, very rare package is restricted not needed to talk
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.)
what about summer developers?
+ 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😂😂😂
Wait... some people arent using dark mode?
Color theme name please
Hide the pain Dan
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.