Posted By
Since I began my development career, I’ve seen that backends can be messy, especially when scaling systems. Complex systems are hard to manage and less flexible. New team members often struggle to understand the infrastructure, which can slow us down. We face these challenges when making critical updates, leading to bottlenecks and poor performance that frustrate users.
To address these challenges, I explored event-driven architecture using Spring Boot, which turned out to be a game changer for me. I want to share a clear, step-by-step guide on how to use Spring Boot to create a powerful, agile, and maintainable backend.
What is an event-driven architecture (EDA)?
Event-driven architecture (EDA) is a software design pattern in which events determine the program's flow. These events can include user actions, sensor outputs, or messages from other systems. EDA encourages the decoupling of services, scalability, and asynchronous processing, making it ideal for modern cloud-native applications.
In event-driven systems, backend services can respond to changes, such as data updates or task completions, without the need for tightly coupling components. This approach is particularly well-suited for automating backend tasks, such as job processing, sending notifications, or updating databases.
What are the benefits of an event-driven architecture in backend automation?
Here are the advantages of using EDAs:
- Scalability: Event-driven systems are highly scalable since events can be processed in parallel across microservices.
- Asynchronous processing: Tasks can be handled asynchronously, ensuring the main application remains responsive while long-running tasks are executed in the background.
- Loose coupling: Components are loosely coupled, allowing backend services to react to events without direct dependency on one another.
- Real-time data processing: EDA enables real-time data processing, which is crucial for contemporary applications.
Steps to implement an event-driven architecture using Spring Boot
Step 1: Set up the environment
Create a new Spring Boot project using your preferred IDE.
Add the following Maven dependencies to the pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.kafka</groupId>
<artifactId>spring-kafka</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
Step 2: Create models
In Spring Boot, models are typically used to encapsulate the data associated with various events that trigger backend automation tasks
@Data
@NoArgsConstructor
@AllArgsConstructor
@JsonInclude(JsonInclude.Include.NON_NULL)
public class TestData extends TestCaseModel {
private List<TestEvent> events;
private String testCaseId;
private String testDescription;
}
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
@JsonInclude(JsonInclude.Include.NON_NULL)
public class TestEvent {
private EventType eventType;
private Request payload;
private Object response;
private Integer responseCode;
private Validation validation;
}
Step 3: Create an EventFactory class
In a Spring-based, event-driven system, you often need a method to dynamically register and fetch various event handlers. This is where the EventFactory class comes into play. It acts as a central registry that maps different event types (EventType) to their corresponding event handlers (EventHandler).
Here's a breakdown of the EventFactory class:
@UtilityClass
@Slf4j
public class EventFactory {
private static final Map<EventType, EventHandler> EventFactory = new HashMap<>();
public static void registerEvent(final EventType eventType, final EventHandler event) {
EventFactory.put(eventType, event);
}
public EventHandler getEvent(final EventType eventType) {
return EventFactory.get(eventType);
}
}
Step 4: Create a Client class
In microservices architectures, services often need to communicate with each other over HTTP. Feign is a declarative web service client, which is a part of Spring Cloud, and simplifies the process of making HTTP requests to other services.
The annotation @FeignClient is used to define Feign clients in Spring. When you annotate an interface with @FeignClient, Spring automatically generates a proxy for the interface and makes HTTP calls based on the method signatures. This allows you to make HTTP requests to other services in a more declarative and concise way, without the need for manually handling HTTP request details like URL, headers, request bodies, and responses.
Here's a rundown of the key parts of a @FeignClient.
@FeignClient(
name = "external-service", // Name of the external service
url = "${external.service.url}", // URL injected from application properties
configuration = {FeignConfig.class} // Custom configuration (optional)
)
public interface ExternalServiceClient {
@PostMapping("/api/v1/resource")
ResponseEntity<Resource> createResource(@RequestBody Resource resource);
@GetMapping("/api/v1/resource/{id}")
ResponseEntity<Resource> getResource(@PathVariable("id") Long id);
@PutMapping("/api/v1/resource/{id}")
ResponseEntity<Resource> updateResource(@PathVariable("id") Long id, @RequestBody Resource resource);
@DeleteMapping("/api/v1/resource/{id}")
void deleteResource(@PathVariable("id") Long id);
}
Step 5: Create an Event class
An event class holds the data or context related to a particular event. Request body, pre-requisites can be set here.
@Component
@Slf4j
public class GetResourceClient {
@Autowired
ResourceClient resourceClient;
@PostConstruct
public void init() {
EventFactory.registerEvent(EventType.valueOf("GET_RESOURCE_EVENT"), (EventHandler) this);
}
public void executeEvent(TestEvent event) {
Response response =
resourceClient.getResource("Id");
}
}
Step 6: Create a test class
@Test(
dataProvider = "DataProvider",
dataProviderClass = TestDataProvider.class)
public void getResourceTest(TestData testData {
testData
.getEvents()
.forEach(
event -> {
log.info("Event execution started:: " + event.getEventType().toString());
EventHandler eventHandler = EventFactory.getEvent(event.getEventType());
eventHandler.executeEvent(event, testData.getCommonInfo());
});
}
Step 7: Create a YAML file
Below is the YAML file. It allows us to define multiple events for test cases that require triggering multiple APIs within a specific workflow. In cases where different test cases have unique test data that cannot be managed within the @Before method, we can create events and specify them in the YAML file. This approach enables us to maintain test data, payloads, and validation responses directly within the YAML file, making the setup more flexible and manageable.
- testCaseId: GET_RESOURCE_POSITIVE_TEST
testDescription: Validate that user is able to do action on assigned case
events:
- eventType: LOGIN_EVENT
- eventType: GET_RESOURCE_EVENT
Conclusion
Embracing event-driven architecture has completely transformed the way we approach backend development. The challenges I encountered over the years have been effectively addressed by utilizing Spring Boot events. I can’t imagine reverting to a non-automated backend system, especially for applications that need real-time processing, scalability, and high levels of automation.
At Opcito, our experts are ready to assist you in adopting event-driven architectures for seamless and efficient backend management. Contact us today for a free consultation, or to discuss any challenges you may be facing. We can find the best solution that fits your business needs the most.
Related Blogs
