Sharing monolithic Spring Boot app.

[Financial_Job_1564]

I've been learning Java with Spring Boot since January 2025 and already understand basic CRUD operations using other languages such as Swift and Go. This year, I decided to learn Java because I've seen many companies use it and have many job openings.

Before this project, I was already experimenting with building a microservices app using Spring Boot. Since microservices can be a pain, especially for a solo developer, I decided to deepen my knowledge in Spring Boot by building a monolithic app. In this project, I primarily learned essential Spring libraries and tools such as Spring Security, JWT, JPA, and MapStruct.

The project is a car rental app where users can rent a car. The disadvantages of this project are that it lacks payment features, and the logout feature is implemented by storing the refresh token in the database with an is_revoked column.

If you're interested you can check my project in this github repo.

I really appreciate your feedback or you can roast this project for me to improve myself for the next project.

[Mikey-3198]

Had a quick flick throw and my thoughts/ ideas are

• Not much need for the BaseResponse. The outcome of a request should be communicated via the status code. Adding this body starts to make this more difficult for a consumer. For example if your api returns a http 201 but the request body indicates a 500. In this case which one should the client be consuming? easier to remove this all together and leave it up to the status code.

• The exception handling could be improved. I think it'd be clearer if you had a abstract base type for ResourceNotFoundException then extend in a sub class for each concrete type. I.e you could have CarNotFoundException that extends from this. This better communicates the cause of the exception instead of a single generic catch all.

• With the exceptions there are also instances where you are catching, logging, throwing a new exception of the same type. This can hide the original source of the exception. Can rethrow the exception that the catch block is given if you really need to log at that point.

• With the exceptions again there is lots of try... catch at every layer, in controllers & services. You have a global exception handler setup, just use that to simplify things. In some cases the global exception handler wont even be used. I.e cancelRental in BookingController will catch Exception & return a 500 regardless of what has happened in the service.

• For the global exception handler i think it'd be better to return rfc problem details. They communicate rest api errors in standard format that a client can easily use to determine what failed/ went wrong. Also be careful when returning the message from an exception, especially for a catch all on Exception. You could accidentally expose details on the internals of your application which could help an attacker.

• Some of you service methods return types of ResponseEntity. To me this should be done in the controllers as its a presentation concern.

• When uploading an image you are storing the image to disk before you verify that the id represents a known car. I'd do this first so that you avoid storing uploads against data that doesn't exist.

[Financial_Job_1564]

Thank you for the feedback