DEV Community: Apurv

Running AI Models Locally with Ollama + Spring AI: A Practical Guide for Java Developers

Apurv — Wed, 23 Apr 2025 12:10:07 +0000

No Cloud, No Limits: Run AI Locally with Spring Boot and Ollama

If you’ve been playing around with AI models but hate the idea of sending your data to the cloud every time you make a call to OpenAI or Hugging Face, you’re going to love this: You can now run powerful AI models right on your laptop.

In this post, I’ll walk you through how to do exactly that using Ollama and integrate it with your Spring Boot applications using Spring AI.

We’ll cover:

The different types of models you can run locally (text, audio, visual)
What models are available on Ollama and their system requirements
Which models actually run well on a local machine (no crazy GPUs needed)
How Spring AI makes working with these models ridiculously easy

Let’s dive in.

⸻

First, What Is Ollama?

Think of Ollama like Docker, but for AI models. With a single command, you can pull and run an LLM locally – no GPU required (though it helps). It’s lightweight, fast, and it gives you privacy and control over your AI workflows.

For example, want to run the mistral model? Just type:

ollama run mistral

Types of Models Ollama Supports

Right now, Ollama is primarily focused on language models, but support for other model types is starting to trickle in. Here’s a quick breakdown:

Text models: These are your bread and butter for chatbots, summarization, Q&A, etc. (e.g. phi, mistral, llama2, gemma)
Visual models: Some early support here, like llava, for things like image captioning.
Audio: Not officially in Ollama yet, but the community is starting to explore integrations with models like Whisper.

Bottom line: if you’re building anything text-based, Ollama has you covered today. More is coming soon.

What Models Can You Actually Run Locally?

Here’s a handy table that breaks down a few popular models and how much memory they typically need:

Pro tip: If you’re working on a MacBook or any device with 8 – 16 GB of RAM and no GPU, start with phi or mistral-mini. They’re fast, smart, and run surprisingly well on basic setups.

Enter Spring AI: AI for Java Devs

Now, let’s talk about Spring AI, which is the Spring ecosystem’s way of saying: “You don’t need to be a Python ninja to use AI in your Java apps.”

Spring AI gives you:

Easy integration with LLMs (OpenAI, Ollama, HuggingFace, etc.)
Chat models: for building conversational experiences
Prompt templates: like handlebars, but for prompts
Function calling: let models trigger your Spring services
Agents + tools: build smarter workflows using custom tools

To get started with Ollama, add this to your Spring Boot app:

<dependency>
  <groupId>org.springframework.ai</groupId>
  <artifactId>spring-ai-ollama-spring-boot-starter</artifactId>
</dependency>

Then configure it in application.yml:

spring:
  ai:
    ollama:
      base-url: http://localhost:11434
      model: mistral

And boom – you’re now talking to an LLM from your Spring Boot controller like this:

@RestController
public class ChatController {

    private final ChatClient chatClient;

    public ChatController(ChatClient chatClient) {
        this.chatClient = chatClient;
    }

    @GetMapping("/ask")
    public String ask(@RequestParam String message) {
        return chatClient.call(message);
    }
}

It’s clean, it’s simple, and it keeps your AI interactions private and fast.

⸻

So Why Should You Care?

Here’s why this setup is a game-changer:

No more cloud costs: Run models without paying per token.
Speed: Local models respond instantly.
Privacy: Your data stays on your machine.
Portability: Build once, run anywhere – even air-gapped environments.

If you’re building anything from customer support bots to internal dev tools, this combo of Ollama + Spring AI is about as powerful (and fun) as it gets.

⸻

Bonus: Run It All in Docker

Want to ship your entire AI app as a container? You can run Ollama and your Spring Boot app in a single Docker Compose file. Makes deployment to servers or edge devices super smooth.

⸻

Final Thoughts

AI is no longer locked behind cloud APIs and GPU clusters. With tools like Ollama and Spring AI, you can bring AI right into your own machine – and your own Java app stack.

Start small, maybe with phi or mistral-mini, wire it up with Spring AI, and see where it takes you. Whether you’re building a side project or enterprise-grade tools, this setup has you covered. Of course, when it comes to scale then gradually can be integrated with external API provider with required functionality implemented locally without spending a single penny.

If you found this helpful or want a follow-up post on vector search, RAG, or agents with Spring AI, let me know!

Spring Boot GraphQL Subscriptions: A Deep Dive into Real-Time Data Delivery

Apurv — Sun, 24 Nov 2024 08:12:04 +0000

Introduction

In today’s fast-paced digital world, real-time data delivery is paramount. GraphQL, a powerful query language for APIs, has revolutionized how we interact with data. When combined with the robust Spring Boot framework and the real-time capabilities of GraphQL subscriptions, we can build highly responsive and efficient applications.

Use Cases

GraphQL subscriptions are ideal for scenarios where you need to push data to clients in real-time, such as:

* Real-time chat applications: Delivering messages as soon as they’re sent.

* Live dashboards: Updating metrics and visualizations instantly.

* Collaborative tools: Syncing changes across multiple users in real-time.

* Stock tickers: Providing up-to-the-second market data.

* IoT applications: Receiving sensor data as soon as it’s collected.

Challenges in Traditional Systems

In traditional systems, delivering real-time updates across multiple clusters can be challenging. For instance, a message published on one cluster may not be immediately accessible to users on another cluster. This can lead to inconsistencies and delays in data delivery.

Resolving the Challenge with Kafka and Spring Boot Sink

To address this issue, we can leverage the power of Kafka and Spring Boot’s Sink mechanism. Kafka, a distributed streaming platform, ensures reliable and scalable message delivery. The Spring Boot Sink connector allows us to easily integrate Kafka with our Spring Boot applications.

Here’s a high-level overview of how this solution works:

* Message Publication: When a new message is generated, it’s published to a Kafka topic.

* Kafka Consumption: Spring Boot applications, deployed on different clusters, subscribe to the Kafka topic.

* Real-Time Delivery: As soon as a new message arrives, the Spring Boot application processes it and pushes the relevant data to the GraphQL subscription clients.

Performance Considerations

To ensure optimal performance for GraphQL subscriptions, consider the following factors:

* Efficient Querying: Design GraphQL queries to fetch only the necessary data.

* Caching: Implement caching strategies to reduce the load on the database and improve response times.

* Asynchronous Processing: Use asynchronous programming techniques to handle multiple requests concurrently.

* Load Balancing: Distribute the load across multiple instances to prevent bottlenecks.

* Kafka Optimization: Tune Kafka’s configuration parameters to optimize performance and scalability.

Conclusion

By combining the power of GraphQL subscriptions, Spring Boot, and Kafka, we can build robust and scalable real-time applications. This approach addresses the challenges of traditional systems and ensures seamless data delivery across multiple clusters. By carefully considering performance factors and optimizing the implementation, we can deliver exceptional user experiences.

Envoy Proxy Explained: How to Secure and Streamline Your Microservices

Apurv — Fri, 13 Sep 2024 14:51:03 +0000

Envoy components such as load balancing, OAuth2 authentication, JWT authentication, service-to-service security, role-based access control (RBAC), and advanced logging and monitoring

Introduction

As I began exploring various proxy options, I aimed to find a solution that could simplify our processes while enhancing security, all without adding extra complexity to the services. That’s when Envoy Proxy caught my attention, and diving into its capabilities has been a game-changer for how we manage our services.

Initial Configuration and Seamless OAuth2 Integration

In many setups, requests are typically routed through a service that connects to an enterprise server for authentication. While this method gets the job done, it often adds an extra service hop, which can lead to increased latency and slower performance.

After exploring Envoy Proxy’s OAuth2 filter, I was amazed by its simplicity and efficiency. This powerful filter seamlessly integrated into our system, eliminating the need for complex, service-level authentication. The result? Reduced latency, faster response times, and a much simpler configuration process. If you’re looking to optimize performance and streamline authentication, Envoy Proxy’s OAuth2 filter is a game-changer.

Implementing JWT Authentication for Enhanced Service-to-Service Security

So next priority comes ensuring secure communication between services, and Envoy’s JwtAuthentication filter proved to be the perfect solution. This filter checks for a token in the request header or cookie and validates it, making it incredibly easy to implement. The best part? It only required a simple configuration change, with no need to modify our existing services. The quick setup and smooth integration reinforced my trust in Envoy Proxy as a reliable security tool.

Role-Based Access Control (RBAC)

Soon after knowing OAuth2 and JWT authentication, I encountered a new challenge — validating users based on their roles. At first, I considered ADFS, but after diving deeper into Envoy’s capabilities, discovered that it supports Role-Based Access Control (RBAC). This feature allowed us to enforce user entitlements effortlessly. Setting up RBAC in Envoy was straightforward, offering the exact access control that one would need without adding unnecessary complexity.

By leveraging both JWT authentication and RBAC, Envoy Proxy has enabled us to secure service-to-service communication and manage user access with ease.

Advanced Logging and Monitoring

Logging is crucial for any application or product, and Envoy Proxy is no exception. Envoy was configured to capture detailed logs, which included valuable insights into the end-to-end user journey.

Envoy’s logging capabilities enabled us to gather statistics such as the number of users logged in, the number of requests at any given time, the average time taken for each request, and much more. This comprehensive logging and monitoring capability has been instrumental in optimizing system performance and ensuring a smooth user experience.

Conclusion

My experience with Envoy Proxy has been truly transformative. From cutting down latency through seamless OAuth2 integration to securing service-to-service communication with JWT authentication, and implementing strong role-based access control, Envoy has consistently proven itself to be a powerful and versatile tool. Its advanced logging and monitoring features have further elevated our ability to manage and fine-tune whole eco system.

In short, Envoy Proxy has far surpassed our expectations, delivering a secure, efficient, and flexible solution that simplifies configuration while boosting performance. By fully exploring Envoy’s capabilities, one should be able to significantly improve system architecture and provide a better user experience.

References

https://www.envoyproxy.io/docs/envoy/latest/

AWS S3 File Upload via Amazon API Gateway

Apurv — Tue, 22 Aug 2023 16:35:47 +0000

Introduction

Amazon Simple Storage Service (Amazon S3) is a cloud object storage service that offers industry-leading scalability, data availability, security, and performance. You can use Amazon S3 to store and retrieve any amount of data from anywhere on the web.

Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. You can use API Gateway to create RESTful APIs and WebSocket APIs that enable real-time two-way communication applications.

Of course, there are multiple ways to upload file to AWS S3 bucket, however, in this section, we will discuss on how to create an API Gateway endpoint for uploading files to Amazon S3. We will also go through on how to test the API Gateway endpoint. I assume that you have some basic knowledge of AWS services and tools, such as IAM, S3, and API Gateway.

Tool(s)/Framework(s)

Cloud Provider — Amazon Web Service(AWS)

AWS Services — API Gateway, Simple Storage Service(S3), Identity & Access Management(IAM)

High-Level Design

Let me start with high level design & what we are trying to achieve here. First, we will create s3 bucket & then we will configure AWS API Gateway using which we should be able to upload any types of file to S3 bucket.

S3 File Upload Via API Gateway

Implementation

→ S3 Bucket Creation & Configuration

Let’s navigate to AWS console & head towards S3.

AWS S3 Console Navigation

Click on “Create bucket” button

S3 Bucket — Create

Enter only minimal required details & keep all other attributes as it is without any change. Bucket name — enter valid bucket name, for Ex: “apigateways3bucket” AWS Region — choose appropriate AWS region in which you want to create bucket

S3 Bucket — Configuraion

Click on “Create bucket” button which will result in bucket to be created.

we can verify that bucket has been created from S3 dashboard as shown below.

S3 Bucket — After creation on S3 Dashboard

Now that we have created S3 bucket, Let’s move on to create & configure API Gateway.

→ API Gateway Creation/Configuration

Navigate to API Gateway from AWS Console

Click on “Create API” button

API Gateway — Create API

Choose “Rest API” & click on “Build”

API Gateway — Build

Now, let’s enter the required details & click on “Create API” button.
“Choose the protocol” — Choose “REST”
“Create new API” — Choose “New API”
Enter “API name” as “s3upload” & choose “Endpoint Type” as “Regional” as shown below under “Settings” section.

API Gateway — Settings

We can see that API Gateway resource has been created successfully

API Gateway — Resources

Also, we can navigate back to the API Gateway dashboard & can see that new API Gateway with name “S3 Upload” is created.

API Gateway — Dashboard

Now, we have to configure resources with request path where
Under “Resources” panel of API page, select /.
Choose “Create Resource” from the “Actions” menu.

Now, we will create two resources where each resources signifies the S3 bucket & the object.
Create a resource under “/” (root) with “Resource Name” as “folder” and “Resource Path” as “{folder}” & click on “Create Resource”
Create another resource under “/{folder}” (root) with “Resource Name” as “object” and “Resource Path” as “{object}” & click on “Create Resource”

API Gateway — Create Resource

Once these resources are created which would look something like this.

API Gateway — Resources

Once resources are created, now let’s create HTTP methods which will help us to upload & download the files to/from S3.
Select “/{object}” from “Resources” & choose “Create Method”

API Integration — Create Metod

Now, from Actions dropdown, choose ‘ Put ’ method & provide required configuration as given & shown below.
Integration Type — AWS Service
AWS Region — Choose the appropriate region
Execution Rolle — Choose execution role created earlier
Under “URL Path Parameters” section, add below parameters.
1. Name — bucket, Mapped From — method.request.path.folder
2. Name — key, Mapped From — method.request.path.object

API Integration — Put method

Now, from Actions dropdown, choose ‘ Get ’ method & provide required configuration as given & shown below.
Integration Type — AWS Service
AWS Region — Choose the appropriate region
Execution Rolle — Choose execution role created earlier
Under “URL Path Parameters” section, add below parameters.
1. Name — bucket, Mapped From — method.request.path.folder
2. Name — key, Mapped From — method.request.path.object

API Integration — Get Configuration

Let’s setup binary media type to allow file upload/download via HTTP request. Click on “Add Binary Media Type” & enter “*/*”

API Integration — Binary Media Type

Testing

Now, you might be thinking so much of configuration but believe me, you will really enjoy & may explore other functionalities on the way which may excite you more & more.

Huuhhh, enough of configuration now, it’s time for testing :)

Let’s navigate to the “Put” method which would looks something like shown below. Let’s click on “Test” link.

API Integration — Test

Enter the required input parameters

{folder} — apigateways3bucket (which we have created ealier)

{object} — testfile (object name by which object would be created under S3 bucket)

Request Body — enter the saple text as file content here

API Integration — Test Inputs Parameters

Once all parameters are set, we are all set to click on “Test” button

API Integration — Test

Now, navigate to the AWS S3 dashboard & check the bucket. it will have the file uploaded in previous step.

AWS S3 — verification after upload

Hurrrrayyy, finally we were able to upload file to S3 using AWS API Gateway.

Conclusion

In this section, we have learned how to create an API Gateway endpoint for uploading files to Amazon S3. We have also learned how to test the endpoint. By using this approach, we can leverage the benefits of both Amazon S3 and API Gateway, such as scalability, availability, security, performance, and ease of development. We can also avoid the limitations of uploading files directly to API Gateway, such as the payload size and encoding restrictions. This way, we can create a robust and efficient solution for uploading files to the cloud.

I hope you have enjoyed this tutorial and found it useful. If you have any questions or feedback, please feel free to connect.

If this post was helpful, please clap for few times or follow to show your support which keeps me constantly motivated to share my learnings.

Learning, sharing & growing together.

The Most Popular File Upload to AWS S3 Using AWS Api Gateway

Apurv — Tue, 22 Aug 2023 16:35:47 +0000

Introduction

Tool(s)/Framework(s)

Cloud Provider — Amazon Web Service(AWS)

AWS Services — API Gateway, Simple Storage Service(S3), Identity & Access Management(IAM)

High-Level Design

S3 File Upload Via API Gateway

Implementation

→ S3 Bucket Creation & Configuration

Let’s navigate to AWS console & head towards S3.

AWS S3 Console Navigation

Click on “Create bucket” button

S3 Bucket — Create

Enter only minimal required details & keep all other attributes as it is without any change. Bucket name — enter valid bucket name, for Ex: “apigateways3bucket” AWS Region — choose appropriate AWS region in which you want to create bucket

S3 Bucket — Configuraion

Click on “Create bucket” button which will result in bucket to be created.

we can verify that bucket has been created from S3 dashboard as shown below.

S3 Bucket — After creation on S3 Dashboard

Now that we have created S3 bucket, Let’s move on to create & configure API Gateway.

→ API Gateway Creation/Configuration

Navigate to API Gateway from AWS Console

Click on “Create API” button

API Gateway — Create API

Choose “Rest API” & click on “Build”

API Gateway — Build

Now, let’s enter the required details & click on “Create API” button.
“Choose the protocol” — Choose “REST”
“Create new API” — Choose “New API”
Enter “API name” as “s3upload” & choose “Endpoint Type” as “Regional” as shown below under “Settings” section.

API Gateway — Settings

We can see that API Gateway resource has been created successfully

API Gateway — Resources

Also, we can navigate back to the API Gateway dashboard & can see that new API Gateway with name “S3 Upload” is created.

API Gateway — Dashboard

Now, we have to configure resources with request path where
Under “Resources” panel of API page, select /.
Choose “Create Resource” from the “Actions” menu.

Now, we will create two resources where each resources signifies the S3 bucket & the object.
Create a resource under “/” (root) with “Resource Name” as “folder” and “Resource Path” as “{folder}” & click on “Create Resource”
Create another resource under “/{folder}” (root) with “Resource Name” as “object” and “Resource Path” as “{object}” & click on “Create Resource”

API Gateway — Create Resource

Once these resources are created which would look something like this.

API Gateway — Resources

Once resources are created, now let’s create HTTP methods which will help us to upload & download the files to/from S3.
Select “/{object}” from “Resources” & choose “Create Method”

API Integration — Create Metod

Now, from Actions dropdown, choose ‘ Put ’ method & provide required configuration as given & shown below.
Integration Type — AWS Service
AWS Region — Choose the appropriate region
Execution Rolle — Choose execution role created earlier
Under “URL Path Parameters” section, add below parameters.
1. Name — bucket, Mapped From — method.request.path.folder
2. Name — key, Mapped From — method.request.path.object

API Integration — Put method

Now, from Actions dropdown, choose ‘ Get ’ method & provide required configuration as given & shown below.
Integration Type — AWS Service
AWS Region — Choose the appropriate region
Execution Rolle — Choose execution role created earlier
Under “URL Path Parameters” section, add below parameters.
1. Name — bucket, Mapped From — method.request.path.folder
2. Name — key, Mapped From — method.request.path.object

API Integration — Get Configuration

Let’s setup binary media type to allow file upload/download via HTTP request. Click on “Add Binary Media Type” & enter “*/*”

API Integration — Binary Media Type

Testing

Let’s navigate to the “Put” method which would looks something like shown below. Let’s click on “Test” link.

API Integration — Test

API Integration — Test Inputs Parameters

Once all parameters are set, we are all set to click on “Test” button

API Integration — Test

Now, navigate to the AWS S3 dashboard & check the bucket. it will have the file uploaded in previous step.

AWS S3 — verification after upload

Hurrrrayyy, finally we were able to upload file to S3 using AWS API Gateway.

Conclusion

I hope you have enjoyed this tutorial and found it useful. If you have any questions or feedback, please feel free to connect.

If this post was helpful, please clap for few times or follow to show your support which keeps me constantly motivated to share my learnings.

Learning, sharing & growing together.

AWS AppConfig With Spring Boot

Apurv — Sat, 13 Aug 2022 07:28:33 +0000

Introduction

Hello AWeSome techies ! Most of us would be familiarized with application configuration by one or the other way & that too with different set of profile depending on the environment or the technical boundaries. A configuration is a collection of settings that influence the behavior of our applications.

Today, we will learn how to retrieve AWS AppConfig using spring boot microservice.

Incase you are not sure how to create, configure & deploy AWS AppConfig through AWS management console then I would advise you to go through this article.

Tool(s)/Framework(s)

IDE — IntelliJ Idea/Eclipse

Language — Java 8 or above

Framework — Spring boot

SDK — AWS SDK

AWS Services — AppConfig

Cloud Provider — Amazon Web Service(AWS)

Build Tool — Maven

Repository

https://github.com/shethapurv/aws/tree/main/aws-app-config-service

Maven Dependencies

Please refer to the maven dependency given below which is required to get config from AWS AppConfig service.

<dependency>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-java-sdk-appconfig</artifactId>
    <version>1.12.272</version>
</dependency>

Important Concepts

Before getting into the implementation, let’s try to understand few concepts/classes & its significance.

aws-java-sdk-appconfig — We will use this maven dependency which will help us to connect to AWS AppConfig service from our spring boot application.

AmazonAppConfigClient- We will use this class from AWS SDK to connect to AWS AppConfig service from our spring boot microservice.

GetConfigurationRequest - We will use this class to build the request to retrieve configuration from AWS AppConfig.

Spring Boot Microservices Communication with AWS AppConfig

As we have understood the important concepts, let’s jump to the implementation.

Implementation

We will create a AWSAppConfig class which we will use to connect to AWS AppConfig service & to retrieve configuration based on the environment & profile. Let’s have a look,

GetConfigurationRequest.application — set the application id for which configuration is created.

GetConfigurationRequest.configuration — To indicate which configuration to pickup.

GetConfigurationRequest.environment — To get configuration for specific environment

public AWSAppConfig() {
    appConfig = AmazonAppConfigClient._builder_().build();
    request = new GetConfigurationRequest();
    request. **setApplication** ("aws-app-config-service");
    request. **setConfiguration** ("dev");
    request. **setEnvironment** ("dev");
}

Now, we will implement a method which should return us a configuration from AWS AppConfig.

AmazonAppConfigClient.getConfiguration — this will get the configuration based on the configuration & environment set in the request.

public String **getConfiguration** () throws UnsupportedEncodingException {
    GetConfigurationResult result = **appConfig.getConfiguration** (request);
    String message = String._format_("contentType: %s", result.getContentType());
    _LOGGER_.info(message);

    if (!Objects._equals_("application/json", result.getContentType())) {
        throw new IllegalStateException("config is expected to be JSON");
    }

    String content = new String(result.getContent().array(), "ASCII");
    return content;
}

By now, you might think, all this is fine but how to verify whether it is really fetching the configuration or not! Don’t worry, let’s verify the same in next section.

Testing

Let’s implement an API endpoint using AWSAppConfig to retrieve configuration.

@RestController
@RequestMapping(path = " **/aws**", method = RequestMethod._GET_)
public class AWSAppConfigController {

    @Autowired
    AWSAppConfig awsAppConfig;

    @RequestMapping(path = " **/getConfig**", method = RequestMethod._GET_)
    public String getAWSAppConfig() throws UnsupportedEncodingException {
        return **awsAppConfig.getConfiguration();**

    }
}

Now, let’s run the application & hit the url localhost:8080/aws/getConfig. Ta..da.. we got the configuration from AWS AppConfig.

AWS AppConfig — Output

References

https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html

If this post was helpful, please clap for few times or follow to show your support which keeps me constantly motivated to share my learnings.

Learning, sharing & growing together.

AWS AppConfig — Create, Configure & Deploy

Apurv — Sat, 13 Aug 2022 07:19:52 +0000

AWS AppConfig — Create, Configure & Deploy

Introduction

Today, we will learn how to configure AWS AppConfig from AWS management console.

AWS System Manager — AppConfig service

Click on “Create application” button. Enter the application details & click again on “Create application” button.

AppConfig — Create Application

Navigate to the “Configuration Profile and Feature Flags” tab under application created in previous step & click on create.

Choose appropriate configuration profile type. Here, we will choose “Freeform Configuraion” & click on “Select”.

Enter “ Build Freeform configuration profile” details & choose “AWS AppConfig hosted configuration”.

Next, choose “JSON” & enter configs in the given text area in json format.

Navigate to the “Environments” tab & click on “Create environment”

Enter appropriate name of the environment. For Ex: Dev, SIT, UAT/Test, Prod & likewise.

Once environment is created, then we are all set to start the deployment to make our configuration available.

For Configuration , choose a configuration from the list.
Depending on the source of your configuration, use the Document version or Parameter version list to choose the version you want to deploy.
For Deployment strategy , choose a strategy from the list.
Choose Start deployment.

Please don’t forget to delete all this AWS resources without fail once you have completed this exercise.

Next Steps

You must be surprising, thinking that all this is fine but then how to access this config as a part of your application !

Don’t worry, you can refer to this article on how to access AWS AppConfig from Spring Boot microservices.

References

https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html

Spring Framework - Handling Prototype Scoped Beans

Apurv — Wed, 10 Aug 2022 17:15:03 +0000

Spring Framework - Handling Prototype Scoped Beans

Introduction

Whenever we are creating a bean using @Service, @Component, or any other similar annotations, we are creating a recipe for creating an instance of a class. Along with this recipe, we can also define the scope of that respective instance. It can be any of these, singleton, prototype, session, request, or global session.

Most of us are already familiar with these bean scopes. But today, we are going to understand whether the prototype scope is creating multiple instances or is being treated as a singleton.

So, let’s start with a summary of singleton & prototype scoped beans. After which, we will go through the issue which may cause the prototype to be singleton & its possible solutions.

GitHub Repo

https://github.com/shethapurv/spring-boot/tree/main/lookup-scope-service

Basics

Let’s define two different service classes named EmployeeService & Department Service. EmployeeService would be singleton scoped & DepartmentService would be of prototype scoped.

@Service
**@Scope("prototype")** // prototype scoped
public class **DepartmentService** {
    private Integer departmentId = new Random().nextInt(1000);

    public int getDepartmentId(){
        return departmentId;
    }
}

**@Service** // by default, singleton scoped
public class **EmployeeService** {
}

Now, Let’s write a test case and compare the hashcode of each service bean defined above.

Multiple instances of singleton scoped bean “EmployeeService” will have the same hashcode.

@Test
public void singletonTest() {
    EmployeeService employeeService1 = applicationContext.getBean("employeeService", EmployeeService.class);
    EmployeeService employeeService2 = applicationContext.getBean("employeeService", EmployeeService.class);
    **Assertions._assertEquals_** (employeeService1.hashCode(), employeeService2.hashCode());
}

Multiple instance of prototype scoped bean “DepartmentService” will have different hashcode.

@Test
public void prototypeTest() {
    DepartmentService departmentService1 = applicationContext.getBean("departmentService", DepartmentService.class);
    DepartmentService departmentService2 = applicationContext.getBean("departmentService", DepartmentService.class);
    **Assertions._assertNotEquals_(**departmentService1.hashCode(), departmentService2.hashCode());
}

Yea, so far so good. Test results are very much as expected. isn’t it !

Problem

So, here is the problem. Whenever we will inject a prototype scoped bean within a singleton scoped bean, the prototype scoped bean will start behaving as a singleton bean.

Let’s try to understand with a simple example.

If you have observed above in DepartmentService bean, “departmentId” class variable is declared which will return a random integer as department id. Now, whenever, we will try to get departmetnId then it should return two different department Id since DepartmentService is a prototype scoped bean but in reality, it will return only the same departmentId.

@RestController
@RequestMapping(path = "/beanScope", method = RequestMethod._GET_)
public class **BeanScopeController** {

    @Autowired
    EmployeeService employeeService;

    @RequestMapping(path = "/prototypeTreatedAsSingleton", method = RequestMethod._GET_)
    public List<Integer> getDepartmentIdWithDeptTreatedAsSingleton() throws InterruptedException {
        return employeeService.getDepartmentIdWithDeptTreatedAsSingleton();
    }
}

// **EmployeeService**

// it will be treated as singleton even though its prototype scoped @Autowired 
DepartmentService **departmentService** ;

public List<Integer> getDepartmentIdWithDeptTreatedAsSingleton() throws InterruptedException {
    **int dep1 = departmentService.getDepartmentId();**
    Thread._sleep_(1000L);
    **int dep2 = departmentService.getDepartmentId();**
    return List._of_(dep1, dep2);
}

As we are clear about the problem explained above, now, let’s try to see the different approaches to get away from this issue.

Solution

To treat prototype scoped bean as really it is supposed to be. We have 3 different approaches instead of auto-wiring prototype scoped bean.

1. Using ApplicationContext

We can use application context to get the prototype scoped bean object. But here, we are violating the principle of inversion of control. We are creating an object instead of a spring container creating an object.

@Autowired
ApplicationContext **applicationContext** ;

public List<Integer> getDepartmentIdWithApplicationContext() throws InterruptedException {
    int dep1 = **applicationContext.getBean** (DepartmentService.class).getDepartmentId();
    Thread._sleep_(1000L);
    int dep2 = **applicationContext.getBean** (DepartmentService.class).getDepartmentId();
    return List._of_(dep1, dep2);
}

2. Using ObjectFactory

We can use object factory instantiation to get a prototype scoped bean but the problem with this approach is, instances will be eagerly initialized.

@Autowired
private ObjectFactory<DepartmentService> **departmentServiceObjectFactory** ;

public List<Integer> getDepartmentIdWithObjectFactory() throws InterruptedException {
    int dep1 = **departmentServiceObjectFactory.getObject** ().getDepartmentId();
    Thread._sleep_(1000L);
    int dep2 = **departmentServiceObjectFactory.getObject** ().getDepartmentId();
    return List._of_(dep1, dep2);

}

3. Using @LookUp Annotation

We can use @LookUp annotation provided by spring. this will help to resolve the inversion of control issue which we faced in option 1 since the spring container itself will take care of instance creation. And, it will also not be eagerly initialized as we saw in option 2.

public List<Integer> getDepartmentIdWithLookUp() throws InterruptedException {
    int dep1 = **getDepartmentService** ().getDepartmentId();
    Thread._sleep_(1000L);
    int dep2 = **getDepartmentService** ().getDepartmentId();
    return List._of_(dep1, dep2);

}

@ **Lookup**
public DepartmentService **getDepartmentService** () {
    return null;
}

Conclusion

We have gone through the problem which might occur with the prototype scoped bean if it is not handled correctly. We have also seen the different approaches to resolving those issues.

It is advisable to use @LookUp annotation to handle the prototype scoped bean which doesn’t violate the spring IoC principle and beans are also not eagerly initialized.

References

If this post was helpful, please clap for few times or follow to show your support which keeps me constantly motivated to share my learnings.

Learning, sharing & growing together.

Serverless GraphQL — AWS AppSync, Lambda, Spring Boot

Apurv — Fri, 10 Jun 2022 01:03:21 +0000

Serverless GraphQL - AWS AppSync, Lambda, Spring Boot

Introduction

In this & this article, we have seen how we can implement the standalone AWS Lambda function and its integration via AWS API Gateway. In case you have not gone through those previous articles then I would strongly recommend going through those articles first.

If you are not familiar with GraphQL concepts then I would request going through this & this article.

Leveraging our learning from the past, we will learn how we can create GraphQL API using the AWS AppSync service.

Tools/Frameworks

IDE — IntelliJ Idea/Eclipse

Language — Java 8 or above

Framework — Spring boot

Build Tool — Maven

Cloud Provider — AWS

AWS Services — AppSync & Lambda

Goal

OK, so let's discuss now what we are trying to achieve. Please refer to the high-level design below.

We will create AppSync GraphQL API which will invoke the lambda function backed by the spring boot cloud function & return a response.

High Level Design — AWS AppSync/Lambda

Sample Application

Let's assume that we have a sample application (don’t worry! you can refer to the git repository at the end of this article) deployed as a part of the AWS lambda function. Here is the “User” model

→ Model

public class User {

    private String name;
    private Integer id;
}

→ Functional API

We will use the “getAllUsers” function to be called as a part of lambda which will return the List

With this basic implementation, let's go ahead & create AppSync GraphQL API.

Create — AWS AppSync GraphQL API

As we have the application background ready, let's jump on how to create/configure AWS AppSync GraphQL API.

→ Log in to the AWS management console. Search & navigate to the AppSync service.

→ Click on the “Create API” button & choose the “Build from scratch” option.

→ Next, let's give our API the name “UserAppSyncApp” & click on create that will create AWS AppSync GraphQL API.

Configure

Now, let's concentrate on the configuration part.

→ Let’s navigate to the API which we have created & configure types/schema based on the model for which we want to perform GraphQL query/mutation operation. Here, we can see that the “User” type is in line with the model of the lambda function.

AWS AppSync — Schema

type Mutation {
    addUser(id: ID!, name: String): User!
}

type Query {
    getUser(id: ID!): User
    getAllUsers: [User]
}

type User {
    id: ID!
    name: String
}

schema {
    query: Query
    mutation: Mutation
}

You might think that schema is created then it should start working, right? But, actually no, it will not work. why? because we have not integrated our lambda function as a data source to our AppSync API.

So, now let's configure the AWS Lambda function as a data source for our newly created “UserAppSyncApp” AppSync API.

→ Navigate to the data source & let’s attache our lambda function.

Data source name — Enter any meaningful name for the data source
Data source type — Choose “AWS Lambda function”
Region — Choose the region to which the lambda function belongs.
Function ARN — Choose the function which you want to bind to the AppSync API
Create or use an existing role — Use the appropriate existing role if you have already one else create a new one.

AWS AppSync — Data Source Configuration

Testing

As we have almost all configurations in place, let’s verify.

→ Navigate to the “Queries” section where you can see all the queries which we have configurated as a part of schema configuration. Click on the play button.

AWS AppSync — Queries

→ Let's see the result.

AWS AppSync — Testing

Yey, we have successfully implemented AWS AppSync GraphQL API using AWS Lambda as a data source.

If this post was helpful, please clap for few times or follow to show your support.

Learning, sharing & growing together.

Git Repository

https://github.com/shethapurv/aws/tree/main/awslambda-appsync-example

References

https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html

Schemas and Types

Spring Boot — Reactive Web

Apurv — Fri, 27 May 2022 17:55:47 +0000

Spring Boot — Reactive Web

Introduction

In this article, we learned how to use Spring Data JDBC connectivity.

Today, we will learn to build an application that uses Spring Data R2DBC to store and retrieve data in a relational database using *reactive database * drivers.

Tools/Frameworks

IDE — IntelliJ Idea/Eclipse

Language — Java 8 or above

Framework — Spring boot, Project Reactor

Database — H2

Build Tool — Maven

Key Concept(s)

The heart of the project reactor is reactive-core. The main focus is on the Reactive Streams spec and targets Java 8 streams.

Project reactor introduced reactive types Flux & Mono that implement Publisher.

Flux — It represents an asynchronous sequence of zero or more objects

Mono —It represents asynchronous single or empty objects

The image given below very well describes the flux transformation very well. Please refer to the reference link at the end of the article for further readings.

Flux Transformation from projectreactor.io

Since we have gone through the basic concepts, let's jump on the implementation without having any delay.

Maven Dependency

Reactor — Maven Dependency

Configuration

First. let’s go through the configuration. As you have noticed, we have used the r2dbc configuration & the URL is prefixed with r2dbc but not with JDBC.

R2DBC Configuration

Implementation

Now, let’s have a look at the implementation. To have a reactive nature, we will implement ReactiveCrudRepository as shown below.

In our service class, we will return the Flux/Mono depending on our functionality.

Example — Flux/Mono Service

In our API resources also, we will return flux/mono as a response as shown below. However, the point to note down here is, that we need to set the “produces” media type as “MediaType.TEXT_EVENT_STREAM_VALUE”.

API/RestController with TEXT_EVENT_STREAM_VALUE media type

Huh, you might think, enough concepts & implementation but does it really work! Of course, it does, :) Let's go ahead & test.

Testing

I’m not sure if you have observed earlier, that I have kept a delay of 5 seconds before emitting the next objects so that we can verify that it's non-blocking asynchronous emitting of objects.

Testing

Yey, we have successfully implemented spring boot reactive web flux & verified the same.

If this post was helpful, please clap for few times or follow to show your support.

Git Repo

spring-boot/spring-reactive-flux-example at main · shethapurv/spring-boot

References

Project Reactor and the Spring portfolio work together to enable developers to build enterprise-grade reactive systems that are responsive, resilient, elastic, and message-driven.

https://projectreactor.io/

Reactor 3 Reference Guide

Spring Boot — Serverless AWS Lambda With API Gateway

Apurv — Sun, 15 May 2022 02:08:37 +0000

Spring Boot — Serverless AWS Lambda With API Gateway

Introduction

In this article, we have learned how to configure & implement the AWS lambda function with a stand-alone java event.

Today, we will learn how to configure & implement the lambda function & trigger it using AWS API Gateway with a practical example.

Tool(s)/Framework(s)

IDE — IntelliJ Idea/Eclipse

Language — Java 8 or above

Framework — Spring boot

SDK — AWS SDK

Cloud Provider — Amazon Web Service(AWS)

Build Tool — Maven

Git Repository

aws/awslambda-apigateway-example at main · shethapurv/aws

Maven Dependency

Please refer to the maven dependency given below which is required for the spring boot cloud function to work on AWS Lambda.

Here, if you have observed, we don’t need maven dependency for Spring Cloud Function Web adapter since AWS doesn't require it at runtime hence we can exclude that dependency.

Maven Dependency

Maven Build

To deploy our spring boot microservice on AWS Lambda, it has to be shaded which will generate two separate jar files,

— one jar which ends with “-aws” is to be deployed on AWS Lambda &

— another jar that will have the spring cloud function web dependency

Maven Build — Generated Artifacts

Implementation

You might be thinking that it's all theory but how the implementation would look like & naturally, we start thinking that how we can pass the input params or get the response while triggering the lambda function via AWS API Gateway.

But it is really very simple than what we might have thought of.

Let's go through the classes listed below which are important to understand first.

APIGatewayProxyRequestEvent — If we will drill down a little bit to see this class, we can clearly say that we can get all the request params/variables from the instance of this class.

Spring boot — AWS APIGatewayProxyRequestEvent

APIGatewayProxyResponseEvent — this will hold the response & its status code details.

As we have understood the importance of the request/response wrapper around AWS API Gateway, Let’s look at the handler. we will implement the spring boot request handler which will work as a wrapper & will hold the request & response-related attributes &

Next, we will have to implement our functional bean “welcome” to accept APIGatewayProxyRequestEvent as a function’s target.

Similarly, if we can use APIGatewayProxyResponseEvent to get the response & any other important attributes like HTTP status code.

Very cool & easy stuff it was than we thought of, isn’t it? Let’s move to deployment now.

Deployment

Here, we will concentrate on how to set up AWS API Gateway & will skip the initial AWS Lambda function setup steps since we have learned the same in this article. so let’s start,

→ Navigate to the function created & click on “Add trigger” & choose “Trigger configuration” as “API Gateway”

→ Choose “Create an API” for the lambda function which we created & choose “HTTP API” as API Type keeping security as “Open” & click on “Add”

AWS API Gateway — setup

→ Once, the trigger event is added as an “API Gateway”, the AWS Lambda function would look like this,

AWS Lambda Function With API Gateway

Testing

Now, the question comes that all this is fine but how I can trigger the function & how about the request/response.

→ let's get the API Gateway URL first. Click & navigate to the “API Gateway” which will give us the API endpoint.

AWS API Gateway — URL

→ Copy this URL & access it with the request parameter “userName” which we have configured as part of our functional bean “welcome”.

For Ex:

https://bdq0e9rc58.execute-api.us-east-1.amazonaws.com/default/HelloWorldFunction ?userName=Apurv

Output:

AWS API Gateway — URL Access From Browser

Hurreeeyyy … !!

Isn’t it easy & very straightforward? of course, it is.

If I can, anyone & everyone can !

References

https://docs.spring.io/spring-cloud-function/docs/current/reference/html/aws.html

Serverless With Spring Boot & AWS Lambda

Apurv — Wed, 11 May 2022 17:04:10 +0000

Introduction

In the previous article, we learned how to implement java's functional interface& serverless with spring. Utilizing this knowledge, we will learn how to build our spring boot microservice application compliant with serverless AWS Lambda.

Tool(s)/Framework(s)

Editor — IntelliJ Idea/Eclipse

Language — Java 8 or above

Framework — Spring boot

Cloud Provider — Amazon Web Service(AWS)

Build Tool — Maven

GIT Repo -

https://github.com/shethapurv/aws/tree/main/serverless-aws-lambda-service

Maven Dependency

Please refer to the maven dependency given below which is required for the spring boot cloud function to work on AWS Lambda.

Here, if you have observed, we don't need maven dependency for Spring Cloud Function Web adapter since it's not required by AWS at runtime hence we can exclude that dependency.

Maven Dependency — AWS Lambda

Maven Build

To deploy our spring boot microservice on AWS Lambda, it has to be shaded which will generate two separate jar files,

— one jar which ends with “-aws” is to be deployed on AWS Lambda &

— another jar that will have the spring cloud function web dependency

Maven Shaded Build Plugin — generating two jars

Implementation

So now, the question comes of how spring boot interprets the response datatype from the AWS Lambda function. For this purpose, AWS has platform-specific data types which is much more efficient than processing each one individually. so, to make use of these types, there are two choices,

Write a function that depends on those AWS types
Rely on Spring to extract the data from the AWS types and convert it to a Spring Message and convert it to a Spring “Message”.

Here, we will write a handler as shown below. which we will use while setting up AWS lambda function.

**public class** HelloWorldHandler **extends SpringBootRequestHandler** <String, Object> {
}

Deployment

After understanding the basic concepts, let’s jump into deploying the jar on AWS lambda.

→ Login to AWS console. Search & navigate to Lambda service.

AWS — Search Lambda Service

→ Once we are on the Lambda service, locate the “Create function” button to create the AWS Lambda function.

→ Next, we will see the function creation page where we need to configure a few parameters as shown below & then click on “Create function” button.

Choose the “Author From Scratch” option to create the function.
Enter the appropriate function name.
choose runtime as java 8 or java 11 as appropriate.

AWS Lambda — Create Function

→ As the function is created now, let's upload the spring-boot jar by clicking on the “upload from” button which will ask us to choose the jar file.

AWS Lambda — Upload JAR

→ Once the jar is uploaded, Let’s edit the runtime setting under the “Code” tab to configure the handler as shown below.

AWS Lambda — Runtime Settings-1

AWS Lambda — Runtime Settings-2

→ Now, let’s configure the function name in the “Configuration” tab under “Environment variables” as shown below.

AWS Lambda — Environment variables

Now, we are all set to test our first Lambda function.

Testing

Yey guys, so are you excited to test our first lambda function after having the adventurous implementation! Let's try it out :)

Let’s navigate to the “Test” tab, enter the required parameter under the “Event JSON” text area & click on “Test”.

We can see below(green area) that our AWS Lambda function test was successful.

AWS Lambda — Test

If we further expand the “Details” link further, we can see that message is being displayed as per the input provided.

AWS Lambda — Test Details

Hope this post will be useful for many of us.

Key Takeaways

Dependency — Maven dependencies required for AWS Lambda function to work
Build — maven build changes required to make our application AWS Lambda compliant.
Request handler — Spring boot & AWS Lambda request handler to handle the responses.
Test — how we can test the AWS Lambda function.

References

https://docs.spring.io/spring-cloud-function/docs/current/reference/html/aws.html

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇