posted by chriskapp on
With this post we are really happy to announce the availability of Fusio 2.0. This release marks a huge milestone for the project and we are looking forward to change the way how APIs are build and managed. In the following we provide a list of a all important changes, please take a look at the previous RC posts for an in-depth explanation of all changes.
In previous versions of Fusio the internal backend and consumer API where based on custom controllers which handled the request and response. We have now converted all controllers to Fusio actions, and added the fitting schemas and routes to the database, this means basically that now the complete backend API runs also on Fusio. We have added a new category to most resources so that you dont see all internal actions and schemas at the backend but in the future it might be possible to select such a category. This means also you can easily reuse any internal Fusio action in your API.
RPC is now a first class citizen style to invoke an action. This means you can call every route action also
via JsonRPC. It supports also batch calls to improve performance. An action receives now a RequestInterface
instance which has two implementations: HttpRequest and RpcRequest. If you invoke an
action via a route your action receives a HttpRequest, if you call it via JsonRPC your action
receives a RpcRequest. To build actions which work in both ways you can simply use the get
and getPayload method which are defined at the RequestInterface. All internal backend
actions can be called via HTTP or RPC.
It is now possible configure an action as async action. This means Fusio will directly return a 202 Accepted
response and puts the request into a queue to execute it at the background. This can be useful for
expensive actions. There is a new console command action:queue which executes all queued actions.
Fusio uses now TypeSchema instead of JsonSchema. TypeSchema is designed to describe data models in a language neutral format. Through this we can now better describe our data and generate much better SDK code.
The deploy command reads all meta files at the resource folder and deploys those resources to the internal API. It is now possible to deploy those change to a remote Fusio instance. By default Fusio uses an internal transport so that the deploy command does not actually send HTTP requests to the server but invokes them internally. If you deploy to a remote instance we send actual HTTP requests. Because of this change you need now to login through the "login" command, which requests a fitting access token.
We have now moved all CLI commands which talk to the API to a separate package so that you can also use these commands as standalone CLI app. Basically those CLI commands are an alternative to the backend app which allows you to control and configure Fusio via CLI.
We have implemented a new role system. A role defines the scopes which are allowed for a user. It also assigns a category for a user, a user can then manage only resources in this category. There is a default role which every new user receives.
We have updated our PHP and Javascript client SDK which can be used to access the internal Fusio API. It is also possible to generate such an SDK for the API which you build with Fusio.
In previous versions the apps folder was separated from the public folder. The idea was that a user has to setup a separate sub-domain to service the apps folder. This makes setup a Fusio instance more complicated, because of this we have moved the apps folder into the public folder. If you want to create such a sub-domain setup you can still easily move the folder to a separate location.