Project Mashling—Build a Smarter API With Evented Microservices

Reading Time: 3 minutes

At TIBCO NOW today, TIBCO announced a new open source project named Project Mashling. This is an ultralightweight microgateway built on the Go language, that allows developers to event-enable microservices.

The reason this is important is that it allows developers to move beyond the rather restrictive request/response message patterns supported with REST APIs and build a new class of APIs that can interact in very flexible ways with evented microservices on the backend.

At this point, you might be asking yourself “What the heck is an evented API and why should I care?” There are two things we need to focus on to answer that question:

—Benefits of microservices-led application architecture
—What you can do with evented microservices

According to research from Forrester and Gartner, companies are using microservices for the majority of new application development, and it is the preferred approach for getting a specific functionality or data from legacy applications, using a targeted refactoring approach that minimizes rework of the application.

A lot of digital transformation projects involve the use of open APIs and mobile applications. Building scale into these apps is a lot easier when you use microservices, since you only have to scale the microservice(s) that are potential bottlenecks, and not the entire application instance. It’s the cheapest and fastest way to get more mileage out of your existing monolithic apps.

When you are building a new application from scratch, a microservices architecture gives you fine grained control of the business functionality in the app, because the application is really just a collection of very simple functions that are loosely coupled as microservices. This is great when it comes time to make a change, both because of the limited scope of any given microservice, but also due to the loosely coupled architecture.

Building microservices has value in itself, but it gets really interesting when you start event-enabling those microservices.

One of the biggest advantages of an evented microservice built with Project Mashling is that it can interact with other microservices when you incorporate pub/sub MEP’s. The microservice API understands events and can handle that event in any number of pre-defined ways, including a response, or forwarding of data to one or more other microservices.

An example would be an instrumented device that is programmed to publish data to a microservice as an event, when it exceeds a predetermined threshold. In banking, credit card transactions could be monitored and forward to a microservice for handling when fraud is suspected. In both of these cases, the microservice isn’t responding to a request, it’s consuming and responding to an event.

Project Mashling allows you to build simple “recipes” that instruct the microservice how to respond to an event. The recipes are built with easy-to-use visual tooling provided as part of the open source project, and anyone in the Mashling community can share recipes by publishing them on the website.

Project Mashling has no dependencies on any TIBCO product, and in fact, we encourage you to use Mashling as part of your overall open source software stack. For example, it’s a great complement to service meshes such as Itsio or Envoy, and is compatible with Kafka or RabbitMQ. Of course, it also works just fine with TIBCO’s own messaging products.

And when we say ultralightweight microgateway, we mean it. Project Mashing has a footprint of less than 10MB! This makes it ideal as an embeddable gateway for edge IoT devices or industrial IoT networks, where small, memory constrained instrumented devices are common.

We’re just getting started with project Mashling, but are super excited about the possibilities it opens up for microservices developers and are looking forward to seeing what people do with the technology. Go to our github page and check it out.

Useful links:

Project Mashling github page:
Recipes and Documentation:
Community based support: