Events, Event APIs, and Event API Products

When working with Solace PubSub+, distinguishing between ?????????? ???????? and ?????????? ?????? ???????????????? is crucial for maximizing the benefits of event-driven architecture (EDA). Before diving into their differences, let’s start with some fundamentals. Then, I’ll break down their key distinctions and provide practical guidance on when to use each to build more effective event-driven applications.

In PubSub+ Event Portal, events are the basic building blocks for everything. Events are published and consumed by applications, and they can be combined into event APIs.

• Events declare a topic and payload, but they do not specify their intended use – are they to be published by an application (or service) or meant to be consumed (subscribed to)?
• Event APIs combine related events into an interface that also determines the operation– publish or subscribe – allowed to the API’s clients.
• Event API products add information about the physical usage of the event API, e.g. the service level agreement, broker location(s) and protocols clients are supposed to use to connect. Developers can register applications and request access to event API products. Event API products are typically made available to developers in a place that they are already familiar with, where they go to find other types of APIs. In existing developer portals, APIM platforms (e.g. Gravitee and their API federation feature) or API marketplaces.

Check out this excellent explainer blog by my colleague Swen-Helge Huber on When to Use Events or Event APIs; Explain it Like a Muppet

When to Use Each

The choice between using Event APIs and Event API Products depends on your role, objectives, and the stage of your event-driven architecture lifecycle.

Use Event APIs When:

You Are Designing and Governing Events: If your goal is to design, catalog, and manage event flows between applications, Event APIs are the right choice. They allow architects and designers to define reusable event interfaces without worrying about runtime specifics.

Example: An architect defining a set of related events (e.g., order creation, order update, order cancellation) for an e-commerce system.

You Need Reusability: Event APIs are ideal when you want to create reusable event definitions that can be shared across multiple applications or application domains.

Example: A financial institution creating a standardized Event API for transaction events that can be used by multiple banking applications.

You Are Focused on Governance: Event APIs are crucial for enforcing governance policies, such as topic naming conventions, payload schemas, and lifecycle management.

Example: Ensuring all events related to customer data updates follow a consistent schema and topic structure.

You Are in the Design Phase: During the design phase of an EDA, Event APIs help visualize and model event flows, making it easier to collaborate across teams. Example: Using the Solace Event Portal to model event flows for a logistics system, specifying which applications publish or subscribe to events like shipment status updates.

Use Event API Products When:

• You Are Ready to Operationalize Events: If you need to make events available to developers for actual integration into applications, Event API Products are the way to go. They provide the connection details and policies needed for runtime use.

Example: Packaging a set of logistics-related Event APIs (e.g., shipment status, delivery confirmation) into an Event API Product for use by external logistics partners.

• You Want to Enhance Developer Experience: Event API Products are ideal when you want to provide a seamless developer experience, offering all necessary details (e.g., AsyncAPI documents, connection endpoints, SLAs) in a single package.

Example: Exposing an Event API Product to developers via an API marketplace, allowing them to quickly integrate real-time stock updates into their retail applications.

• You Need to Bundle Events for Specific Use Cases: Event API Products allow you to bundle multiple Event APIs for a specific business use case or target developer profile, making it easier for developers to find and use relevant events.

Example: Creating an Event API Product for real-time fraud detection, bundling events like transaction initiation, risk score updates, and fraud alerts.

• You Are Integrating with Developer Portals or Marketplaces: Event API Products are designed for integration with existing developer portals or API management platforms (e.g., Gravitee, Apigee, Axway, Kong), making events discoverable alongside REST APIs.

Example: Publishing an Event API Product to a developer portal so internal developers can access customer notification events alongside RESTful customer data APIs.

• You Need to Enforce Runtime Policies: Event API Products allow you to define runtime policies, such as event retention quotas or quality-of-service settings, ensuring consistent performance and compliance.

Example: Defining an Event API Product for IoT sensor data with specific retention policies to manage storage and performance on the event broker.

Practical Considerations

Cost and Complexity

• Event APIs are simpler and less costly to manage, as they focus on design and governance within the Solace Event Portal. They are ideal for organizations in the early stages of EDA adoption or those with limited integration needs.
• Event API Products add complexity and potential cost, as they require integration with developer portals, API marketplaces, or custom plugins. They are better suited for mature EDA implementations or organizations aiming to expose events to a wide audience (e.g., external partners, third-party developers).

Scalability

• Event APIs are scalable for internal use, allowing organizations to grow their event catalog without immediate operational overhead.
• Event API Products are more scalable for external or enterprise-wide use, as they provide a standardized way to distribute events across diverse environments and teams.

Integration with Existing Tools

• Event APIs can be exported as AsyncAPI documents, making them useful for integration with code generation tools or internal documentation systems.
• Event API Products are better suited for integration with broader API management ecosystems, such as unified API management platforms that handle both synchronous (REST) and asynchronous (event) APIs.

In summary, Event APIs and Event API Products serve complementary roles in Solace PubSub+.

• Use Event APIs for designing, governing, and reusing event definitions, especially during the early stages of EDA adoption or for internal use.
• Use Event API Products when you are ready to operationalize events, enhance developer experience, and distribute events to a wider audience, particularly in production environments or external integrations.

By understanding your goals and the maturity of your EDA, you can choose the right tool for the job, leveraging the full power of Solace PubSub+ to build robust, real-time systems.