It is tough to stay up to speed on what is happening across the API landscape. Things move fast, and when you have your head down taking care of business, you don't always have the time to pick your head up and tune into what is going on. It can be tough to understand what is happening with traditional web API design, as well as Hypermedia, GraphQL, and microservices evolutions in the sector. Let alone, faster evolving approaches using Kafka, AMQP, MQTT, WebSub that are emerging to define the event-driven API space. Luck for you, tuning into what is going on is our job here at Streamdata.io
"If you need help understand what people mean when
they say event-driven architecture, we are here for you."
While our primary goal is all about selling our API streaming services, we see it as our mission to help our customers make sense of the existing opportunity that exists across the API landscape. We've discussed how webhooks are one sign of API platforms maturing
towards a more event-driven approach to using APIs, and clearly leading edge players who have the resources to implement Kafka and other real time messaging solutions, but what about everyone else? How does the average API provider, or API service provider selling their tools and services to the space begin understanding this evolution in how we are using APIs? Ultimately, it really depends how far along on your API journey you are. Do you have an active API presence? Does your platform provide webhooks? How many other 3rd party APIs do you consume? There are many aspects of doing business with APIs which will determine what you should be considering next when it comes to understanding your position in the event-driven landscape.
If you don't have a robust, existing API presence--this is where you should be focusing. Sure, you'll want to study up on some event-driven concepts to stay up to speed, but with the ability to quickly define, deploy, and manage simple web APIs, event-driven anything won't be a reality. If you have an active API presence, then mapping out, analyzing, and defining the events that are already occurring is where you should be looking to invest next. Much like API management did for the provider side, and testing has done for the client side, looking at your operations through an event-driven lens will show you new and interesting things that are already occurring your platform. After that, if you already have a handle on the events occurring via your operations, you are probably looking at how to better define, refine, and open up your platform for more publishing and subscription channels. We are working in all of these areas, and actively working with our customers to understand, develop strategies, and execute on an event-driven vision in 2018.
We don't expect our customers to be 100% ready for a real time streaming, event-driven world. Our role is to not just sell them a service to help enable this world for them, but also figure out how they can prepare, evolve, and maximize operations, moving things forward to an event-driven reality. If you need help understand what people mean when they say event-driven architecture, we are here for you. There is no shame in being behind in this emerging world. We are happy to sit down with you and help define what event-driven means to your company, organization, institution, or government agency. No expectations. We are just looking to help understand your position, and try and find a way to get you further down the road towards operating in response to the meaningful events that are already occurring across your business, and throughout the industry you operate within.