Rearchitecting an eCommerce framework from the ground up in order to leverage modern microservice design patterns has been quite an undertaking. Ultimately, though, it makes for more adaptable and resilient platforms. As we’ve begun the journey at Broadleaf, I’m excited to share some key technical decisions we’ve made along the way.
Broadleaf’s Microservice Tech Stack
Broadleaf's microservices are based on Java and Spring, and we make heavy use of the Spring stack across the board. This includes many of the Spring libraries you already know like Spring Data and Spring Boot. We also leverage Spring's cloud stack to include additional components for gateway and messaging support with Spring Cloud Gateway and Spring Cloud Stream.
With our new offering, we continue to support a variety of RDBMS platforms, in addition to new support for NoSQL. You'll see support here for Postgres, MySQL, Maria, Oracle and Mongo.
We're also compatible with a number of presentation tier technologies. Single Page Application technologies including Vue.js, Angular and React are great tools for building custom eCommerce sites against the Broadleaf API. In fact, our admin platform is written entirely in React. More traditional server-side page rendering technologies, like Thymeleaf, also continue to be available and can also be used to interact with our APIs.
We have flexible support for a variety of message brokers through Spring Cloud Stream. Our reference implementation leverages Kafka out-of-the-box, but it can be replaced with google pub sub, or Microsoft's and Amazon's offerings in this area.
Finally, we have many deployment options for the services exposed by the Broadleaf framework. For example, we deploy Spring Boot executables via Docker in Kubernetes in our reference implementation and this represents a modern and scalable approach. However, it is entirely possible to deploy these services as more traditional applications in regular web containers. There's a lot of flexibility here.
Broadleaf’s Microservice Reference Architecture
Broadleaf’s microservice architecture includes a great mixture of technology and deployment options that we think will meet most needs. We think this is a great place to start and represents how we work with and deploy the services here at Broadleaf.
We expose a set of APIs that can be consumed by multiple channels. In front, we expose a gateway component that acts primarily as a routing mechanism. The gateway is not a required piece of the architecture, but is does help alleviate challenges related to CORS.
Next, we have a tier of services that are responsible for powering the admin experience. This includes NodeJS for serving the REACT application. There's also a metadata service that serves to inform the admin application of the resource services that are available for management (I'll talk more about this later). Additionally, we have an auth service responsible for authentication and OAuth2 authorization. Finally, at this tier, we have a menu service that informs the navigation structure of the admin.
We also have a resource tier that is home to services that fulfill the e-commerce related functionality of the system. Catalog and cart services are a couple of examples here.
Finally, the majority of communication between services is handled via async message brokers. Many of you will recognize Kafka, and others (including cloud native offerings) are supported as well.
Broadleaf’s Microservice Resource Tier
Resource tier services generally serve to cover the use cases related to eCommerce. These range from PIM-related services like the catalog service for merchandising products and categories - to cart related services like search and customer profile.
We also have several cross-cutting concern services that manage aspects across multiple services. This includes sandboxing and tenant services. Any sandbox capable service is capable of persisting sandbox data that is visible only to the editing user. Then, there's workflow to promote, review, and eventually schedule the change for deployment. Through the async messaging infrastructure, the sandbox service is able to manage this lifecycle and inform the user from a central location of sandbox state spanning multiple services.
In a similar vein, one of the duties of the tenant service is to manage catalogs, which represent groups of data based on one or more partitioning strategies. These groups can be arranged into complex hierarchies with interesting inheritance behavior. Deployments in a top-level catalog can result in propagation through inheriting catalogs all the way down to catalogs consumed by a storefront - at which point - the change is exposed to real customers. Multiple services can have data belonging to shared catalogs, and the tenant service is the central location for the management of this information.
These services can also be composed in interesting ways. In a granular deployment, each service has its own JVM running in a docker container. You achieve scale by adding more instances of each service. There's a lot of individual scaling flexibility here, but it can result in a larger infrastructure footprint than what you want, especially for services that are under-utilized and don't require an individual footprint. Multiple Broadleaf services can be composed together in a single container, which allows you to optimize your infrastructure outlay for components of the system where your scale needs are not as high.
Broadleaf’s Microservice Messaging
The majority of communication between Broadleaf’s Microservices is handled with messages via async message brokers.
Persistence messages are sent on state changes. When a mutating change is requested via the API, the system not only persists the change, but will also emit a message about the state change to the broker. This message is a great way to integrate with the system and be notified of changes as they occur. In fact, this will often extend beyond Broadleaf based services and consumption of these messages will occur in new or existing services seated outside of the Broadleaf ecosystem.
Our message emission is also resilient and can handle temporary broker outages. The state is tracked and expected messages will be emitted and acknowledged once the broker has returned to normal function.
Finally, our reference implementation uses Kafka, but this can be replaced with other brokers via Spring Cloud Stream configuration.
Broadleaf’s Microservice Administration Console
Broadleaf’s microservice-based administrative platform is primarily driven by metadata. Metadata serves to inform the admin of the available resource tier services, and describes the fields and visual presentation aspects of the forms rendered in the admin to manage resource data. In this way, it is the primary vehicle of discovery for the admin application.
Resource tier services provide metadata describing themselves in the form of a metadata library jar. Then, the metadata service includes these libraries and aggregates the information they contain. The metadata service is then able to serve as a central communication hub for the admin application regarding this information.
We also have an auth service responsible for authentication and OAuth2 authorization. For those implementations that wish to use a different provider, or a third party provider, this auth services can be swapped out.
Everything we develop at Broadleaf adheres to the same core principles: extensibility, performance, and scalability at an enterprise level. The microservice architecture pattern helps us continue with further customized deployment options on top of modern technology. We hope to find partners who think the same way - let us know if you’re one of them!
