SQLAlchemy

I'm considering moving from Flask to Quart, does anyone have some experience with this migration?

I expect possible problems with @{connexion}|tool:20479| which we use as OpenAPI specification.

Would be good if someone can point downsides of moving to the Quart framework so I can double-check if my plan is worth doing.

Other libs and tools used in the project: SQLAlchemy, alembic, PostgreSQL, Datadog

cons for now:

• Refactoring uncertainty (not sure how big of a task is it)
• Connexion might not work with Quart (moving to another library)
• ...

Merging Django ORM with SQLAlchemy for Easier Data Analysis (Video Inside)

Development of products with Django framework is usually easy and straightforward; great documentation, many tools out of the box, plenty of open source libraries and big community. Django ORM takes full control about SQL layer protecting you from mistakes, and underlying details of queries so you can spend more time on designing and building your application structure in Python code. However, sometimes such behavior may hurt - for example, when you’re building a project related to data analysis. Building advanced queries with Django is not very easy; it’s hard to read (in Python) and hard to understand what’s going on in SQL-level without logging or printing generated SQL queries somewhere. Moreover, such queries could not be efficient enough, so this will hit you back when you load more data into DB to play with. In one moment, you can find yourself doing too much raw SQL through Django cursor, and this is the moment when you should do a break and take a look on another interesting tool, which is placed right between ORM layer and the layer of raw SQL queries.

Unlike our frontend, we chose Flask, a microframework, for our backend. We use it with Python 3 and Gunicorn.

One of the reasons was that I have significant experience with this framework. However, it also was a rather straightforward choice given that our backend almost only serves REST APIs, and that most of the work is talking to the database with SQLAlchemy .

We could have gone with something like Hug but it is kind of early. We might revisit that decision for new services later on.

In the early days, the Uber backend system was a monolithic software architecture with several app servers and a single database. The system was mainly written in Python and used SQLALchemy as the ORM-layer to the database.

In early 2014, Uber faced the fact that given their trip growth —roughly 20% per month—the solution for storing trips was going to run out of steam, both in terms of storage volume and IOPS (Input/Output Operations Per Second) by the end of the year.

To fix this problem, project Mezzanine was launched. The whole system, which Uber simply calls Schemaless in homage to its design, is written in Python. The initial version took about 5 months from idea to production deployment.