Idea to modernize the technological stack

[hongquan]

• [x] Use Poetry to manage dependency
• [ ] Use Dynaconf to divide and load settings by environment.
• [ ] Switch to an ASGI framework.

The reason of ASGI is:

• We seems to support async communication (SocketIO), but Flask is synchronous and is not actively updated (stay at version 1 for too many years).
• A spec for async-friendly Python web framework has been introduced for a while: ASGI. It is so widely supported that, there are many micro-frameworks made, and even big framework like Django also supports it.
• Integration of Flask-SocketIO looks not smooth. I feel weird when we have to add environment variable INTEGRATE_SOCKETIO, which will not happen if we use ASGI-supporting framework.

In addition, I propose that if we use WebSocket, just use plain WebSocket instead of SocketIO. SocketIO is WebSocket, adding a protocol layer which are private to SocketIO community. It brings no other benefit than just locking us up with NodeJS ecosystem. In other word, using SocketIO on backend will force client side to use SocketIO-supported libraries too. If we use plain WebSocket at backend, the clients just need to support general WebSocket, no SocketIO specific.

The ASGI idea is a very big change and I don't expect it to happen soon.

[iamareebjamal]

• Will look into poetry if it is not as slow as pipenv and does not drastically increase docker build time
• We already use .env locally and config.py with environment variables to load the config, so Dynaconf would just be a fancier option with more supported formats, but that doesn't matter in production because we configure it using environment variables. It'll just help in local development, but I think .env is enough for that. Another case for .env is that it is supported both via flask-dotenv and docker so there is a single source of truth for settings

SocketIO isn't working and removed from the system since v2. We run on eventlet worker to make WSGI somewhat asynchronous. I'm afraid ASGI won't be possible in foreseeable future because everything from ORM to HTTP layer in the project is synchronous. Even if Django has support for ASGI views, they don't have support for ASGI ORM and I don't think they will without breaking changes. Having async ORM is unfortunately not a task which can be migrated bit by bit as a single async function needs all its callers to be async and thus the runtime/server to be async as well. And calling a sync function in async framework is blocking the entire event loop. So, it's all or none. So unless SQLAlchemy adds a middle ground of supporting both, which I don't think it will since its author had written against the case of async ORMs in general single threaded applications regarding performance, we won't have a means to move to an ASGI framework. Besides, the heavy lifting of the API is done by flask-json-restapi which is inherently tied to flask's sync API and there is no async alternative for that as well.

[hongquan]

I am aware of lacking async ORM, but the current stack of Flask + SQAlchemy is not better. At least in ASGI, we can convert non-ORM parts to true async, still better than current stack where every things are still synchronous.

Another things about SQLAlchemy: SQLAlchemy ORM is not async-ready, but SQLAlchemy Core is. Actually, SQLAlchemy Core is not related with "sync or async", because it is just "query builder", it doesn't involve any IO.

Benefit of Dynaconf (not just fanciness):

• Data saved in environment variable is just text, it doesn't have data type, i.e, if you write "MYVAR=1", then MYVAR is just string "1", not number. We have to have additional layer to coerce the variables.
• When we change from one environment (development to production, for example), we have to pass many variables. But with Dynaconf, we just pass one variable, like "ENV_FOR_OEVENT=production".

[hongquan]

Because we no longer use SocketIO, let's skip the ASGI idea.

[ShreehariVaasishta]

• Will look into poetry if it is not as slow as pipenv and does not drastically increase docker build time
• We already use .env locally and config.py with environment variables to load the config, so Dynaconf would just be a fancier option with more supported formats, but that doesn't matter in production because we configure it using environment variables. It'll just help in local development, but I think .env is enough for that. Another case for .env is that it is supported both via flask-dotenv and docker so there is a single source of truth for settings

SocketIO isn't working and removed from the system since v2. We run on eventlet worker to make WSGI somewhat asynchronous. I'm afraid ASGI won't be possible in foreseeable future because everything from ORM to HTTP layer in the project is synchronous. Even if Django has support for ASGI views, they don't have support for ASGI ORM and I don't think they will without breaking changes. Having async ORM is unfortunately not a task which can be migrated bit by bit as a single async function needs all its callers to be async and thus the runtime/server to be async as well. And calling a sync function in async framework is blocking the entire event loop. So, it's all or none. So unless SQLAlchemy adds a middle ground of supporting both, which I don't think it will since its author had written against the case of async ORMs in general single threaded applications regarding performance, we won't have a means to move to an ASGI framework. Besides, the heavy lifting of the API is done by flask-json-restapi which is inherently tied to flask's sync API and there is no async alternative for that as well.

FYI FastAPI can be used. It seems promising.

[iamareebjamal]

FYI FastAPI can be used. It seems promising.

No, it can't be. Read the comment again. It'll take us months to migrate. There is no compatibility between ORM or views in FastAPI. It'll literally be a rewrite, which we don't want to do. There are much more important things to handle than rewriting the entire server.

[ShreehariVaasishta]

FYI FastAPI can be used. It seems promising.

No, it can't be. Read the comment again. It'll take us months to migrate. There is no compatibility between ORM or views in FastAPI. It'll literally be a rewrite, which we don't want to do. There are much more important things to handle than rewriting the entire server.

Okay, got it.