yo, i'm trying to build a full-stack app using react on the frontend, spring boot for the backend, and keycloak handling auth, and i kinda need some guidance on how to do it properly instead of just hacking together a basic tutorial setup.

right now i get the general idea of spinning up keycloak and getting a basic login working, but i'm a bit lost on the best practices for real/bigger projects and where to go from here. specifically:

• how are you guys handling tokens on the react side? is storing them in memory/using a BFF (backend for frontend) pattern the move nowadays, or is standard keycloak-js / react-oidc-context still fine?

• on the spring boot side, how do you cleanly sync keycloak users with your own database (like storing extra user profile info, orders, etc.)? do you just use the sub claim from the jwt on every request, use keycloak event listeners, or something else?

• what's the best way to handle roles and permissions across both frontend routes and spring security endpoints without it turning into a mess?

• i asked opencode a bit about how spring boot 4.1 and spring security 7 handles this today, it has like their own prefix config on application.yaml or which is the right way to setup the JWT converter (the role mapping one) since I've tried and it doesnt quite work..?

if anyone has a solid repo structure, workflow, or just tips on how to build out from a basic "hello world" auth setup into an actual production-ready app, i'd really appreciate it. thanks!

I know how to code in JAVA and make basic programs and have basic knowledge of packages and some libraries, but I will still call myself just a little bit more experienced than a beginner, as I regularly need to google and use AI for stuff that I do not understand.

I am also learning DSA in Java only.

I want to know which free resources I should use to learn Spring Boot. I am fine with the resources being either in English or Hindi; both are not a problem for me as long as they are good.

I did some research with the help of AI and some other posts; here is a list of some of them:

1. Amigos Code: It is not in sequential order; it feels like random videos about Spring Boot rather than a structured course to follow, and he even has released a video labeled "Spring Boot course" in 2025 but is not in this playlist.

2. Freecodecamp 12-hour Spring and JPA: 2-year-old, 12-hour-long video. Feels the most trustworthy out of them all due to sheer length.

3. Freecodecamp WebApp using Spring Boot 3: 3-hour-long video, but it jumps directly to building web apps rather than starting from scratch and also does not cover a lot of topics from the above video.

4. Mosh's Spring Boot: A 1-hour-long video that seems too small to cover all topics, so I'm hesitant to use it.

5. Coder Army's course: An Indian YouTuber made a 40-video-long playlist for Spring Boot, but I honestly never heard of this guy to fact-check if he is actually good at teaching, and also some of his videos are behind memberships.

There are also a lot of documentation courses like Spring.io, GfG, and Baeldung. The problem with these is that I feel navigating through these websites is extremely hard, and I can't find a way to just get to the next chapter directly from the current one.

I want to avoid Scaler and Udemy as much as I can, so I did not add them here.

If there is a better comprehensive way to learn, please do tell me!

Or if it is any of the ones I mentioned, just give me a heads-up so I can start ASAP!

My goal is to just learn enough first and then start building on my own, but I want to know one course that I will watch at start that will cover enough so I do not need to worry about not knowing some deep insight into how spring works!

Feedback and missing gotchas welcome

I've been working on a solution to a problem I encountered while building applications with Spring AI.

How do you enforce token and dollar budgets at different levels?

For example:

• A maximum token budget per user.

• Separate budgets for different tenants.

• Request-level limits.

• Atomic budget consumption to avoid race conditions.

• Handling token usage from streaming responses.

I ended up building an open-source Spring Boot starter called Token Allowance to address these problems.

It uses Redis-backed atomic operations and supports token and dollar budgets.

I'd particularly appreciate feedback from developers working with Spring AI on how they're approaching this problem.

I'm the author, so happy to answer questions about the implementation.

GitHub: https://github.com/Ultron03/token-allowance

Token Allowance is an open source Spring Boot starter that gives every user, tenant and request a token or dollar budget for Spring AI calls. When the budget is gone, the API answers 429 with a Retry-After, and nobody else is affected.

Apache 2.0. Java 17+, Spring Boot 4.1, Spring AI 2.0.

What went wrong while building it (races, cached tokens, streaming usage, timeouts):

https://dev.to/ultron03/building-token-budgets-for-spring-ai-the-problems-i-didnt-expect-lg2

Code and demo:

https://github.com/Ultron03/token-allowance

I spent the last few months digging into the OpenID AuthZEN Authorization API, which became a final specification in January 2026. It addresses a problem that anyone who has connected a Spring app to a PDP will recognize. Every PDP (Keycloak, OPA, Cerbos, Topaz, ...) comes with its own API, so the enforcement code ends up tied to one vendor. AuthZEN standardizes that API, so I built an open source Java SDK with a Spring Boot starter on top of it.

With the starter, a handler is protected like this:

@CheckPermission                       // read on {type: "documents", id: <id>}
@GetMapping("/documents/{id}")
Document get(@PathVariable String id) { ... }

@CheckPermission(action = "cancel", resourceType = "order", resourceId = "#id")
@PostMapping("/orders/{id}/cancel")
void cancel(@PathVariable String id) { ... }

Whatever the annotation leaves out is inferred:

• the subject from the authenticated caller in Spring Security (sub claim, type user)

• the action from the HTTP method (read/list, create, update, delete), while CORS preflight requests pass through without asking the PDP

• the resource from the route pattern Spring matched, never from the raw URI, so the way a client spells the path cannot change what the PDP is asked about

Every inferred part can be overridden on its own, in the annotation or in configuration. Routes that cannot be inferred safely, such as /{tenant}/documents, are denied without calling the PDP and reported as warnings at startup. A deny becomes an AccessDeniedException, so your existing error handling keeps working.

The only required setting is authzen.pdp.url. The PEP authenticates to the PDP with its own credential through a CredentialProvider bean, never with the user's token, and anything that prevents a decision (timeout, 5xx, invalid response) means deny.

The starter is a preview for Spring MVC on Spring Boot 4. WebFlux support and an adapter for Spring Security's OAuth 2.0 client are next. For batch decisions, such as a bulk delete, you can inject the client and send one request yourself; the examples repository has a runnable app with a Keycloak realm that shows both.

• Repo: https://github.com/authzenenforcer/authzen-enforcer

• Article with the full background: https://hakdogan.medium.com/an-introduction-to-openid-authzen-and-authzen-enforcer-a-java-sdk-933f2122bdd9

I'd really appreciate feedback on the annotation design and the inference defaults, especially from anyone who has built something similar in-house.

I've been experimenting with resource-efficient Java applications, exploring how much of Spring Boot's familiar architecture can be preserved with smaller frameworks.

I compared five Java stacks on a 1-vCPU, 512 MiB VM with no swap, running MariaDB alongside the application.

The HotSpot tests used OpenJDK 27 with G1 GC. Each stack had two runs, with 1,500 requests per run and no errors.

CoilBase is a small Jdbi-based foundation I'm developing. The Javalin, Jex, and Micronaut implementations reuse the same services, repositories, and transaction boundaries, with different HTTP frameworks and application wiring.

The interesting part wasn't just the memory savings. It was seeing how much of the familiar Spring-style application architecture could remain unchanged when switching frameworks.

I also tested GraalVM Native Image for all five stacks. Runtime memory dropped further, but native compilation introduced additional build time and complexity.

This is a lightweight synthetic workload, not a throughput benchmark or a general recommendation to replace Spring Boot. Spring's ecosystem and conveniences still have real value.

Full experiment, measurements, and limitations:

https://pvrlabs.xyz/articles/five-java-stacks-512mb-vps.html

Source code and benchmark setup:

https://github.com/PVRLabs/experiments/tree/main/java/coilbase-framework-comparison

CoilBase, which I built and used for this comparison:

https://github.com/PVRLabs/coilbase

I'm curious whether others see value in a lighter Java stack that keeps some of Spring Boot's familiar development patterns, or whether Spring Boot's ecosystem and conveniences outweigh the potential resource savings.

Update: Framework versions used in the benchmark

All HotSpot runs used OpenJDK 27 with identical JVM settings: -Xms16m -Xmx80m -XX:+UseG1GC (fixed 80 MiB maximum heap).

CoilBase was an early 0.1.0-SNAPSHOT prototype. I'm working on a more formal, publicly reproducible follow-up benchmark using an updated version of CoilBase, with Quarkus also joining the comparison.

A controller starts calling a persistence adapter directly. The response is still correct; the

dependency direction isn't.

I work on ArchUnitJava. One way to catch that is a package policy over the compiled application:

controller packages must not depend on concrete persistence packages. Run the check in an ordinary

JUnit test, without starting a Spring context for that structural check.

That doesn't validate bean wiring, transaction behavior or runtime-injected implementations.

Keep the Spring integration tests; this checks a different property.

Version 1.0 requires JDK 25 for the analyzer. It's independently implemented, unaffiliated with

the original ArchUnit, and isn't a drop-in replacement for it.

[Compiled-code quickstart]

Which controller shortcut has actually caused trouble in your codebase?

Writing assisted by AI.

Article: https://huseyinbabal.dev/posts/spring-boot-five-jvms-benchmark/

I keep running into the same thing with small Spring Boot projects. The app is tiny, but proper monitoring means a collector, a store, dashboards and alert rules, and that setup ends up bigger than the app. So most of my small projects just ran with no monitoring at all, and I only found out something was wrong when someone told me.

How do you handle this for small services? Do you skip it, use Actuator and look at the numbers by hand, or set up the full stack anyway?

I got curious enough that I tried a different approach: a Spring Boot starter that watches the app from inside. You add one dependency, start the app, and there's a live dashboard at /streamguard/ with per-route request rate, error rate and p50/p95/p99 latency. On top of that it flags error, latency and traffic spikes, and it notices things like repeated failed logins or one client probing lots of paths. Nothing to run next to the app, no database, no agent.

The interesting problem was keeping it cheap inside someone else's app. Rescanning a list of raw requests gets slower as traffic grows, so I cut time into 1-second buckets with counters and a latency histogram. A query merges the buckets in range, so it costs the same however much traffic there was. On my laptop a 15-minute snapshot takes about 70 microseconds, and that stays flat as the window fills. Single run, so take it with a grain of salt.

It's got real limits. It only sees the JVM it runs in, so a scaled-out service gets one view per instance and state resets on restart. It's Spring MVC only for now, and it needs Java 21 and Spring Boot 4.1.

The part I'm least sure about is the detection rules. They're fixed right now (for example, error rate more than 3 times the previous 15 second window counts as a spike), and they look fine on my demo traffic, but I've never run them against a real production service. For those of you who've set up alerting before, do rules like that feel sensible, or do you always end up wanting to tune them per service? And is there anything you'd want from something like this before you'd trust it on a real project?

It's on GitHub if anyone wants to look: https://github.com/eswar-7116/streamguard

Article: https://huseyinbabal.dev/posts/spring-security-google-login-bff-react/

I published the first release of idempotency4j, an idempotency library for Spring Boot, in April. It started with the basic HTTP case: the client sends an Idempotency-Key header, and a retried POST gets the stored response back instead of running the handler a second time. The @Idempotent annotation only worked on Spring MVC controller methods.

Since then the direction has moved toward message-based systems. When services talk over a broker with at-least-once delivery, every consumer sees the same message twice sooner or later. The usual answer is an outbox on the sending side and an idempotent consumer on the receiving side, which keeps services consistent without two-phase commit or a central coordinator. idempotency4j does not ship an outbox. It is built to be the receiving side.

@Idempotent(key = "#event.id()") works on any Spring bean method, so a Kafka listener or an event handler runs once per event id, however many times the broker redelivers it inside the retention window (24 hours by default):

@Idempotent(key = "#event.id()", waitTimeout = "PT0S")
@KafkaListener(topics = "orders")
void on(OrderPlaced event) {
    // Runs once per event id, however many times the broker redelivers.
}

You choose how the idempotency record relates to the consumer's transaction. By default it is written right after the transaction commits, and a rollback frees the key so a redelivery runs again. That leaves one gap: if the process dies between the commit and the record write, the event is processed a second time. With the JDBC store you can set completion = "join-transaction", which writes the record inside the same transaction as your own data and closes that gap. Redis cannot join a database transaction, so it only has the default.

Records live in PostgreSQL, MySQL or Redis, and the HTTP filter is still there.

None of this makes a call to someone else's API exactly-once. For that the downstream service needs its own idempotency key.

Two things happened this autumn that I did not expect.

I opened the Maven Central stats after ignoring them for a while and saw more than 100 unique downloads. Those are builds I have nothing to do with.

And at the end of October Vinícius (vinirib on GitHub) opened four issues in one day, and a fifth the next day. Three were about running the library in a real application: how it starts next to Actuator, what an app that only uses Redis needs on its classpath, and what Retry-After a client should get when its duplicate arrives while the first request is still running. The other two proposed extension points. One lets you answer in your API's own error format when the filter rejects a request. The other decides per response whether it is stored, or the key is released so the client can retry.

Then he sent a pull request for every one of them, five in two days. 0.6.0 went out on November 3 and it is mostly his work.

The Spring Boot starter needs Spring Boot 4 and Java 21.

Repo: https://github.com/josipmusa/idempotency4j

Docs: https://josipmusa.github.io/idempotency4j-docs/

So I am studying Spring and SpringBoot through this book - Spring Start Here. Usually I feel like the book overexplains things with multiple examples differing in minute ways, but there is some code in Chapter 9 - Using Spring Web Scopes, that I do not understand and the author surprising doesn't dive deep into.

RequestScope was being explained and as far as I can tell it is like Prototype scope where Spring manages the type, and instantiates a fresh new bean every time someone requests a bean, and this bean exists for the duration of the HTTP request.

But how does this work when the bean is injected into another bean that has Singleton scope? Presenting the code shown in the book below:

@Controller
public class LoginController {

  private final LoginProcessor loginProcessor;

  public LoginController(LoginProcessor loginProcessor) {
    this.loginProcessor = loginProcessor;
  }

  ("/")
  public String loginGet() {
    return "login.html";
  }

  ("/")
  public String loginPost(
      @RequestParam String username,
      @RequestParam String password,
      Model model
  ) {
    loginProcessor.setUsername(username);
    loginProcessor.setPassword(password);
    boolean loggedIn = loginProcessor.login();

    if (loggedIn) {
      model.addAttribute("message", "You are now logged in.");
    } else {
      model.addAttribute("message", "Login failed!");
    }

    return "login.html";
  }
}

@Component
@RequestScope
public class LoginProcessor {

  private String username;
  private String password;

  public boolean login() {
    String username = this.getUsername();
    String password = this.getPassword();

    if ("natalie".equals(username) && "password".equals(password)) {
      return true;
    } else {
      return false;
    }
  }

  // Getters and Setters
}

In this example, the Controller bean is going to be instantiated once during the app startup, and considering that the loginProcessor field is final and only injected during bean instantiation, how is it able to use a new loginProcessor bean for each request? This code works, but I don't understand how.

Most call graph tools stop at the interface. You call orderService.place() and the diagram shows OrderService, not the class doing the work.

Call Sketch is a JetBrains plugin I built, and its Pro version follows the Spring wiring to the real bean. It also draws if/else and loop boxes, so you see when a call happens and not only that it does.

Free version covers Java and Kotlin with any depth and click to jump to code. Pro is $7 a year with a 30-day trial.

https://plugins.jetbrains.com/plugin/35865-call-sketch-sequence-diagrams

A common surprise: you annotate a method with @ Transactional, call it, and it behaves as if the annotation weren’t there. One frequent cause is calling the method from another method in the same class. Instead of taking my word for it, you can check in a few lines.

public class ReportService {

    public void viaThis() {
        save();                      // internal call
    }

    u/Transactional
    public void save() {
        System.out.println("tx active: "
            + TransactionSynchronizationManager.isActualTransactionActive());
    }
}

Now call both from somewhere else (a controller, a test, a CommandLineRunner):

reportService.save();      // direct call from another bean
reportService.viaThis();   // goes through the same class

What I’d expect to see (please run it on your version to confirm):

tx active: true     // from save()
tx active: false    // from viaThis() -> save()

Why this happens (as I understand it):
By default, Spring applies @Transactional through a proxy that wraps the bean. A call from another bean goes through the proxy, which opens the transaction. A call from inside the class uses this, which is the raw object and skips the proxy, so the annotation is never applied.

Common ways around it:

• Move the transactional method to a separate bean and call it through that bean. This is the option most people recommend because it’s the least surprising.

• Put u/Transactional on the outer method instead, if the whole operation should be one transaction anyway.

• Use TransactionTemplate for programmatic control.

• Use AspectJ mode (mode = AdviceMode.ASPECTJ), which weaves the behavior into the class itself and doesn’t depend on the proxy. It needs extra build or runtime setup, so it’s a bigger step.

• Injecting the bean into itself also works, but many consider it a code smell.

Caveats:

• The details depend on your Spring version and proxy type (JDK vs CGLIB), and on method visibility, so check the reference docs for the version you use.

• The same proxy limitation applies to other annotations implemented through AOP, like @Async and @Cacheable.

• An exception thrown inside the “transaction” in the broken case won’t roll anything back, which is why this bug can stay silent.

Has anyone found a pattern for catching this earlier than “the data was inconsistent in production”, like a test, a lint rule or a startup check?

GitHub: https://github.com/somewhereMaDan/spring-RCE

While building my Remote Code Execution (RCE) platform, I initially used Redis Lists for job processing.

It worked, but I eventually encountered a reliability issue: if a worker was killed with SIGKILL after popping a job, that job could be lost permanently, leaving the client stuck in RUNNING state.

So I decided to move to Redis Streams and implement a more fault-tolerant workflow.

Here's what I implemented:

* **Consumer Groups & PEL:** Jobs remain recoverable until acknowledged with XACK.

* **Stale Job Recovery:** Workers reclaim unacknowledged jobs from crashed consumers using XCLAIM.

* **Orphaned Container Cleanup:** Added an execution-level timeout so containers don't run indefinitely if their worker disappears.

* **Duplicate Container Protection:** Clean up an existing container before retrying the same job.

* **Dead Letter Queue:** Jobs exceeding 3 delivery attempts are moved to a separate stream instead of being retried indefinitely.

I also tested worker failure scenarios, including unexpected SIGKILL, SIGTERM, stale job recovery, repeated failures, and container cleanup.

How do you handle orphaned executions and duplicate processing in your distributed worker systems?

Would love to hear how others approach this.

Hi friends,
I started learning spring boot about 4 months ago through reading, and about a month ago started getting hands-on experience with a personal project, my stack is spring boot backend, no front end for now but I’m planning to add a simple angular page together eventually.

I find myself confused and interested in learning the following things that I am not sure where to start with and how crucial they are.

I find myself overwhelmed by spring boot’s configuration beyond the auto-configuration. There are many properties that can be configured, and while I know there is no point in knowing all of them but rather what I need, it feels intimidating.

I also find that most projects and books that I stumble upon online are Spring Boot 3, while my project is Spring boot 4. Am I wrong for using the most recent technologies? How do I find/understand current implementation when the book has the older version of it? How do I go about knowing both in case I stumble upon a “legacy” system in the work place or even open source contributions. An example I stumbled upon was implementing OAuth2, where configuration was completely different.

Is redis/cache commonly used with redistemplate, or is it more common to use the caching annotations(@cacheable, @cacheput, @cacheevict, etc).

I also wanted to ask about configuring ci/cd with a java/spring project, but I wasn’t sure if it follows community guidelines to do so.

Any additional advice is welcome and highly appreciated.

Thank you!

I have decent hands on experience in java and java is my main language too.

How do I start learning springboot.

Recently started watching coder army tutorials but he went too in-depth that it went mostly over my head and went boring.

How do I learn hands on in spring boot?

where should I start?

Also please share any resources.

Hey everyone,

As a Java Principal Architect, one of my recurring pain points is the compliance risk and Day-1 friction of bootstrapping new projects. In strict corporate environments, utilizing cloud-hosted LLM APIs to draft initial scaffolding or internal schemas poses massive data privacy and IP leakage risks.

To solve this within the host perimeter, I built OllamaSprout—an automated accelerator designed to translate plain-text domain requirements into production-ready, ready-to-run Java services out-of-the-box.

🚀 What it does

It streams code from a local model and programmatically compiles a complete, valid Maven directory tree directly onto your disk. It generates fully realized structural layers: Controller ➡️ Service ➡️ Repository ➡️ JPA Entity with 100% written code (absolutely zero trailing ellipses ... or // TODO shortcuts).

🛠️ The Architectural Stack

• Framework: Spring Boot 3.x

• AI Integration: Spring AI

• Local Inference Engine: Ollama running qwen2.5-coder:7b

• Language & Build: Java 21 & Maven

🧠 Deep-Tech Optimization Highlights

• Resource Preservation (RAM Reclaiming): To ensure a developer's workstation remains unburdened, the system includes custom orchestration to ensure that once the generation process completes, the system completely reclaims the heavy memory footprint occupied by Ollama.

• Deterministic Parsing & Disk I/O: Safely translates streamed markdown multi-file blocks into structured directories on disk with exact package boundary alignments.

• Eclipse/IntelliJ Target Compliance: The generated pom.xml uses root schema tags tailored specifically to satisfy Eclipse's offline cache validation rules, avoiding compilation hiccups during network-isolated imports.

🔮 Architecture Roadmap

The application's core state model is abstractly structured to support iterative modular growth. The next milestone is allowing developers to point the tool at an existing codebase to inject new controller/service slices or database entities programmatically.

💻 Source Code

The project is licensed under Apache-2.0 and includes the full engineering story, validation endpoints, and environment configurations: 🔗 https://github.com/tpkani2026/ollamasprout-bootstrapper.git

I’d love to get your architectural feedback on the scaffolding strategy, your thoughts on localized AI generation patterns for corporate stacks, and how you see local model orchestration fitting into the enterprise SDLC!

I’ve submitted a Spring AI contribution addressing input-error recovery for method-backed tools using returnDirect=true.

The issue: malformed JSON or invalid typed arguments can become the final response, preventing the model from correcting its input. Missing/null primitive arguments and top-level JSON null can also bypass the exception processor.

The proposed fix distinguishes input parsing/binding failures before execution and sends processed error feedback back to the model. Successful corrected calls still return directly, while ordinary tool-body and result-conversion failures retain their existing behavior.

Validation:

- All 38 new regression cases passed, covering blocking/streaming, direct return on/off, and mixed-success batches.

- Scoped clean package build: 2,030 tests reported, 10 skipped, zero failures or errors.

- Negative control: the original code failed 20 of the initial 32 checks, including checks for the new exception classification; the patched code passed the same cases.

No external LLM calls were needed. External-provider integration tests and the full repository build were not run. Developed with AI assistance and reviewed before submission.

PR submitted for maintainer review: https://github.com/spring-projects/spring-ai/pull/7292

Feedback on the input-error boundary and recovery behavior is welcome, especially from anyone using direct-return tools.

#SpringAI #SpringFramework #Java #OpenSource #SoftwareTesting