Bread or Sandwich? Salesforce’ Apex REST Endpoints vs. Platform Events
Once upon a time, a baker would spend ages making sure that every loaf of bread was a work of art. People paid a lot of money to get the bread for its freshness and taste. Until one day, someone invented a sandwich.
In one fell swoop, the nuances of bread loaf were just another thing amidst all the toppings, cheese and mustard. Suddenly, people realized that any decent bread would do and the effort for making bread from scratch was less useful. This is the story of Apex REST.
As companies embark on digital transformation — innovate from product to services, subscriptions, on-demand models and superior user experience, the need to make better technology sandwiches is more pronounced than ever.
Apex REST implementation essentially turn Apex code into a REST API endpoints. This approach rewards the developer with incredible flexibility to determine how fine-grained or coarse-grained their services will be.
Implementations can use Apex REST to act as an event producer and consumer, but not as an event bus in the classic ESB/Enterprise Messaging style. It also means that the event message’s composition, translation and any other related logic will need to be implemented through the code in Apex.
Apex Rest is the idea of baking your own bread from scratch.
Salesforce makes it fairly straightforward to expose Apex endpoints, enable oAuth or other authentication mechanism and offer a simple-standards based approach to integrate with other systems, mobile clients etc.
However, operationally, the onus of building it all — including considerations for API limits, scaling up to Millions of users etc., is all up to the baker…oops, I meant the architect/developer.
This approach works for simple integration between 2–3 systems, and is a good choice if there is already has an integration infrastructure that Salesforce is connecting to it as it is easy to implement and whole grain ;-)
Architecturally speaking, integration of this nature tend to be ‘point-to-point’, and consequently, the enterprise architecture ends up a nightmare to manage and evolve from. It also does not offer future readiness to support an event-driven architecture, often a key technology capability for sophisticated user experience and digital transformation.
Summary: A REST API based integration is simple to implement, but operationally and architecturally, there are better choices to make a technology sandwich.
How is Platform events different? And where does it fit in comparison with REST API, Streaming data solutions (Apache Kafka/AWS Kinesis), and of course, its big brother ESB — Mulesoft? Let’s start with what are Platform events.
Just like REST, Salesforce’s Platform Events(PE) enables Apex code to integrate with both Event producer and consumer scenarios, but that is where the similarity stops. In addition to this ability with our sliced bread of PE infrastructure, we get more goodies…
With PE, event messages get to ride on the event bus that offers message persistence for 24 hours, massive scalability and declarative ability to work with messages via Process builder and Flows.
PE one-ups on the classic MQ design by using a data streaming that is inspired by Apache Kafka. That makes it perfect for social-network scale pub/sub scenarios to connect events with Millions of subscribers/clients. And with the newly GA’d High volume Platform Events, those limits can be much higher.
How is this sausage…oops, Sandwich made? PE and its twin, Streaming API use long polling(remember AJAX), where the server holds a client connection and notifies them when an event occurs. This is based on CometD, which is an HTTP based event routing bus that implements the Bayeux protocol.
PE ensures that an event-driven architecture solution can be implemented using Process Builder, Flows, Apex or JavaScript. Any external system can connect/publish events using SObjects API and listen in using CometD libraries. Easily build a simple integration today, and scale it up for IoT, Mobile Apps, Social media sites etc. when needed, without breaking a sweat.
Platform events is the idea of making a sandwich, and then some…with no time spent on baking the bread.
For example, declaratively create a flow-based wizard, expose it to Community Guest user for no extra licensing cost and offer a seamlessly integrated user experience. With fairly limited effort, we can now build complex logical UI flows, integrate them via platform events to other internal/external system and offer a delectable technology sandwich.
So, what can a PE based architecture not do? It does not include native adapters for external apps, thus requiring effort to integrate via CometD. Also, more complex transformation, endpoint virtualization for various protocols, and full-featured ESB capabilities are not what it is about. That is where Mulesoft would fit in.
Summary: Platform events based solution offers an event-driven scalable architecture, and offer a more extensible choice without racking up technical debt with custom development. It also offers an enterprise-grade messaging capability and allows developers to focus on making a great sandwich, instead of baking the bread.
