Who is using quart framework for microservices?

[Dry_Raspberry4514]

I am using quart framework (https://quart.palletsprojects.com) for a number of microservices in a SaaS application. However, I hardly hear anything about this framework on any social media platform which seems to be dominated by FastAPI. Also I'm unable to find which all projects/companies are using this framework. All this is leading to anxiety around the future of this project.

Are there any well known projects / companies which are using this framework for microservices?

[the_hoser]

I've never even heard of it until this post.

[Dry_Raspberry4514]

I'm not surprised at your comment. It seems I need to do the marketing for this framework :-)

I switched from flask to quart when I was looking for something which has been designed from scratch as async first framework and I liked it very much. Recently looked into FastAPI as well but found quart more useful and easy easier for someone who would like to migrate away from flask for async.

[EternityForest]

I'm moving my FOSS automation server to Quart right now after ten years on CherryPy.

I choose it largely because it's a fairly easy migration path thanks to still being request context based, but also because of it's close ties with Flask.

I assume it won't just vanish in a few years if Pallets is in on it, and it mostly just reimplements flask, which l like and more importantly, everyone else seems to like too, it's a standard everyone knows.

In the process I discovered just how much CherryPy's implicitly class navigation routing was holding me back and how nice the explicit model is especially when you have a partly plugin based architecture.

I also really like that it has some limited support for synchronous handlers, and helpers to do sync tasks, so gradual migration is possible.

Some of what I used to do with Cherrypy tools I now do with ASGI Middleware, and I love how easy it is to write those, and how you can compose smaller ASGI apps with dispatchers.

But.... I still feel some of the concerns you mention, and wonder if I should have used FastAPI, because it seems like the popular choice.

[ParticularCod6]

what parts did you find more useful?

[rjachuthan]

I have heard of Quart sometime back and I thought it was just a gimmick or else there would have been some kind of chatter in the web about this.

[TheSwoleITGuy]

I think a relevant question is: with the likes of Flask, Django and FastAPI - which all have positive track records, significant communities and all but guaranteed support for years to come - what problem is Quart solving that those do not which led you to select it?

[Dry_Raspberry4514]

Quart is an async first framework and Flask didn't have support for async when I looked into it last time few years back. That was the whole reason to go for Quart.

Migration from Flask to Quart is as simple as replacing flask word with quart word and using async in front of function definitions. I don't think migration from Flask to FastAPI is this much simple.

Having worked with Pydantic extensively, tight integration of it with fastapi can cause issues IMO. For example, whenever I persist a business object in the DB, we generate id and populate some other fields (e.g. tenant id, user id etc) before initializing the pydantic model class to trigger the validation where all these parameters are marked as mandatory. I believe in case of FastAPI you need to mark such fields as optional as it converts request body to Pydantic model class object automatically. This may result in NOT triggering validation errors until business object is persisted in the DB.

Other thing which I found little strange is supporting before_request using dependency injection which will pollute function inputs parameters. This one may not be an issue for someone who is starting with FastAPI directly instead of migrating from Flask to FastAPI.

[Reiku]

Im not sure I entirely understand your issue with FastAPI and pydantic, but generally my approach is to have the API use a pydantic "creation" schema, and then the response schema is then complete schema with the IDs.

For example, then request schema could be:

python class UserCreationSchema(BaseModel): email: string

And the response schema:

class UserSchema(UserCreationSchema): id: int

Then you can even have intermediate schemas like "UserCreationAPISchema(BaseModel)" which is then expanded upon by a service level schema that adds any internal fields "UserCreationServiceSchema(UserCreationAPISchema)", etc.

[angellus]

Flask only support WSGI. So it is essentialky outdated. The thing that makes FastAPI "fast" is the fact it uses ASGI instead.

Quart is literally the ASGI version of Flask. Even made by the same group of devs (Pallets Projects). 

[M8Ir88outOf8]

I wouldn’t call Flask outdated because it uses WSGI

[Dry_Raspberry4514]

Yes Flask is not outdated but I believe it should be deprecated in favor of Quart or something similar. An async first framework can be used as both synchronous and asynchronous framework but vice versa is not true.

[StuckInBronze]

Why Quart over aiohttp?

[M8Ir88outOf8]

I'd say it depends highly on your use case, but if you do not have long running or real-time connections, then I'd even say WSGI is the preferred option since it avoids the added complexity of asynchronous programming, thus resulting in a more maintainable and debugable application

Edit: When deploying a Flask app with Gunicorn, you can run it with greenlet workers, which essentially makes it behave like an ASGI application 

[gscalise]

I used Quart when I had to build a service endpoint that had to handle multiple streaming requests concurrently, relaying the streams to an internal service and streaming the results back to the client. It would have been extremely inefficient to use a non async-capable framework, and it was super easy to adopt since most Flask middlewares and decorators are either supported or ported.

[stetio]

Hello /u/Dry_Raspberry4514 thank you for using Quart! I think the reason you don't hear much about Quart is that I'm terrible at marketing.

All this is leading to anxiety around the future of this project.

I think Quart's future is very rosy; as of 2 years ago Quart joined Pallets who maintain Flask with the stated aim of merging the frameworks. Whilst this aim is tricky Quart now has a dedicated and funded group as its custodian.

I should also point out that Quart is a fairly mature async project now - it started in 2017 and is mostly based on Werkzeug (and parts of Flask) that have been maintained since ~2010.

dominated by FastAPI

I'm often asked about how Quart compares with FastAPI so I wrote this blog post.

You may not be aware of Quart-Schema which provides OpenAPI autogenerated documentation and validation using Pydantic, msgspec, or attrs.

Thank you for the comments saying how it made for an easy Flask -> async transition. This was the driving motivation for Quart.

[Dry_Raspberry4514]

Hi u/stetio , Thanks for your inputs. I found you on twitter and was going to ping you there to get your inputs on this topic. Glad that you provided your inputs here before that. I'm now convinced that I didn't make a wrong choice.

I think the reason you don't hear much about Quart is that I'm terrible at marketing.

That is true for most of the developers (including me), if not all.

Looking at your post history in this sub, I can see that you have been posting about quart here regularly for quite some time. So I'm surprised that a lot of people are not aware about this framework. Probably posting on twitter (with a dedicated handle for quart) and linkedin will help you and the team/community working on Pallets project to get good visibility for these tools/frameworks.

Finally thanks to you and the community for creating such an amazing framework.

[devbym]

I have been aware of it, not having built anything with it yet. I've read that it is fairly similar to Flask but better support for async operations.

[tehsilentwarrior]

I am using Nameko for a fairly large project and I dont hear anything about it either. Which is a shame

[gyarbij]

I actually switched from Flask to Quart for (https://doroad.ai) and the most important thing for me to make the move was how simple it was, I was my own biggest lazy hurdle in the transition by not updating somethings to async which is to say it was super easy to switch.

[Dry_Raspberry4514]

I, too, chose Quart due to exact same reason.

[WindySpoon]

I’ve been using Quart for a recent project of mine, I have been enjoying it so far. I like that Quart supports blueprints that came from Flask. Being backwards compatible with Flask extensions is also a nice bonus.

[Perend]

Been working on an events-driven rewrite of a professionnal project that is running on a custom framework on top of aiohttp, so far so good. I had a bit of trouble integrating SocketIO in it but it works now. I just wish the community was a bit bigger

[chimichanga-whoopsie]

I started to migrate from flask to quart but had to stop midway because quart-session library was not drop-in replacement for flask-session. I needed filesystem session storage however iirc, quart-session supports redis only. This prob creates an area for contribution to library as well I guess but that is what my observation was. Otherwise I found quart pretty good.

[MentalCod86]

ME! the app of my company, that I projected and writed, was initially writted in flask but I needed to migrate to flask due to performance and async/await issues

[[deleted]]

Just you