5 Common Mistakes Spring Developers Make
HTML-код
- Опубликовано: 8 июн 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 ❤️ 
Наука
thanks! writing interfaces, which are never used are waste of time. good to hear this from an experienced spring developer.
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?
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.
Thanks for creating this video Dan. Looking forward to more additions on the common mistakes series. Cheers!
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
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. 😄
Amazing Tutorial Dan! As someone who is exploring Spring, this was a great learning
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.
Very good advice for a novice like me. Thanks a lot!
Dan, thanks for sharing. I hope you will make this a series and add more "mistakes" to the repository and RUclips
Thank you Dan. Very insightful.
Very good basic points made here. Clear and concise. Dan delivers 😊
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.
#1 is going to be problematic in the long run IMO. Agree with you about all others!
Thanks for good examples
good topic and easy explanation
Great video, thanks Dan! Looking forward to the exception video!
learned a lot, thanks Dan
thanks!!! please continue!!!
Kindly continue this series.
Very useful content!
Thanks!!
Keep sharing good practices about coding with Spring.
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
Great content!!
Learned some good stuff
of course, it is sounds like very good series
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
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.
Great tips @DanVega regarding handling errors video you mentioned at 13:40, is that one already published? tnx
i love the feature package organization idea, can you make a video on 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.
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.
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?
Thanks!
Wow thank you so much for your generosity. I appreciate you 🤩
@@DanVega np. what intellij theme did you use for the demo?
please we need more
Hi Dan, please add hexagonal architecture video
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.
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?
love it
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.
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!
Dan what theme are you using for the demo. just curious
Mistake #6. Do not use streams everywhere and always, they are much slower in most cases.
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 :)
Concerning the mistake 5: is there a way to also set response message (not only response code) for spring to render by some annotation?
Hello Dan, do you have any channel through which we can submit our code to you for a code review?
please to on package structuring in spring project. thanks!
in last example. better to just return optional from repository. And then throw exception from controller.
Have mercy on folks that watch this at night time. Light mode is a no no 😭
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?
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?
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! =)
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
In Mistake #1, how to write unit tests if service layer is private ?
Do we expect to keep Unit test code in same package?
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 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.)
Not using constructor injection for @ConfigurationProperties.
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
245th...Thanks Dan
what about summer developers?
first viewer..''🎉🎉
🎉
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.
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😂😂😂
+ light mode.
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.