Member-only story
Spring Boot Event-Driven Programming with AWS EventBridge
AWS EventBridge is a serverless event bus that makes it easier to build event-driven applications at scale using events generated from your applications, integrated Software-as-a-Service (SaaS) applications, and AWS services. EventBridge uses a predefined schema for events and allows you to set up routing rules to determine where to send your data to build application architectures that react in real-time to your data sources with event publisher and consumer completely decoupled.
Some of the main benefits of EventBridge are:
- Handles AWS events, authorized SaaS partner events, or custom events
- Cross-account or cross-application integration
- Message filtering
- Message transformation
- Built-in distributed availability and fault-tolerance
- Event archiving and replay
- A wide number of target AWS services (although you can still send an event to outside services through API Gateway routing or a Lambda function call)
- Schema registry to check event structure
- Code bindings to auto generate code based on schema definition, speeds up development!
- Has baked-in IAM support and works across-account. Easily allows account-to-account sharing of events.
In this article, we are going to explore the steps required to use AWS EventBridge for pub/sub between two Spring Boot microservices.
High-Level Architecture
Event publisher is Customer-Service, which publishes CustomerCreatedEvent to EventBridge. We have defined two targets on the subscriber side, one API Gateway pointing to Order-Service which consumes the CustomerCreatedEvent, the other target is a Lambda function to just print out the event details, merely to demonstrate that we can have multiple targets defined on the subscriber side.
Step 1: Implementation on the Publisher Side
First, add the following dependency in the pom:
On the publisher side, we need to implement the following code snippet to invoke AmazonEventBridgeClient to put events on EventBridge’s event bus.
Supply AWS Credential
By default, AWS SDK will attempt to find AWS credentials from the following places:
- Java system properties:
aws.accessKeyIdandaws.secretAccessKey. - Environment variables:
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEY. - The default credential profiles file:
~/.aws/credentials. - Amazon ECS container credentials, loaded from Amazon ECS if the environment variable
AWS_CONTAINER_CREDENTIALS_RELATIVE_URIis set. - Instance profile credentials, used on Amazon EC2 instances, and delivered through the Amazon EC2 metadata service.
For simplified demo purpose, let’s specify the credentials via application.yml, which is also recognized automatically:
Step 2: Implementation on the Subscriber Side
In July 2020, AWS announced the support for Amazon API Gateway as an event target in Amazon EventBridge. This feature enables new integration scenarios for web applications and services. In this example, we are going to expose our subscriber endpoint through API Gateway, which in turn is triggered by EventBridge as an event target.
To enable our subscriber app to listen on the event bus, we first add the following dependency in the pom, just like what we did for the publisher app:
Then, we create a Event class, defining properties per EventBridge AWS Event schema (I was hoping this class would be in aws-java-sdk-eventbridge dependency, but it is not). This Event class serves as the input for the subscriber endpoint, with its detail property holding the payload of the actual event passed over from the event bus.
With Event class in place, we can now implement our logic on the subscriber side in a SubscriberController, exposing endpoint consumeCustomerCreatedEvent:
Step 3. API Gateway Configuration for the Target
Now let’s expose our subscriber app through API Gateway. Once subscriber app is deployed in AWS, say EC2, define its deployment stage, expose its endpoint through API Gateway.
Step 4: EventBridge Configuration
Now let’s string the dots together.
- Create custom event bus
Access “EventBridge” under AWS Services → click on left navigation menu “Event Buses” → click on “Create event bus” button to create a event bus, “test-event-bus” in this example. Be sure this event bus name has to match what’s defined on the publisher app in step 1.
- Create custom rule
Access “EventBridge” under AWS Services → click on left navigation menu “Rules” → select the custom event bus in the drop-down, then click on “Create rule” button to create a new rule.
Under “define pattern” section, need to ensure a custom pattern for the publisher app is defined so events get properly filtered to be consumed. Notice the “source” and “detail-type” need to match what was defined in the publisher code in step 1 exactly, otherwise, events will not be delivered to the target. The event pattern section is also the place to define event filtering rule, say if we only want to handle events with last name “Smith”, we could add "detail":["lastName": "Smith"] into that event pattern.
Under “Select Targets”, ensure to add a target for the API Gateway pointing to our subscriber app, specify its deployment stage, integration target, see sample below:
There is a limit of 5 targets per rule. Additional targets such as Lambda function can be added to this rule. This example defined 2 targets, one API Gateway, the other Lambda to just print out the event details, and both targets work as expected.
The source code for these two microservices using EventBridge can be found under my GitHub repository: https://github.com/wenqiglantz/spring-boot-aws-eventbridge.
Happy coding! Happy crafting!
References:
https://aws.amazon.com/eventbridge/
Event-Driven Architecture (amazon.com)
Choosing the right event-routing service for serverless: EventBridge, SNS, or SQS — Lumigo
https://micronaut-projects.github.io/micronaut-aws/latest/guide/
https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-api-gateway-target.html
