Incorporating asynction into existing flask API with socketio events about asynction HOT 2 CLOSED

Hey @AFlowOfCode! Thanks for your feedback and apologies for the late response.

Asynction is built on top of Flask-SocketIO and is fully compatible with it. Essentially, the AsynctionSocketIO class (which is the entrypoint to any asynction app) inherits from the flask_socketio.SocketIO class. Asynction only adds auxiliary capabilities on top of the core functionality of FlaskSocketIO, which is left intact.

Wrt onboarding an existing API to Asynction, the main piece of work would be to come up with the actual spec of your API, which is then going to be fed into Asynction. You may find this blog post particularly helpful when attempting to model your existing SocketIO API in AsyncAPI. Once you got your spec finalised, transitioning from vanilla FlaskSocketIO to Asynction flavoured FlaskSocketIO should be relatively trivial, especially for an application involving <10 events.

A typical migration would involve:

1. Modifying the entrypoint to your FlaskSocketIO app to use the AsynctionSocketIO class instead of flask_socketio.SocketIO. In a typical Flask-SocketIO setup, this should just be replacing the class name, and passing the additional spec_path argument to the constructor.
2. Removing the now redundant @socketio decorators from your existing event and error handlers. Asynction auto-registers these handlers by inspecting the x-handler references within the spec file.

Since this is an operational API that clients currently depend on, I would strongly advise in favour of disabling validation of incoming event payloads, especially when the migration is first rolled out (see the validation parameter of the AsynctionSocketIO constructor). This would prevent existing client integrations breaking due to misdocumentation of existing event messages. Think of a scenario where an existing client arbitrarily passes additional arguments as part of the event payload. FlaskSocketIO does not care about schemata, and hence no exceptions are raised. However, Asynction may introduce a strict event schema which does not allow additional arguments. It's important to prevent breaking existing client integrations, and disabling the validation would ensure that. You may later enable the validation incrementally, starting with loose schemata and testing at pre-production environments, only promoting it to prod once you are confident that no existing integrations are to be broken.

Please take all of the above with a pinch of salt. The answer to your question vastly depends on the specifics of your application. Let me know if you would need further help. Will try to be more swift with my response times.

from asynction.

The blog post looks very helpful. I'll close the issue as this has given me an idea of what it will take and a great starting point. Thanks for your thorough response!

from asynction.