Middleware
Middleware offers powerful functionality to control the behavior of your APIs at pivotal points of execution.
All plans include one instance of middleware at no charge.
Our Scale and higher plans include unlimited middleware.
What is middleware?
Middleware are separate pieces of logic that you build in Xano that can run before your API executes (even before input validation) or after your function stack is finished executing but before your API delivers its response.
Middleware can be applied at an API, API group, or workspace level. This means that you can apply the same middleware functionality to multiple API endpoints, or even your entire application, in one swing. You also have the ability to customize the middleware application at an API or API group level, meaning that if you want to apply your middleware to your entire application except a certain API or group, you can do that too.
Middleware offers the same functionality that any other function stack can utilize.
Middleware Availability
Middleware is available in both free and paid versions.
Free Version
All of our paid plans can utilize the free version of Middleware. In the free version, you can create one Middleware function stack to assign as you see fit across your workspace.
Paid Version
The paid version of Middleware is included with our Scale plan. The premium version allows for unlimited creation and assignment of Middleware on APIs, functions, or tasks. Additional defaults are supported at the API group level, which can either be customized or inherited from workspace defaults.
If your plan includes the Compliance Center, you'll also be able to access reporting on middleware usage from there.
How does middleware work?
Types of Middleware
Pre-Middleware
Pre-middleware executes before any input validation takes place. For example, if you have one of your inputs built in such a way that it requires a minimum string length, your pre-middleware won't be aware of this.
Post-Middleware
Post-middleware executes after the function stack ends, but before the API delivers a response. The output of the middleware can be merged into the response your API generates, or replace it entirely.
Building Middleware
Once you've added your middleware, you can begin building your logic, just like any other function stack. There are a couple of key differences to be aware of, however.
Inputs
Middleware inputs are static and can not be changed. They will automatically contain the variables coming from the parent object. This means that for pre-middleware, the parent object will provide the inputs contained in the API request. For post-middleware, this will be your API response.
When referencing those inputs, you will do so from inside the
varsvariable. So, if you send an input labeledtext, you'd reference this inside a middleware stack usingvars.textThe type contains whether this is running as pre or post middleware, and can not be changed.
Response
Middleware responses have the option to either merge or replace the response in the parent object.
Merge means that middleware will generate its response and merge it with the response of the parent object. For example, if my API contains an input called
textand my pre-middleware generates a variable called number, and my response type is set to merge, we could use a Get All Input function to retrieve those additional inputs. Merge also means that any items in the response that have the same name as your inputs will be replaced in the process, as you can not have two keys in a JSON object of the same name.Replace means that your middleware will essentially ignore all of the inputs given to it when it generates a response. For example, if I am building pre-middleware, and I send it an input called 'text', and it does not deliver that in the response, that 'text' input will no longer be available in the API's function stack.
Exception Preferences
Silent ignores errors thrown in middleware and allows the API to return the response without returning the error encountered
Rethrow allows post-middleware to execute for the purposes of error logging in your pre-middleware
Critical halts all execution if an error occurs
For this example, we'll be using the following middleware:
...with the following API:
The middleware is responsible for checking the 'text' API to determine if it has a value of "Hello" before allowing access.
After you've built your middleware, you're ready to apply it.
Applying Middleware
Applying Middleware to your Entire Workspace
Applying Middleware to an API Group or Single API
Middleware applications are inherited from their parent object. This means that any middleware you apply at a workspace level will be populated down to each API group and API. You do have the ability to customize the middleware on API groups and individual APIs for more granular control over the middleware that applies to that workflow.
Just click the settings icon inside of an API group or API, choose Middleware, and check the Customize box to update the middleware for that specific group or API.
Why use Middleware?
Flexibility
Middleware can be much more flexible in certain scenarios, such as input validation. While Xano currently offers several basic filters for input validation, such as enforcing a certain number of characters, middleware offers the power of an entire function stack to not only validate those inputs in new ways, but even transform and manipulate them, should the need arise.
Build Efficiency
One of the key benefits to using middleware, as opposed to using a custom function for example, is the methods at which middleware can be applied. Having the ability to insert both PRE and POST middleware in your function stacks offers more versatile and controlled execution of the logic contained within them.
Not only that, Middleware can also be applied at a workspace or API group level, giving you a one-swing approach to applying middleware to all of your API endpoints at once, instead of having to go through each API one at a time to apply a custom function.
Last updated
