DEV Community: Arpit

State of Spring survey 2021

Arpit — Wed, 10 Nov 2021 11:31:20 +0000

VMWare recently did a survey of over 1500 individuals who use Spring for their "State of Spring 2021", which you can view here.

I read the survey and here are a few things that I learnt from it.

Spring (esp. Spring boot) positively impacts developer productivity

Most users (95%) said that Spring boot increases the developer productivity hugely. Similarly for Spring, overall, most developers agreed that it increases the productivity, more than other Java platforms.

Also, in terms of who knows most about Spring in the team, most people said, they do not have a Spring specialist (34%), which I agree with as well. I think since Spring is a framework, rather than a language, most teams leverage their developers, architects, etc. to be up to date on the new features of Spring, and related projects, rather than having someone dedicated for this role. But this also means, each company, needs to make sure, they give their developers enough space, time and resources, to keep themselves updated of the things happening in the spring community.

Where do people find answers

For a majority of developers, stackoverflow.com is the way to go for any questions about spring. Spring official documentation on spring.io is a close second. Close to 70% developers still go to the official documentation, which I think is a pretty good number. But VMware acknowledged that they need to focus more on creating demos and improving the docs. The fact that there are multiple resources apart from the official documentation and stackoverflow, it's surprising that they didn't come up as an answer in the survey. If they do publish the raw data, I'm sure we'll find many people who leverage these in their day to day.

Shiny new modules

Developers love the new shiny modules spring continues to come up with. Half of them said, that's one of the reasons they stay with spring. 39% said they would add new modules to their existing or new projects in the near future. It speaks to the fact that spring keeps up to date with new tech, and keeps adding integrations for them. And who doesn't like a new lego block in their toy box.

Give me more data !

Spring data is the most popular module, which suggest a lot of database integrations, mostly relational. Although noSQL also seemed to be close behind with Mongo, Redis and Elastic.

Spring security is as popular as spring data, which is good, since that means people are keeping their applications secure!

About picking a new module, or Spring project, people consider documentation and maturity as the main factors.

Another thing that came out, as a winner, is Kotlin ! More than 90% of the surveyors have a positive view about it and ~60% plan to learn or use it for their projects.

We want more APIs !

Although REST, SOA has been around for very long, the primary use-case for Spring and Spring Boot is still creating and exposing API to internal and external consumers.

Also, a large percentage of people use Modern architectures - like microservices, API management, API Gateways, observability, etc. for their application architectures.

A lot of people are also considering and using GraphQL (20%) and Spring already has an integration with it.

Native is the new cool kid ?

Spring Native is the newly launched module that allows your Spring applications to start quicker, reduce memory footprint, which has been one of the bigger complaints by developers using Spring. Native solves these issues and seems like a lot of the developers are eagerly reading up on it. The adoption is not still 3%, but it's an early project, so I would not judge this yet. Also, the fact that it's still in Beta and possibly not mature enough, is holding people back for now. A third of people also have issues with the build time, but that is improving and that is essentially the cost you pay for getting a fast startup.

But a lot of people (58%) plan to deploy it in the next few months to a couple of years, which is great adoption for such a new project.

In Summary...

I think Spring and Spring Boot specifically, is here to stay, because of its ease of use, developer productivity, excellent and always improving documentation and a massive user group. A LinkedIn group called Spring Users, has more than 90,000 members, which speaks about the sheer number of people either using, learning or planning to use it.

Article originally published here

Dynamic health-checks with spring boot

Arpit — Mon, 08 Nov 2021 19:28:50 +0000

Health-check is an important part of any project that you create. You can deploy your service, and expose an endpoint that emits its health periodically. These endpoints could be called from your container, your dependent clients, your cloud deployment infrastructure, etc. As long as the service is healthy or "UP", the consumers are happy. When it goes down, the consumers can either pivot to something else, or show an error to the end user to wait till it's back up.

Dynamic Health-checks

Let's imagine you have a use-case, where your spring boot application is already up, and its talking to other systems, and you want to register a new health endpoint while your application is running. Spring boot will already give something like this already out of the box -

{
  "status": "UP",
  "components": {
    "ping": {
      "status": "UP"
    }
  }
}

So, the application is up and running now, and there is a new dependency that you have identified, that you want to register. Usually, the health-checks are static - either configured in the yaml / properties file or defined as part of your code by implementing HealthIndicator.

But, there is another way to register a health indicator, while the system is running, this is using HealthContributorRegistry. Spring boot gives you this from the application context, so you can Autowire it in your bean.

@SpringBootApplication
public class Application {

    @Autowired
    HealthContributorRegistry healthContributorRegistry;

    public static void main(final String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

Once you get the object, there are really simple methods to invoke to register or unregister contributors to your application while its running.

healthContributorRegistry.registerContributor("myNewService", new MyNewServiceImpl());

Your MyNewServiceImpl.java should implement HealthIndicator.

{
  "status": "UP",
  "components": {
    "ping": {
      "status": "UP"
    },
        "myNewService": {
      "status": "UP"
    }
  }
}

You can also unregister it, if you want to remove something at runtime.

healthContributorRegistry.unregisterContributor("myNewService");

Hope this helps you, your application and your application's consumers stay healthy 🙂

Spring Boot documentation
Originally published here

Improve your APIs with Optic

Arpit — Wed, 28 Oct 2020 23:59:14 +0000

If you are an API Developer or an API consumer, you know how important it is to keep your contracts up-to-date all the time. If you change something and don't update the contract, someone somewhere gets mad 😡 !

So here's a tool to help make friends of API consumers 👫 .

What?

Optic is a "Git-like version control system for API contracts". It makes it easier to create API documentation and update it as you go on merrily change your API request and response. All you have to do is review the change and approve it.

Installation

You can install the CLI as an npm global package or using homebrew.

It works with most of the languages - Java, NodeJS, Go, Rust, etc.

How?

Optic uses a proxy to monitor the API over the network. It detects any change in your API and suggests changes in your API documentation.

You navigate to your Project's root and run

api init

This creates a optic.yml in your project that you then navigate to and update with a couple of things

command - Command that runs your API Project. You also need to set the server port to be $OPTIC_API_PORT. This is a sample for a Maven Java project
```
export SERVER_PORT=$OPTIC_API_PORT; mvn exec:java -Dexec.mainClass="com.test.Application"`
```
inboundUrl - Your API hostname and port. Like http://localhost:8080

Then there is a way to check if your configuration is working ok.

api check start. The check prefix verifies your configuration and then start starts the API.

There are a few other commands to help API developers

api generate - This generates an Open API documentation that you can then use to host somewhere and have it used as a UI, like your Readme, Swagger UI, Slate etc.
api spec - Opens your Optic API specification in a browser

I created a sample Spring Boot Ping API and set it up following the documentation. I got it up and running in a few minutes and it was finding endpoints and suggesting documentation right away.

For all the API Developers, this solves a major pain point of documenting the APIs while they are being developed and also keeping them up to date as and when changes are made. And it does so, all by snooping into your local traffic while you code away !

Why I love it !

GitBot - Apart from doing all the documentation for you, it has a github integration that would comment on every Pull Request, Detect any changes in your API and comment that in your PR ! Right there for the reviewers to see what you have fixed (or broken).

Look Ma, no YAML ! - (Well almost) There's only a few lines of yaml that it expects you to write. All other the other Open API specs to get that beautiful documentation, done for you.

API Test Coverage - With integration for running the tests through Newman (you will have to define a task in your optic.yml), you can use a --collect-coverage flag to ask Optic to track API testing code coverage and report that to you. It will look at your API Documentation Responses, and highlight any responses that you have not written a test for. So no more forgetting the edge case in your API Automation Testing !

Conclusion

I think it's a great tool that has a lot of potential use for any company developing APIs and need to keep track of their changes. You can add it to your build pipeline and use that code coverage tool in the CI pipeline. It is definitely like source control for your APIs as they advertise.

Also, it's free and open source. So you can fork the repo here.

Playing with the new AWS Copilot CLI

Arpit — Tue, 06 Oct 2020 22:19:44 +0000

AWS just launched a fresh CLI recently - copilot. AWS says this CLI is for containerised applications. So the target audience seems to be people using ECS and Fargate. I decided to try this new stuff.

Installation

The installation for Mac is quite simple. You use homebrew like -

brew install aws/tap/copilot-cli

For windows and Linux refer - https://github.com/aws/copilot-cli/wiki/Installation#manually

Prerequisites

aws cli. If you do not have that you might want to install and configure that. Steps here and here
docker

Initialisation

I am using a simple html file to deploy to in a container using a simple Dockerfile.

The first command you will have to run to initialise is

copilot init

This asks you a few questions and sets up the following things for you in the AWS account.

Virtual Private Cloud (VPC) on 2 Availability Zones (AZs), which includes
1. Internet Gateway
2. Public Subnet
3. Private Subnet
4. Route Table
ECS Cluster
Application Load Balancer (ALB)
Elastic Container Registry (ECR)

After running copilot init, creation of infrastructure ongoing

Deployment

Once this is complete, it will ask you whether you want to deploy this service to a test environment. If you say yes, it will deploy the service in a test environment and provide a URL where you can access the service (if it is a Web Service that you configured).

This does everything you need to deploy and access the Service through a Web URI.

Test your deployment

Finally when the deployment is complete, it will give you a URL that you can paste in your favourite browser and test.

Voila!

Other commands

The copilot CLI has three main command streams

app - You can use this to perform operations on applications that you have deployed.
env - To perform operations on the environments where your apps are deployed
1. copilot env init - Initialise the env
2. copilot env ls - List all envs
3. copilot env show - Show Details of the env
4. copilot env delete - Delete the env
svc

All these have a common set of commands, which are self explanatory -

copilot {app / env / svc} init - Initialize
copilot {app / env / svc} ls - List
copilot {app / env / svc} show - Gives a more detailed view of the services in the application, the Environments and the URIs. In case of service, it will also display Routes, Service Discovery and other Configuration.
copilot {app / env / svc} delete - To delete the app / env / service

Apart from these, svc has some more commands for package, deploy, status and logs.

Use cases

I think copilot has a really wide range of command sets to cover a wide range of use cases. It can be easily used for CI/CD for most containerised apps. Just install in the pipeline of your choice and deploy from there.

Anyone using ECS or Fargate could make their deployment processes easier by these commands.

They also have plans to introduce provisioning of S3, Databases (SQL and NoSQL) from the command which would further widen the use cases to deploy not only services but also storage for your application using this command.

Also, its open source. Check it out here.