What's Next
Top Priority
These are the issues and improvements that we plan to fix before going out of beta.
Mature API
mion is in the early stages of development, so the first priority is to establish a robust and developer-friendly API.
To avoid maintainer burnout once we reach v1, we want to maintain long release cycles and not add too many new features.
Client Improvements
Currently, the client size is quite large (65Kb), so we are looking into alternatives to reduce the bundle size.
This might involve using a different serialization library and validating only on the server.
Strong Typed Errors
We are investigating making RpcError a generic error for better static type checking and error handling.
I.E: RpcError<500, ErrorCode>
Support More Serverless Platforms
At the moment just AWS Lambda is supported, but we planning into add support for at least Google-Cloud and Azure-Serverless platforms.
Compilation Step?
At the moment, there is no compilation required. This can be an advantage in some cases (full stack or monorepos) but a disadvantage in others.
With a compilation step, we would not require an initial query from the client to get route metadata.
We could automatically generate an npm package including only type definitions of the backend and standardize how backed types get imported in the client.
We are looking into pros and cons and will most probably be an optional step if implemented.
Extra Features
These new features involves quite a bit of work and complexity so will be implemented once mion gets adopted or ideally has more maintainers.
Merging Route Calls
mion has been designed from minute one so that in the future, we can easily merge multiple calls.
This will allow us to merge all initial page requests into a single one, debounce requests, and add many more features.
Output Input Chaining
Following the concept of merging requests, a step forward would be using the output of one request as input for another so some logic can be directed by the client but executed in the server.
Our Own Validation and Serialization
At the moment, we use @deepkit for validation and serialization.
This is an amazing library but is oriented toward enterprise applications and the size of the libraries can be quite big to include in the client.
Also a mayor drawback is that it can't be used in some edge computing platforms like CloudFare as deepkit uses a JIT compiler.