Thoughts about the upcoming 2.0 release and beyond

posted by chriskapp on

This post should give you an insight about our thoughts for the upcoming 2.0 release and also describe plans which we have for the future.


The business logic of Fusio is defined inside an action. You can either use and configure an existing action or you you can develop a complete custom action. An action can then be assigned to a specific route, which invokes the action in case the route gets called. This action concept matches perfectly to the serverless design, so an action is equivalent to i.e. an AWS lambda function.

We are planing to build a deploy mechanism which lets you generate a serverless.yaml to deploy your complete Fusio application to a serverless platform. Currently we are looking at bref which simplifies this process for AWS. In the future it would be also possible to support other platforms like OpenWhisk or Google Cloud Functions.

This would enable the great use case, that you can start building your API on a cheaper self hosted bare-metal server and in case you need the scalability of a cloud provider you can move your complete API to a serverless version with a single command. This feature is probably not directly available for the 2.0 version but it is on our roadmap. Feel free to let us know in case you are interested.

API styles

Fusio provides multiple ways to access your action logic. Every style is useful for specific use cases and Fusio tries to help you to easily facilitate this for your API. With the 2.0 release we try to improve these ways even further. The following list describes the API styles which you get out of the box with Fusio:

  • Request/Response style

    The most common style to access APIs, you send a request to an endpoint and you receive directly the response of the endpoint. Fusio provides automatically an OpenAPI specification of all your endpoints.

  • RPC style

    Through the RPC style you can directly invoke actions based on the defined operation id. Fusio provides an JsonRPC endpoint, it is also possible to invoke multiple actions through a single call. For the 2.0 release we also plan to generate an OpenRPC specification, so that you can easily discover all available methods.

  • Event-based style

    Through the event based style your consumers register for specific events and all listeners will be notified in case your application triggers this event. For the 2.0 release we also plan to generate an AsyncAPI specification.


In the previous post we have talked about our code generation plans regarding client code. Beside this we have also plans to improve our generator service. This service helps your to generate complete Fusio applications based on different sources. Currently we support OpenAPI and Entity as source. In the future we will also make it possible to save specific configurations and also provide more sample configurations. Looking even further it would be possible to directly deploy such a generated application to a server. So also please let us know if you are interested in this feature or if you have specific use cases which we should consider.

So we hope we could share some of our thoughts and plans for Fusio. These are exciting times and we think that Fusio has a great future since it is a versatile tool to build APIs with some cool unique features.