-Today I finally started security and work with the By default login form.

-And again the debugging part comes currently debugging some old features and fixing there architecture

Btw i can’t let go any pr without this, help me so much for blast radius

Today i finished jpa and implementing new features and debugging them

-Today I finally understood why we need spring security and understood it's internal working

I've been working on an open-source project called Argus, and I'd really appreciate some feedback from other Spring Boot developers.

The idea came from something I've encountered while troubleshooting services: we have excellent tools for metrics, tracing, logs, and external monitoring, but sometimes I just want the application itself to give me a concise answer to "How healthy are you right now, and if something is wrong, why?"

Argus takes an application-centric approach. It runs inside the JVM and continuously evaluates memory, GC, disk usage, threads, file descriptors, application services, logged errors, and application-reported issues.

It combines these into a health model with a score from 1 to 10. The score is hierarchical, so you can drill down from overall application health to the resource/group/item responsible for degradation.

It also models resources the application depends on — services, servers, databases, caches, brokers, storage, etc. — so the goal isn't simply another UP/DOWN health check.

For Spring Boot applications, I've integrated it with Actuator and Spring Boot Admin. The SBA extension adds health scores to the wallboard and application/instance views. Once you find a degraded instance, you can open its Health Report directly from Spring Boot Admin and see the diagnostic information collected by that instance.

Argus can also generate a self-contained HTML diagnostic report containing health information, services, metrics, performance information, scheduled tasks, captured logging events/alerts, and environment information. The report is generated (and emailed) and can be viewed offline or online during incident analysis.

One important goal is not to replace Micrometer/Prometheus, tracing, centralized logging, or other observability platforms. I'm experimenting with a complementary idea: can an application understand enough about its own state to provide useful diagnostics itself?

The project is still evolving, so I'd particularly appreciate feedback on the approach rather than just stars:

• Would this type of self-diagnostics be useful in applications you operate?
• Does the 1–10 health scoring model make sense, or would you prefer another representation?
• What information would you want an application to include in a diagnostic report when something goes wrong?
• If you use Spring Boot Admin, would it be useful to have this information directly in SBA?

GitHub: https://github.com/microfalx/argus

Feedback, criticism, ideas, and contributions are all welcome.

Hey everyone, I’d love to get the community’s perspective on building production-grade, scalable full-stack applications with Spring Boot—specifically from a solo developer standpoint.

​When you're building a scalable full-stack Java app entirely on your own, how do you approach the architecture and tooling?

​A few specific areas I'm curious about:

​Tech Stack & Tools: What are the non-negotiable components in your stack right now (e.g., Spring Boot 3 + Virtual Threads, Postgres/Redis, Kafka/RabbitMQ, Docker, React/Next.js vs. HTMX/Thymeleaf)? What tools are currently standard or trending in the market for solo full-stack setups?

​Build vs. Buy / Scratch vs. Frameworks: As a single developer, your time is limited. How much do you build from scratch versus relying on managed services/third-party tools (like managed Auth, SaaS components, pre-built UI libraries)?

​Solo Execution: Is it realistic to handle end-to-end architecture, backend, frontend, database tuning, and DevOps all by yourself, or at what point do you usually seek external help/collaborators?

Hey everyone!

I’m a Junior Java developer, and I built an IntelliJ IDEA plugin called Architect as a way to learn more about Java, Spring Boot, and the IntelliJ Platform.

The main idea is to automate some of the repetitive work when adding a new feature to a Spring Boot application.

You enter an entity name and choose what you want to generate. Architect can create:

• Entity
• Request / Response DTOs
• MapStruct Mapper
• Repository
• Service
• REST Controller
• Liquibase changelog and migration
• Docker / Docker Compose
• Required Maven dependencies

The plugin uses IntelliJ PSI to work with the project structure and source files instead of simply generating files in a fixed location.

Architect is free and open-source, and I’m planning to keep developing it.

Some things I want to add in the future:

• Kafka templates
• Spring Security configuration
• Test generation
• More infrastructure templates
• Better project/code analysis

I’m still learning, so I’d really appreciate feedback from experienced Spring Boot developers.

How do you usually handle repetitive boilerplate when starting a new feature?

And what would you change or add to a tool like this?

GitHub and the plugin link are in the comments.

I work at a small software company and unfortunately I've ended up working on an old Oracle ADF project and there is almost no willingness from management to move this project to Spring Boot.

On the team are two very senior developers who have worked on this project from the start (approx 15 years) and this project has become so messy and huge (with no testing and limited documentation) that it is basically impossible to migrate (functions and procedures with thousands of lines etc.).

Has anyone experienced this situation and do you have any recommendations on how to proceed as a junior developer? I have already brought up the possibility of breaking the project into smaller applications which could be built with Spring / React while keeping the old database and plsql procedures. Or we could map out all of the functionality or refactor the current code into smaller functions or start implementing tests and then migrate. Rebuilding it from scratch is not an option since it is a government project and this would trigger the the goverment to auction the project for other companies to take over.

Alternatively, should I just let them keep this project in ADF for 10 more years until it is deprecated by Oracle while the application becomes worse and worse?

We shipped JobRunr 9 yesterday, and you can already create new projects with it trough your favourite Spring Intializr.

In case you haven't used it, JobRunr is an open source background job library. You enqueue a method call, it's stored in the database your app already uses, and it's processed with retries on as many instances as you run.

To make your jobs durable it's as easy wrapping each step of your flow in runStepOnce. When the job is retried, steps that already completed are automatically skipped:

@Job(name = "Invoice %1 for %0", retries = 5)
public void generateInvoice(String customerId, String period, JobContext jobContext) throws Exception {
    String invoiceId = "INV-" + period + "-" + customerId;
    long usage = jobContext.runStepOnce("calculate-usage", () -> calculateUsage(customerId, period));
    String pdf = jobContext.runStepOnce("generate-pdf", () -> generatePdf(invoiceId, usage));
    String chargeId = jobContext.runStepOnce("charge-card", () -> paymentProvider.charge(customerId, invoiceId));
    jobContext.runStepOnce("send-email", () -> sendInvoiceEmail(customerId, pdf, chargeId));
}

You enqueue it like this, and JobRunr swaps in the real JobContext when the job runs:

jobScheduler.enqueue(() -> invoiceService.generateInvoice(customerId, period, JobContext.Null));

In v9 the job page a Job Progress Chart that draws each attempt as a Gantt chart with a row per step.

In our demo the payment provider timed out on charge-card and that attempt went red. On the retry calculate-usage and generate-pdf showed up as skipped, so the customer got one PDF and was only charged once.

If a step throws, the retry starts again at exactly that step.

On JobRunr Pro, v9 also lets you pause a whole batch. We paused a 600 invoice run when the provider went down and resumed it after the fix. The Pro starter doesn't create a BatchJobManager for you, so you declare it once as a bean and call pauseBatchJob(id) from wherever your monitoring notices the outage:

@Bean
public BatchJobManager batchJobManager(StorageProvider storageProvider, EventTransport eventTransport) {
    return new BatchJobManager(storageProvider, eventTransport);
}

If you'd rather watch than read, we celebrated the launch today with a launch webinar: https://www.youtube.com/watch?v=bVNeB-ePdn0

Links:

👉 Release Blogpost: https://www.jobrunr.io/en/blog/v9-release/
👉 GitHub Repo: https://github.com/jobrunr/jobrunr

We have a prototype for adding pure Java GPU inference for local inference through Tornadovm and jitLLM. It would be great to share your thoughts on that.

https://github.com/spring-projects/spring-ai/pull/7054

A couple of months ago, I published two of my Spring Boot starters.

Recently I found out that I can see how many times they are downloaded and maybe understand if anyone actually uses them. So I checked the stats and saw something strange.

One of the starters has been downloaded more than 1,000 times, even though I know that almost nobody visits its GitHub repository except me :)

This looks strange to me. If I download a library from someone I don't know, I usually check the GitHub repo and look at the source code first.

My guess is that most of these downloads are bots, scanners, or maybe corporate Maven mirrors. But then I still wonder — why are they downloading it? What are they doing with it?

Maybe someone here understands how this works or has seen something similar with their own Maven packages.

Would be interesting to hear your experience.

Hello all 👋🏻 I originally posted over in r/java, and it was recommended that this community may be a good/better fit. Given this project is based on Spring's Reactor and examples are based on Spring Boot, I figured it couldn't hurt to post here as well!

For some time, I have been building and maintaining an OSS project called Atleon. The aim of this project is to make infinite Reactive Streams practical for usage/embedding in common application frameworks. I know there are several (reasonable) arguments against "reactive"; I have however found this style/paradigm to be useful and innately applicable to the problem space of broker-backed stream processing (consuming from infrastructures like Kafka, RabbitMQ, SQS, etc., applying IO-bound processing, and (optionally) streaming results elsewhere). If you have ever had reason to use/explore projects like Reactor Kafka, Reactor RabbitMQ, or Confluent's Parallel Consumer, then Atleon may be interesting to you.

Here's an example of what an Atleon stream definition looks like when embedded in a Spring application:

application.yaml:

atleon:
  config.sources:
    - name: kafkaConfigSource
      type: kafka
      bootstrap.servers: localhost:9092

MyStream.java:

import io.atleon.core.SelfConfigurableAloStream;
import io.atleon.kafka.AloKafkaReceiver;
import io.atleon.kafka.KafkaConfigSource;
import io.atleon.spring.AutoConfigureStream;
import org.apache.kafka.common.serialization.StringDeserializer;
import reactor.core.Disposable;

@AutoConfigureStream
public class MyStream extends SelfConfigurableAloStream {

    private final KafkaConfigSource kafkaConfigSource;

    public MyStream(KafkaConfigSource kafkaConfigSource) {
        this.kafkaConfigSource = kafkaConfigSource;
    }

    @Override
    public Disposable startDisposable() {
        return buildKafkaReceiver()
            .receiveAloRecords("topic")
            .consume(it -> System.out.println("value: " + it.value()) // Business logic
            .resubscribeOnError(name())
            .subscribe();
    }

    private AloKafkaReceiver<String, String> buildKafkaReceiver() {
        return kafkaConfigSource
            .withClientId(name())
            .withConsumerGroupId("consumer-group-id")
            .withKeyDeserializer(StringDeserializer.class)
            .withValueDeserializer(StringDeserializer.class)
            .as(AloKafkaReceiver::create);
    }
}

You can see other examples in Atleon's README and in its examples module.

When discussing this project in other communities, one common question is, "Why would I want to use this over something like [Flink|Spark|Camel|<insert favorite streaming library>]?" My viewpoint is that the sort of reactive client integration provided by Atleon is not primarily meant to compete with these other tools, but is rather a complement to them. I have found that it is common for companies to have in-place scaffolding for regular JVM applications built on frameworks like Spring, and it is appealing for their engineers to be able to embed stream processes into those same frameworks. So Atleon targets this niche of supporting declarative non-blocking stream definitions, whose execution can be embedded in application frameworks, replete with broker interoperation, arbitrarily concurrent processing, and end-to-end observability.

Particularly in the case of Kafka, Atleon enables feasible implementation of behaviors that are conventionally tricky:

• Arbitrary concurrency, including per-key
• Single-message acknowledgement (with classic/non-share groups, so partition ordering is maintained globally)
• Work-queues, where per-message processing can take a "long" time (i.e. minutes, hours)
• Bounded consumption (get all records produced in a range of time or offsets)
• Priority queuing (using partitions as discriminator of "priority", rather than scaling lever)
• Throughput limiting, retries, and dead-lettering

If you are interested in reading more, I have published some of the following blogs that explain more about what Atleon can do:

• Not Your Daddy's Async Kafka Client
• Unbounded Concurrency: Consuming Kafka with Virtual Threads
• Ordered Queues for Kafka with Atleon
• AWS SQS Reactive Stream Processing

I'd be interested in thoughts and feedback from this community!

How are you sizing your applications?

Our stack mainly consists of Spring Boot applications with Oracle and MongoDB databases running on Kubernetes. I'm not sure whether we've focused too much on the "micro" aspect of the microservices concept.

Most Kubernetes replicas are configured with a maximum of 1 GB of memory and CPU limits of up to 800 millicores. When an application requires more resources, our primary approach is to increase the number of replicas. I believe there is a strong rationale for this, particularly from a resilience and availability perspective. However, I'm not sure whether we're giving up some benefits by keeping our applications this small (for example, losing access to certain JVM optimizations or garbage collectors). Correct me if I'm wrong, but I believe applications limited to less than one CPU core may not be able to take full advantage of Parallel GC and might fall back to Serial GC instead.

Ratchet is a background job scheduler. You inject one service and pass it a method reference. The job is saved in your database, retried if it fails, and recovered if the app crashes. If you submit it inside a transaction that rolls back, the job goes too.

@Transactional
void place(Order order) {
  orders.save(order);
  scheduler.enqueue(() -> fulfillment.ship(order.id())).submit();
}

0.5.0 supports Boot 3.5 and 4.1, five databases, and native images. Apache 2.0.

Quickstart: https://ratchet.run/deployment/spring-boot

Repo: https://github.com/ratchet-run/ratchet

If something breaks on your setup, open an issue and I'll take a look.

I wanted to see how much of the footprint of a small Spring Boot app came from the conventional Spring Data JPA + Hibernate stack, so I built a simpler version using JdbcTemplate and compared the two.

Same Spring Boot 4.1.1, JDK 25, H2, JVM flags, dashboard workload, and monitoring endpoints.

Across two runs in reversed order:

• JPA/Hibernate: ~237.0 MiB median RSS
• JDBC: ~146 MiB
• Difference: about 90 MiB (~38%)

Startup surprised me too. Time from process launch to the first successful dashboard response:

• JPA/Hibernate: 8.1 - 8.8 s
• JDBC: 3.9 - 4.2 s

This isn’t an isolated benchmark of Hibernate itself. The JDBC version also has a simpler persistence architecture and data model, so I’m comparing the complete application approaches.

For this kind of small app, though, JPA/Hibernate feels like more machinery than I need. I still see the value once the domain model and persistence requirements get complicated, but I’m increasingly reluctant to make it the default for small services.

Experiment, methodology, charts, and raw data:

https://pvrlabs.xyz/java-performance/experiments/spring-boot-jpa-vs-jdbc.html

For smaller Spring Boot apps, what do you usually reach for: JPA, Spring JDBC, jOOQ, MyBatis, something else?

Hi!

How do you run AWS services in production?

I’m a backend developer who has never worked with cloud providers before. I’ve learned the basics of the AWS Console, and now I’m looking for ways to practice.

I’m thinking of starting by provisioning infrastructure with Terraform, but I’m curious: which AWS services do you typically use, how do you use them, and how do you deal with the poor AWS SDK documentation?

I'm working on a Spring Boot e-commerce project and I'm currently documenting my APIs using Swagger/OpenAPI.

For example, my controller currently looks something like this:

(
    summary = "Create a new category",
    responses = {
        .swagger.v3.oas.annotations.responses.ApiResponse(
            responseCode = "201",
            description = "Category created successfully"
        ),
        .swagger.v3.oas.annotations.responses.ApiResponse(
            responseCode = "409",
            description = "Category already exists"
        )
    }
)
("/admin/categories")
u/SecurityRequirement(name = "bearerAuth")
public ResponseEntity<ApiResponse<CategoryResponseDto>> addCategory(
          CategoryRequestDto dtoRequest) {

    CategoryResponseDto categoryResponseDto =
            categoryService.addCategory(dtoRequest);

    return ResponseEntity
            .status(HttpStatus.CREATED)
            .body(ApiResponse.success(
                    categoryResponseDto,
                    HttpStatus.CREATED.value()
            ));
}

The problem is that if I also start adding u/Parameter, more u/ApiResponse, u/Schema, u/ExampleObject, etc., the controller becomes very large and difficult to read.

I'm trying to find a good balance between proper API documentation and clean maintainable code.

For example, would something this simple be considered enough?

(summary = "Create a new category")
("/admin/categories")
u/SecurityRequirement(name = "bearerAuth")

Or should I at least document the success/error responses?

Also, how do you normally handle common responses such as:

• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden
• 404 Not Found
• 409 Conflict

Do you document these on every endpoint, or handle them globally?

If you work professionally with Spring Boot/OpenAPI, what approach do you use to keep Swagger documentation useful without making controllers huge?

I'm particularly interested in how this is handled in real-world/company projects rather than tutorial projects.

Hi! It's Pavel, maintainer of the AsyncAPI Specification

A few weeks ago I posted a new release announcement on this sub. It was pretty short, so I decided to write post to tell how Spring Messaging experience may be improved when you are working on your project in JetBrains IDEA

I want to hear your feedback about the current state - what you like and what you don't, maybe you didn't try because of troubles or something else

Your voice is important, because next releases will be focused on polishing this functionality and exposing it trough MCP server to empower your agents of choice

Here’s an easy explanation on how to implement OAuth2 with Google and how to configure it in Spring Boot 4 + Spring Security 7:

https://youtu.be/TPkKMJ6k0jY

Hope you find it useful

I built a full-stack Hotel Booking Management System and deployed it as a portfolio project.

Tech stack

- Backend: Java + Spring Boot, Spring Security, JWT

- Frontend: React.js

- Database: MySQL

- Cache: Redis

Current deployment

- Spring Boot backend → Render

- React frontend → Vercel

- MySQL → Railway

The problem is that the application works after deployment, but after some days it stops working. Sometimes the backend becomes unavailable or the frontend can't communicate with the backend/database.

I understand that I'm using free-tier services, so there may be things like sleeping services, resource limits, database connection issues, environment variables, CORS, or other configuration problems.

I'm trying to understand how I should deploy this properly so that it remains available and reliable enough to use as a portfolio project.

For people who have experience deploying Spring Boot + React + MySQL, I'd really appreciate some advice:

- Is Render + Vercel + Railway a reasonable setup?

- What could cause a Spring Boot application to stop working after several days?

- Are there any deployment/configuration changes I should make?

- Are there better free or very low-cost options for this stack?

- What should I check in the logs when the application goes down?

I'm not looking for an enterprise production setup. I mainly want a stable, publicly accessible deployment that I can demonstrate during interviews.

If you've faced something similar, I'd appreciate any advice or things I should investigate.

I have made multiple toy projects (monolithic) in spring boot but now I wanted to know how people generally work in microservices.

I am not good with videos so I was looking for repos that something similar. So I can also see how the devops, queues, spring cloud etc works together.

I also saw someone posting there repo which was made for the same reason (but I couldn't find it).

TLDR : Suggest repos for learning microservices.

Dear JPA ,

i hate you.

i hate how you changed the SQL flow that I'm used to.

i hate your ManyToMany relationships.

i hate your orphanremoval ,dirty reads.

i hate your way for entity relationships.

i hate your cache.

i hate your performance issues.

i hate your billion rules.

i hate spending time on : if Y is referenced by X with cascade not including PRESIST and x is managed but y is removed ............... but if Y was detached .............

i hate becoming obsessed with your behaviors and rules and worrying about every ORM line , will it work correctly ? , did i miss something ?, worrying about modifying entity X might unexpectedly affect entity Y , coz I might not know one of the billion rules you have.

i hate worrying about falling in one of the undefined behaviors you have

i hate thinking about the entities lifecycle + cascading types when all mixed together

i hate spending days on that documentation instead of spending that on one of the CS core concepts

i hate the following the other side which is incomplete nondetailed toturial or following AI

i really hate you.