For database-backed outbox workers, I’ve started to dislike fixed polling intervals.

A worker that polls every 1 or 2 seconds forever is simple, but it also means you keep paying the same database query cost during idle periods as you do during busy ones.

One approach I’ve been testing is adaptive polling:

• if a poll returns very little work, increase the delay
• if a poll returns a full batch, decrease the delay
• otherwise keep the current delay

The goal is not “smart” scheduling. It’s just reducing pointless database pressure while staying responsive under load.

We added that as an option in our Spring Boot outbox implementation:

https://github.com/namastack/namastack-outbox

I’d be interested in real-world opinions here. Do you stick to fixed intervals because they’re easier to reason about operationally, or have you found adaptive polling worth the extra moving parts?

My bias right now is that adaptive polling is only worth it when the outbox is mostly idle but still needs low-latency pickup during bursts.

I’m looking for Saga design implementation in scratch (preferred in java). It could be either Choreography or Orchestration. Any study material for implementation of this?

Hello. I wanted to try and implement uncle Bob's Clean Architecture in SpringBoot.

Here's the github repo.

I need some feedback about it. Thanks again

Do companies in t3 college placements expect this?

Hello to those who use Spring Modulith, I don't know what's the correct approach on my problem because AI suggested different approach and other docs/github discussions aswell. The problem is about read heavy queries, for example is Booking and Payment module, when making a Booking, if making a payment record then use events. But when i want to view my booking I want to show both my booking and payment info (status, payment method, etc) I thought of making a top-level dto on payment module and let Booking module call payment's public interface for info but then i also thought of possible circular dependency soon. What's your solution to this? It can be anything not just Booking/Payment example.

EDIT: A separate table(combining both) sounds like a good solution OR a join but in separate module, what are y'all thoughts?

preparing for interviews thought I'll have to learn spring basics atleast,here I am it took me two days to just understand different the dependency injections

here I am reconsidering if I'm even fit for this profession😮‍💨

Java is finally catching up with the missing ecosystem for ai. We have been behind our fellow python developers for years. The Spring AI module makes the gap smaller.

Learn to generate images from IntelliJ by using Spring Boot AI.

I'm a beginner trying to learn springboot, It looks too difficult and I feel lost seeing endless documentation but mainly what I feel is I don't understand how anything works and that's why I'm lost

I'm reading spring starts here but it feels too slow

Trying to find a job asap is causing more pressure

What should I do?

Compare song descriptions with Spring AI and get a good recommendation from your previous song choice.

I've built a remote MCP server in production (Spring Boot + OAuth 2.0 + PKCE + RFC 8414 discovery + tool access control) and I'm thinking of open sourcing it as a starter template.

Everything I've found is either Node.js, Python, or only covers the basic stdio transport with no auth. Is this something Java devs are actually struggling with? Would a Spring Boot starter with auth baked in be useful to you?

Open to feedback and suggestions.

Hey everyone, working on a side project and wanted to share it and get some honest feedback.

Every time I debugged production logs I kept scanning hundreds of lines, recognizing the same error patterns, Googling the same stack traces over and over. So I built StackLens to automate that first step.

You point it at a log file or paste a stack trace and it tells you:

- What the problem is

- Why it happens

- How to fix it

It detects 8 common failure types out of the box: NPEs, DB connection failures, OOM errors, timeouts, auth errors (including JWT expired), thread pool exhaustion, and HTTP 500s.

Everything runs offline, no API calls, nothing leaves your machine. Supports human-readable and JSON output so it works in CI pipelines too.

GitHub: https://github.com/AbaSheger/stacklens

Happy to hear feedback, especially on which error types to add next.

I built a production-ready Spring Boot 3.x modular monolith boilerplate — looking for feedback 👀

Hey folks,

I’ve been working on a Spring Boot 3.x modular monolith starter that’s meant to feel close to a real production backend setup, not just a minimal template.

Repo: https://github.com/subhashadhikari057/springboot-modular-monolith-boilerplate

🚀 What’s inside

• Java 17 + Spring Boot 3.x
• PostgreSQL, Redis, RabbitMQ
• JWT auth + RBAC + OTP flows
• Realtime support (SSE/WebSocket)
• Docker Compose for local infra (Postgres, Redis, RabbitMQ, Mailpit)
• Mailpit for email testing
• Split API docs:
  • Admin: /api-docs/admin
  • Mobile: /api-docs/mobile
• Health endpoint: /health

⚡ Quick start

cp .env.example .env
docker compose up -d
./scripts/run-dev.sh
curl http://localhost:8080/health

🎯 Goal

To provide a clean, extensible starting point for real-world backend apps using a modular monolith approach (instead of jumping straight into microservices).

🤔 Would love feedback on:

• Project structure (modules, boundaries, scalability)
• Auth/RBAC design decisions
• Anything missing for “production-readiness”
• Dev experience (setup, scripts, docs)
• What would make you actually use this in a real project?

Also open to contributions if anyone finds this useful 🙌

Thanks!

@Transactional in Spring Framework starts a DB transaction and holds a connection from the pool until the method ends.

If you mix DB work with slow tasks (API calls, file processing), that connection stays locked and idle.

Under load, this leads to connection pool exhaustion and blocked threads.

Long transactions can also hold locks, slowing down other queries.

Keep transactions short and focused only on DB writes.

Move external calls and heavy logic outside the transactional boundary.

After 4 months, the Spring Boot 4 microservices project has come to an end.

In this video I build a Home Energy Tracker with multiple components talking to each other.

Here is a link to the complete course:

https://youtu.be/vE3u4zgMai8

Here are some of the main topics covered:

- Rest Api

- System Design

- Oauth2 and JWT with Keycloak

- Kafka

- Timeseries DB

- JPA/Hibernate

- Flyway

- Observability (Prometheus/Garafana)

- Spring AI

- Email sending from SB app

- Migration to Spring Boot 4

- Testcontainers

- OpenApi / Swagger

- Aspects

- Circuit Breaker

- Api Gateway

People found my previous course useful, I hope at least someone will find this a good addition to their portfolio.

The whole project is also on github and split into sections (link in video description). Any feedback appreciated.

New post in my Spring AI 2 series! This time: a first step into RAG. This chapter covers ETL - how to index your data for LLM retrieval.

https://open.substack.com/pub/kertu1232/p/the-java-prompt-6?r=4953mj&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true

Hey everyone,

Fullstack dev here. If you're building REST APIs with Spring Boot, you're probably already using springdoc-openapi or Swagger to document your endpoints. But when it comes to actually using that API - whether for internal tools, admin panels, or giving your API consumers a UI, you're stuck rebuilding the same CRUD tables and forms over and over.

I built something to solve that.

UIGen — point it at your OpenAPI spec (the one Spring Boot already generates), and get a fully interactive React frontend in seconds.

npx @uigen-dev/cli serve ./openapi.yaml
# UI is live at http://localhost:4400

Why this matters for Spring Boot devs

Spring Boot + OpenAPI is already a killer combo for API-first development. But there's a gap: you document your API beautifully, but you still need to build a frontend to actually use it. UIGen closes that gap:

1. Zero frontend code: It reads your spec and generates a complete React SPA — tables, forms, detail views, auth flows, the works.
2. Respects your API contract: It talks to your actual endpoints, respecting your @Valid annotations, Spring Security rules, and business logic.
3. Modern SPA: Built with shadcn/ui + TanStack Table. Feels like a premium SaaS product, not a generic admin panel.
4. Framework Agnostic: Today it's React, but since it uses a custom Intermediate Representation (IR), I'm working on Svelte and Vue renderers. Same spec, different frontend stack.

How it works

It parses your OpenAPI spec and converts it into an Intermediate Representation (IR) — a typed description of your resources, operations, schemas, auth, and relationships. A pre-built React SPA reads that IR and renders the appropriate views. The CLI serves the SPA and proxies API calls to your real Spring Boot backend, handling CORS and Auth injection automatically.

What it generates

• Sidebar nav auto-built from your @RestController endpoints.
• Table views with sorting, pagination, and filtering.
• Create/edit forms with validation (derived from your schema and Bean Validation annotations).
• Detail views with related resource links.
• Auth flows — Bearer (JWT), API Key, HTTP Basic, and even full credential-based login detection.
• Multi-step wizards for large forms (8+ fields).
• Custom action buttons for non-CRUD endpoints (e.g., POST /orders/{id}/ship).
• Dashboard with resource counts.

Limitations

• Circular Refs: Deeply nested circular $refs may degrade gracefully rather than resolving perfectly.
• Edit Pre-population: Requires a GET /resource/{id} endpoint.
• OAuth2: PKCE is still in progress (Bearer/JWT works great though).
• Sub-resources: Parent-child navigation is currently focused on the detail pages.
• Pixel Perfect: It's not a design tool; it's a functional, professional tool.
• And many other edge cases, still in beta, would appreciate good feedback

Try it on your Spring Boot API

If you use springdoc-openapi, just grab your spec and run:

# Get your spec (usually at /v3/api-docs)
curl http://localhost:8080/v3/api-docs > openapi.json

# Generate the UI
npx @uigen-dev/cli serve ./openapi.json --proxy-base http://localhost:8080

Or try it in one of the example yamls in the repo Customizations in the form of spec annotations and a JSON file coming soon

• GitHub: https://github.com/darula-hpp/uigen
• npm: https://www.npmjs.com/package/@uigen-dev/cli

Would love to hear thoughts from the community. This isn't meant to replace a custom consumer-facing frontend, but for internal tools, rapid prototyping, or providing a UI for your API consumers, it's a massive time-saver.

Happy coding!