r/SpringBoot

Hey everyone,

I'm currently building a full-stack app (Spring Boot backend + React frontend) and need to implement document parsing/text extraction functionality.

Requirements:

• Budget: Free / Open Source.
• Formats: Primarily PDFs, DOCX, and ideally scanned images/invoices (basic OCR).
• Integration: Preferably handled on the Java/Spring Boot backend (REST API) to send structured JSON to the React client.

Hello all!

I am fairly new to Spring Boot and coding in general.

I took it upon me to build a simple browser game where the player chooses an action and gains resources over time. I am currently finishing the prototype and I am being slowly introduced to all of the concepts behind the actual coding, but also when it comes to layering and design choices as well.

On to my dilemma.

So far I have several @ Transactional annotations inside the service layer whenever I interact with the repository layer in order to ensure that no two methods make changes to the DB - throwing any calculations made go haywire. Not sure if this is a common or best practice but it was a semi-conscious decision that I made during the early stages of development.

Now I am at a point where I have two identically named methods inside the service layer:

• calculateProgress(UUID playerId) - it searches the db for a PlayerCharacter instance using the playerId field and then does some calculations.
• calculateProgress(PlayerCharacter character) - it already gets a PlayerCharacter instance and does the calculations.

In fact, the first one calls the second one inside its body. The reason for this is that there is a scheduler that calculates the progress in regular intervals. And that scheduler only knows the PlayerCharacter's playerId and not any other information for that PlayerCharacter. So my initial thought was to have it call calculateProgress(UUID playerId) which in turn calls calculateProgress(PlayerCharacter character) to make the calculations etc etc.

I was not thinking much about it when I first did this but now I am realising that having two methods with the exact same name (and different arguments) might be ugly/not a good practice for the readability and maintainability of my code.

Now I am thinking: I could have the scheduler method call a new service method that returns a PlayerCharacter instance if I give it the playerId, and then call calculateProgress(PlayerCharacter character).

That would mean though that I need to have the scheduler method have a @ Transactional annotation to avoid the race conditions that I mentioned earlier. That would in turn break my initial decision of having Transactional annotations in the service layer only and also move db integrity from the service layer to the scheduler layer.

So I am thinking again and I pose the same question to anyone who might read this: Is it a common/good/best practice to have transactionality into the scheduler layer as well as the service layer or is there another option for my case?

Thanks in advance for anyone providing any feedback to my conundrum!

TL;DR: Have Transactional annotated methods inside the scheduling layer as an exception OR keep them strictly inside the service layer instead? Is it a good/common practice to do that split?

I have been thing what should I choose for backend as i want to become a full stack engineer. I just completed js and React in frontend . I am confused between java+spring boot or .Net . I will learn python as well .

What's your opinion ? What will be better option for me ?

I want to learn springboot now from scratch any experienced candidates can you please suggest me is it good to learn springboot now in the AI era or should i focus on any other AI related skills

Two weeks ago, I set out to solve a simple problem for a local pharmacy: keeping track of inventory.

My first thought was, "Why not just use Excel?"

So I spent time designing a workbook with separate sheets for products, stock movements, sales, current stock, dashboards, and weekly reports. I added formulas, dropdown lists, search functionality, automatic calculations, and conditional formatting. It worked surprisingly well.

But as I kept building, I started running into limitations.

What happens if two people need to use it?

How do you prevent accidental edits to formulas?

How do you manage user authentication?

How do you make backups and restore data easily?

How do you package it so the business owner just clicks one button and starts working?

That's when I realized the spreadsheet had become a prototype rather than the final solution.

So I decided to build a lightweight inventory management system instead.

Tech Stack

Angular (Frontend)

Spring Boot (Backend)

SQLite (Database)

I intentionally chose SQLite because I wanted the system to run on a single computer without paying for cloud hosting or a VPS. The goal was to keep it affordable for a small business.

Some of the features I built include:

Secure login and authentication

Product management

Stock In / Stock Out transactions

Automatic current stock calculation

Sales recording

Dashboard with inventory insights

Low-stock and expiry tracking

Database backup and restore

Packaged deployment so the entire application can run from one folder

One of the most interesting parts was figuring out deployment. Instead of requiring separate frontend and backend servers, I bundled the Angular application inside the Spring Boot application, so the owner only needs to start one application. The SQLite database lives outside the application, making updates much safer because the data isn't lost when deploying a new version.

This project taught me something important: sometimes the best solution isn't the one you start with. Starting with a spreadsheet helped me understand the business workflow before writing a single line of backend code. By the time I built the application, I knew exactly what the users needed because I had already modeled the process.

Looking back, I'm glad I didn't stop at Excel. It evolved into a complete inventory management system that solves the same problem in a much more scalable way.

I'd love to hear how others approach projects like this. Have you ever started with a spreadsheet or another simple tool, only to realize it needed to become a full application?

As the title says

Currently I am a student, my projects are In Java Fullstack

Right now I don't even know what RAG or MCP is , and I think I should have some hands on experience of it, i should be at least aware of it, because it's a trendy topic , not these two terms only, but many things

Now should I start python, for getting into it, is there any need , or I can explore Spring AI

If I don’t really have a front end, and I want to learn how to test my backend, is there any video recommendations that yall that explains how to write test for it. Because I don’t want to watch a video and form wrong foundation info.

[supprimé]

Java springboot is so vast once u dive into it, first java, then springboot, then microservices, exploring message queues , and what not

But nowadays what I have seen is that top companies organizing their hackathons, for fresh graduates

Most of them are ml based ai based, like making a model XYZ model, something like a model that detects deepfake images , that's just an example

What is the role of java springboot then, i sometimes feel I wasted my time learning this, i think I should have master python, what are ur thoughts

I've been thinking about contributing to some open source projects built with spring boot. What are some good open source projects that you think are worth contributing to in 2026?

Once I got a call a while back because a customer record "wasn't processing." Two hours later the culprit turned out to be log.warn("Could not process customer: {}", customer) - @Data's generated toString() was walking a lazy @OneToMany, the persistence context was already closed, and the log line itself threw the exception. The stack trace pointed at logging code, not the real bug.

That's one reason why I don't put @Data on entities anymore. Field-based equals is wrong for most entities, a toString that walks associations is a logging incident waiting to happen, and once you're bolting @ToString(exclude = ...) back on to undo it, you haven't saved typing, you've just hidden it.

Wrote up the longer version (builders, @SuperBuilder gotchas) as chapter 5 of a series I'm doing on Spring/Java architecture. Link in comments if anyone wants it. Curious if others have hit the same lazy-loading-in-logs thing or if it's just how our entities were modeled.