It's a few months since we had a blog about Spring gRPC that wasn't just a release announcement. This one marks the first release since the project was promoted from experimental to a full member of the Spring Portfolio. This doesn't change the way you consume the project, but it has some implications for support and symbolically for what the project now means to the portfolio.

The latest release is 0.8.0, and it has been available for a couple of weeks now in Maven Central. The main reason for that release was to bump the dependencies to their latest versions, bringing Spring gRPC up to version 4 of the protobuf-java libraries. The easiest way to get started is to download a project with "gRPC" checked on the Spring Initializr. There are separate "starters" for Spring Boot applications gRPC that want to be "servers" or "clients", or you can get both at once from the plain spring-grpc-spring-boot-starter…

On behalf of the team and everyone who has contributed, I'm happy to announce that Spring gRPC 0.8.0 has been released and is now available from Maven Central. This is the first "non-experimental" release, signified by the project moving to its new repository location in the https://github.com/spring-projects organization. Support will be provided for the only current 0.x release, and the normal cycle of extended support will start with the 1.0.0 release (expected around the same time as Spring Boot 4.0.0).

The main change in this release was to upgrade Spring Boot and also the gRPC Java and…

On behalf of the team and everyone who has contributed, I'm happy to announce that Spring gRPC 0.6.0 has been released and is now available from Maven Central.

The main change in this release was to rename the annotation for creating gRPC client beans to @ImportGrpcClients, harmonizing with the work on HTTP interface clients in Spring Framework. This release includes features, bug fixes, documentation improvements, and dependency upgrades. Thanks to all those who have contributed with issue reports and pull requests.

How can you help?

If you're interested in helping out, check out the open issues. If you have general questions, please ask on Stack Overflow using the spring-grpc tag…

On behalf of the team and everyone who has contributed, I'm happy to announce that Spring gRPC 0.5.0 has been released and is now available from Maven Central.

This release includes features, bug fixes, documentation improvements, and dependency upgrades. Thanks to all those who have contributed with issue reports and pull requests.

How can you help?

If you're interested in helping out, check out the open issues. If you have general questions, please ask on Stack Overflow using the spring-grpc tag.

GitHub | Issues | Documentation | Stack Overflow

The experimental Spring gRPC project released its 0.3.0 version recently. Jars are available in Maven Central, and you can generate a new project with Spring gRPC at https://start.spring.io. We recommend you do that if you are trying it out because there are some build plugins to configure and the generated project will have that all sorted out for you.

The new release has some updates to factory interfaces on the client side. Also there is now full support for autoconfiguration of client side interceptors, including the ones from Micrometer. On the server side we now support Spring Security…

A few Java libraries have shown up recently that use text templates, but compile to Java classes at build time. They can thus claim to some extent to be "reflection free". Together with potential benefits of runtime performance, they promise to be easy to use and integrate with GraalVM native image compilation, so they are quite interesting for people just getting started with that stack in Spring Boot 3.x. We take a look at a selection of libraries (JStachio, Rocker, JTE and ManTL) and how to get them running.

The source code for the samples is in GitHub and each template engine has its own…

Front end development these days is dominated by large JavaScript client side frameworks. There are plenty of good reasons for that, but it can be very inefficient for many use cases, and the framework engineering has become extremely complex. In this article, I want to explore a different approach, one that is more efficient and more flexible, built from smaller building blocks, and well-suited to server side application frameworks like Spring (or similar tools in a range of server side languages). The idea is to embrace the concept of hypermedia, imagine how a next-generation browser would…

Part 1

Plain Javascript with SSE Stream

Vue isn’t really adding a lot of value in this simple HTML replacement use case, and it would add no value at all to the SSE example, so we will go ahead and implement that in vanilla Javascript. Here’s a stream tab:

<div class="tab-pane fade" id="stream" role="tabpanel">
	<div class="container">
		<div id="load"></div>
	</div>
</div>

and some Javascript to populate it:

<script type="module">
	var events = new EventSource("/stream");
	events.onmessage = e => {
		document.getElementById("load").innerHTML = e.data;
	}
</script>

Dynamic Content with React

This article explores the different options that Spring Boot developers have for using Javascript and CSS on the client (browser) side of their application. Part of the plan is to explore some Javascript libraries that play well in the traditional server-side-rendered world of Spring web applications. Those libraries tend to have a light touch for the application developer, in the sense that they allow you to completely avoid Javascript, but still have nice a progressive "modern" UI. We also look at some more "pure" Javascript tools and frameworks. It’s kind of a spectrum, so as a TL;DR here…

If you have an application that connects to an RSocket server at runtime, how do you test it? We need a way for a test to start a server and tell us where it is listening, and then we need to be able to register request and response examples (a.k.a. "contracts"). That’s what this project provides - it’s like Wiremock but for RSocket.

Getting Started

The easiest way to use the project is as a JUnit (Jupiter) extension, e.g:

@SpringBootTest
@ExtendWith(RSocketServerExtension.class)
class SocketsApplicationTests {
	...
}

With this extension installed the Spring Boot tests will run with an RSocket server listening on a port given by test.rsocket.server.port, so the test can connect directly to it, or (more likely) the code that it is testing will connect to it. You might need to tell it where to connect via the @SpringBootTest annotation, e.g. if the application is looking for a property at runtime called rsocket.port…