Feature pairity with other backend frameworks (nest.js, fast api, flask, etc...)

[rodrigomf24]

Context

Motia provides an entire backend ecosystem for software developers, an essential part of this ecosystem is its framework. The framework is solid, but there are essential features that most backend frameworks don't skimp on and its up to the developer to use these features with the required amount of security/considerations when their systems are running on a live environment.

Some of these basic features are customizations of the HTTP layer such as:

• cors
• middleware (authentication, body parsers, allowed headers, etc...)

What do we need?

Motia steps sit at the core of the framework, currently there is support for some configurations at the step level (i.e.: authentication), but for flows that have multiple API steps, the configuration per step becomes a limitation.

Here are some of the proposed changes:

Allow global middleware that applies for a group of steps

Introduce a new middleware primitive into the Motia architecture, that allows for middleware to be executed prior to the execution of a given step (part of the lifecycle of a step). This middleware can be authn or authz, cors (for api steps). This middleware could be configured to apply to all steps in a motia project (agnostic of flow), or to a specific group of flows.

Allow for http configurations for a given step or group of API steps

Allow API steps to be configured for their HTTP layer, i.e.: cors, body request limits, allowed headers (i.e.: content-type)

For self-hosted projects, allow configuration of the express server that hosts the api endpoints and workbench

For projects that are self-hosted and rely on the express server spawned from the motia start command, allow to enable specific express features such as:

• cors
• body parsers (multer, busboy, etc...)

[sergiofilhowz]

We have a simple middleware configuration, it's per step, but ideally we should have a global middleware configuration (similarly to what fastify has)

but multer and body parser, we don't have plans to supporting it, in fact, we want to discourage devs from uploading to steps. Instead, we want to provide a built-in support for storage and file uploads

[mfpiccolo]

I agree in terms of best practices, but it does seem limiting to not support these in principle