Creating RESTful APIs with Spring Boot is a straightforward process, making it a popular choice for a variety of applications, from UI to batch processing. The same API created can be used anywhere, whether it’s called from a UI application or batch applications. However, testing these APIs to ensure they work correctly can be challenging. In this article, I’ll introduce …
I am assisting a client that is migrating from a monolithic legacy application to a modern Microservice stack with Spring REST. We are helping to implement Swagger UI to provide both a front-end API UI, as well as to provide a level of documentation at the same time. This implementation has simultaneously met our project requirements, as well as garnering some positive feedback from our client!
Swagger UI is one of the most popular tools to visually render beautiful, interactive API documentation. In this blog, I’ll use a REST API application to demonstrate some usage of Swagger UI. The source project is available at https://github.com/bingliu2016/spring-boot-rest-swagger2.
In past blogs, I have discussed development containers (dev containers) in detail, from explaining their general mechanics to showing how they can bolster a team’s build automation. As a brief recap for the uninitiated: dev containers are a way of encapsulating a developer’s setup into a container, typically a Docker container. As a practical example, rather than forcing a new teammate to manually install and configure all the necessary tooling before contributing to a project, they can leverage a team’s devcontainer.json definition file to quickly spin up a fully configured development environment.
Microsoft has championed this workflow over the past few years, offering tight integration with tools like VS Code and Codespaces to make containerized development as seamless as possible. At the time of writing, the developer experience has reached a point where I honestly prefer to operate within a dev container for certain types of projects. When I open a team’s codebase within VS Code and it informs me that they have provided a dev container to use, I have higher confidence that I’ll be using the same versions of their tools and seeing the behaviors that they expect.
I’ve even come to trust these setups more than an equivalent set of Dockerfiles or docker-compose scripts, just because the simplicity of the ecosystem makes it more likely that everything is well-maintained and configured correctly. It’s easy to see how these standardization and automation benefits can be a huge boost to teams…once they’ve adopted the right tools to integrate with them.
But what if you don’t want to use VS Code?
Test coverage is a metric that measures how much of your codebase is exercised by tests, providing insight into the effectiveness of your testing efforts. In this blog, we’ll focus on API projects, exploring the types of tests suited for code coverage, realistic goals (and tools to help achieve them), and the minimum coverage needed to reap the benefits of your tests.
Testing your code—down to individual lines—is a critical practice in modern software development. It helps ensure applications remain reliable, stable, and maintainable, all while balancing practical constraints.
Over the years, we’ve seen many approaches to HTTP API design. While REST APIs are still very popular throughout the industry, they offer no inherent guarantees that the client’s assumptions about the response structures will be valid.
GraphQL fills this gap to an extent by allowing client-side code greater control over the resulting structures but at the cost of added complexity. RPC (remote procedure call) frameworks attempt a different solution by sharing generated type definitions between the client and server implementations. What if there was a way to achieve the type safety of RPC by simply inferring the type definitions from the server’s code?
Enter tRPC. Since JavaScript (and specifically TypeScript) can already span across client and server implementations, tRPC allows a client to directly consume structures defined by the server’s exposed procedures. Essentially, you import your dependencies from the server to access these procedures, their return types are inferred and checked at build time, and your client code can confidently consume the returned data.
In this post, we’ll look at how it achieves these goals and what limitations it places on your project stack.
