Mule uses components to conduct backend processes for specific business logic (like checking the customer and inventory databases). Then, the components route messages to the correct application (such as an order fulfillment system). This use is called a Staged Event-Driven Architecture (SEDA) for core asynchronous message processing in flows. Importantly, components don't have to have any Mule-specific code; they can simply be POJOs, Spring beans, Java beans, Groovy scripts, or web services containing the business logic for processing data. Components can even be developed in other languages such as Python, JavaScript, Ruby, and PHP. Mule’s catalog of building blocks includes the most commonly used Enterprise Integration Patterns.
A flow, therefore, is the construct within which you link together several individual components (i.e. building blocks) to handle the receipt, processing, and eventual routing of a message. You can connect many flows together to build a complete application which you can then deploy on premise, on Mule, on another application server, or in the cloud. Practically speaking, you could build, deploy, and run a Mule application in a matter of hours, rather than spending weeks or months building point-to-point connections between systems. Studio, Mule’s Eclipse-based graphical IDE, makes it even easier to model, then configure, test, and deploy your applications. Mule is so named because it “carries the heavy development load” of connecting systems.
Carte is a simple Jekyll based documentation website for APIs. It is designed as a boilerplate to build your own documentation and is heavily inspired from Swagger and I/O docs. Fork it, add specifications for your APIs calls and customize the theme. Go ahead, see if we care.
We built Carte because the existing options (Swagger and the likes) were trying to do too much and did not match our needs:
Most of our API calls are sending JSON objects, as opposed to a series of parameters,
Being able to query the real API is nice, but running anything but GET calls can get tricky ("What do you mean I deleted my stuff? I was just trying out the API calls!"),
Overall, setting up a separate server for what really requires a good static documentation seemed overkill.