DEV Community: David Brown

gRPC moved into Spring Boot 4.1: the new starters, the property renames, and what we measured

David Brown — Wed, 22 Jul 2026 07:28:57 +0000

Spring Boot 4.1 went GA on 10 June 2026, and its biggest change for service-to-service work is that gRPC support moved into Spring Boot itself. The spring-grpc 1.1.0 release notes state it in a single line: "The main change in 1.1.0 is the migration of autoconfiguration to Spring Boot 4.1.0."

Concretely, the starters you add to a build are now Boot's own:

org.springframework.boot:spring-boot-starter-grpc-server
org.springframework.boot:spring-boot-starter-grpc-client
org.springframework.boot:spring-boot-starter-grpc-server-test
org.springframework.boot:spring-boot-starter-grpc-client-test The spring-grpc project lives on as the programming model: spring-grpc-core:1.1.0 supplies @GrpcService, @ImportGrpcClients and GrpcChannelFactory, and it arrives transitively. You never declare spring-grpc in your build. The old org.springframework.grpc starters are deprecated, with the 1.0.x artifacts still on Maven Central for projects pinned to Boot 4.0.

When the merge was announced in November 2025, the plan included explicit migration guidance at release time. What exists as I write is a draft wiki page, and the tutorials that rank for the topic still teach the old coordinates or the abandoned net.devh starter; Baeldung's guide still declares Boot 3.4/3.5 support. We built a complete server and client on 4.1.0 GA for a full tutorial on our blog; this post is the condensed version of what changed and what we found.

The property renames

The property tree was restructured as well as re-homed. These are the renames most likely to bite when you migrate a spring-grpc 1.0.x project:

spring-grpc 1.0 (Boot 4.0)	Spring Boot 4.1
`spring.grpc.client.channels.<name>.address`	`spring.grpc.client.channel.<name>.target` (singular `channel`, `address` becomes `target`)
`spring.grpc.client.channels.<name>.default-deadline`	`spring.grpc.client.channel.<name>.default.deadline`
`spring.grpc.server.keep-alive.*`	`spring.grpc.server.keepalive.*`
`spring.grpc.server.max-inbound-message-size`	`spring.grpc.server.inbound.message.max-size`
`spring.grpc.server.address` (combined `host:port`)	`spring.grpc.server.address` (address only) plus a separate `spring.grpc.server.port`
`spring.grpc.server.health.actuator.*`	Removed; health is configured under `spring.grpc.server.health.*`

Each of these was checked against the 4.1.0 GA jars and the migration guide while building the project.

The build file delta is zero lines

This was the finding I expected least. The Spring Initializr skeleton applies com.google.protobuf version 0.9.6 with no protobuf{} block and no codegen configuration at all. Drop a .proto file into src/main/proto/ and the build generates both the message classes and the gRPC service stubs.

It works because Boot 4.1's Gradle plugin ships a ProtobufPluginAction that reacts to the protobuf plugin being applied and configures the protoc artifact (4.34.2, aligned with the managed protobuf-java), the io.grpc:protoc-gen-grpc-java codegen plugin (1.80.0, aligned with the managed gRPC BOM), and a resolution strategy keeping them in step with the runtime classpath. Every pre-4.1 tutorial showing a 20-line protobuf{} block is describing configuration this setup no longer needs. Across the whole project, server and client, build.gradle never changed from the skeleton.

What runs before you configure anything

With spring-boot-starter-grpc-server on the classpath and one @GrpcService class, startup gives you a Netty gRPC server on port 9090 alongside Tomcat, reflection registered by default (grpcurl works with just -plaintext), and grpc.health.v1.Health answering SERVING out of the box, bridged from Boot's health system when actuator is present.

One default deserves attention: spring.grpc.server.observation.enabled is true, so an ObservationGrpcServerInterceptor instruments every call even when nothing consumes the observations. In our A/B it cost roughly 20 to 25% of gRPC throughput with no collector attached (a single clean measurement pair, so treat the exact percentage as indicative). If you export metrics or traces you're paying for something you use; if you don't, that property is the off switch.

The benchmark

We measured unary REST (Spring MVC, JSON) against unary gRPC on the same running process, same H2-backed repository, same row, with k6 and ghz in four order-balanced pairs, both protocols seconds apart within each pair. Median run: REST 1,613 req/s with p50/p95/p99 of 7.0/27.4/38.0ms; gRPC 1,926 req/s with 7.9/14.0/19.7ms. That is about 19% more throughput and roughly half the tail latency, with medians close to equal.

The environment note belongs next to the numbers, so here it is: this ran on a shared, virtualised 2-vCPU sandbox whose two vCPUs are hyperthread siblings of one physical core, with invisible host throttling we controlled for using a fixed-work CPU probe. The ratios between the two protocols under identical conditions are the result; the absolute figures describe that box and nothing else. The full methodology, fairness notes and raw outputs ship with the code.

The full version

The complete tutorial adds TLS with SSL bundles, error handling with @GrpcAdvice, in-process and real-transport testing, OpenTelemetry tracing with a verified client-to-server trace, and a server-streaming demonstration: gRPC in Spring Boot 4.1: The New Auto-Configuration, End to End. All the code, benchmark scripts and raw results are in the companion repo.

Building a multi-step AI agent in Java with Spring AI 2.0

David Brown — Tue, 30 Jun 2026 19:02:21 +0000

I wanted to try Spring AI's agentic tooling on something that resembles a real production project rather than the usual weather-API call, so I built an example Spring Boot API: a civic research assistant. You give it a plain-English issue and a UK postcode, and it works out the most effective way to raise that issue with Parliament. It uses an LLM (ChatGPT) along with the free UK postcode and Open Parliament APIs. The flow isn't dictated in code. We register a handful of @Tool methods (resolve the postcode, find the MP, search bills, find committees and open inquiries, check the voting record) and let the model decide which to call and in what order. It chains them itself and returns a final answer with a citation on every claim. The stack is Java 25, Spring Boot 4.1 and Spring AI 2.0.
The full tutorial walks through the Spring AI 2.0 tool-calling setup and what changed since 1.x, registering the tools, getting structured typed output back instead of free text, and a small guard that checks every citation actually came from a tool call so the model can't quietly invent a source. It's all runnable, with the complete code on GitHub.

Full tutorial: https://tucanoo.com/building-an-agentic-workflow-in-java-multi-step-ai-agents-with-spring-ai-and-tool-calling/
Source: https://github.com/tucanoo/spring-ai-civic-research-assistant

If you're using Spring AI's tool calling on anything that touches real data, I'd be interested in how you're handling grounding to keep the model from citing things it never fetched.

The Big Beautiful Bot - A Spring Boot & LLM Chatbot with SSE -> Next.js

David Brown — Fri, 26 Jun 2026 07:16:09 +0000

There's not much material out there showing how to use SSE (Server-Sent Events) with a Spring Boot back end connected to an LLM to power a ChatGPT-style Next.js front end, so I put together a full tutorial on it, with the complete code repository as always.

Tutorial -> https://tucanoo.com/streaming-llm-responses-end-to-end-a-spring-boot-sse-backend-and-a-next-js-frontend/
Repo -> https://github.com/tucanoo/streaming-llm-spring-next

Virtual Threads in Spring Boot 4: I rewrote a blocking service and measured everything

David Brown — Sun, 21 Jun 2026 09:52:15 +0000

I took one realistic blocking Spring Boot 4 service — a PostgreSQL query through HikariCP plus a downstream HTTP call — flipped spring.threads.virtual.enabled=true, and benchmarked exactly what changed: throughput, tail latency, and where the bottleneck went.

TL;DR: ~6× throughput at 2,500 concurrent users from one flag — but the connection pool quietly becomes your new ceiling, so you have to resize it. I also measured the JEP 491 pinning change (the "avoid synchronized" advice is now out of date).

Full write-up, raw data, charts and a reproducible repo on the Tucanoo blog

👉 https://tucanoo.com/virtual-threads-in-spring-boot-4

Localised notifications with Firebase cloud messaging (FCM)

David Brown — Wed, 09 Nov 2022 09:08:05 +0000

If you need to send localised push notifications from a Java server side application to mobile devices with Firebase Cloud Messaging (FCM), whether your server side is Grails, Spring boot or any other Java based framework utilising the Firebase (Admin) SDK then search no more as it's not so clear in the official documentation. Most examples focus on the REST or JS implementations.

In my use case, I wanted to alert users subscribing to a specific Topic of a particular event. Users of this app are distributed globally so it was important to localise the messages depending on the users locale according to their device. From the server side, I just want to generate the notification and let Firebase's servers handle the notifications to each device subscribed to the topic and then the device it self display a locales message, both the title and subtitle, on both Android and IOS devices.

Fortunately Firebase lets us do this by specifying localised 'keys', instead of specifying the title and body. However finding an example was more of a struggle as the documentation is somewhat lacking.

What we have to do is establish Options objects for each platform, i.e. one for Android and one for Apple devices and then deep within nested Builders we can finally set the localised keys. These then can be interpreted from the resources within the mobile App itself and will be displayed to the user, both when the app is in the foreground AND also when it's in the background.

So without further ado, let's look at the code:

Note: I'm omitting the rest of the app code assuming you already know how to setup Firebase etc and just need to see how to generate the notification.

void sendLocalisedNotification(String topic, String titleKey, String bodyKey) {
        // Set localisation key for Android
        AndroidConfig androidConfig = AndroidConfig.builder()
            .setNotification(
                AndroidNotification.builder()
                    .setTitleLocalizationKey(titleKey)
                    .setBodyLocalizationKey(bodyKey)
                    .build()
            ).build()

        // Set localisation key for Apple devices
        ApnsConfig apnsConfig = ApnsConfig.builder()
            .setAps(Aps.builder()
                .setAlert(ApsAlert.builder()
                    .setTitleLocalizationKey(titleKey)
                    .setSubtitleLocalizationKey(bodyKey)
                    .build()
                ).build()
            ).build()

        Message message = Message.builder()
            .setTopic(topic)
            .setAndroidConfig(androidConfig)
            .setApnsConfig(apnsConfig)
            .build();

        // And then send the message to the devices subscribed to the provided topic.
        try {
            String response = FirebaseMessaging.getInstance().send(message);

            // Response is a message ID string.
            log.debug("Firebase message $topic sent: " + response);
        } catch (Exception ex) {
            log.warn("Firebase message $topic failed: " + ex.message);
        }
    }

So that's the gist of it, this method can be called with the topic we want to publish to, the title key and the body key.

I hope this helps save someone time discovering how to accomplish localised messages under a Java environment using the FCM SDK.

Dave / Tucanoo Solutions

Super Fast Prototyping with Grails Tutorial Available

David Brown — Wed, 12 Feb 2020 08:39:54 +0000

One of the greatest benefits of the Grails framework is how it allows you to put together a Proof Of Concept(POC) or a web app prototype in such a short period time.

In a current world where there is lots of focus on UI frameworks and microservice architectures, sometimes, you just need to build something quickly without worrying about different front and backend layers.

Grails allows you to build apps fast, but with the benefit of sitting on top of the most robust Java-based libraries in existence, Spring, Hibernate, etc. etc.

In this tutorial, you'll see how to build a simple CRM backed by a H2 in-memory database, prepopulating itself with 1000 fictitious records.

The user is provided with basic CRUD screens, create, edit, and a rich Datatables based list screen to allow filtering, sorting and ajax driven paging of the customer records.

Download full source on github Download the full source on github

and Read the full tutorial