Hacker News Reader

Comment by Majestic121 | Hacker News Reader

We went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970

We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the code.

I guess that's the issue when you pick projects maintained by one person, so for my next projects I might get back to something built on stronger grounds, like Django.

How is Django this day with modern Python constructs like typing in general and Pydantic models integration ?

View on HN

Hey! FastAPI author here. I do have a bunch of issues and PRs to review across the projects. But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. I even changed my working structure to optimize for more open source. Sadly, new issues and new discussions like that one linked asking why the other issues are not solved, don't really help, as they just add another issue for me to read and take care of. I'm also prioritizing the work that can have the most impact. For example recently I was helping a bit with AnyIO and Trio, as they are used underneath by FastAPI. And now I'm working on something for Pydantic, that would be used by SQLModel and FastAPI.

If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-fastapi/

One of the things that consumes time the most is handling issues by others. If you go and help them and they close those issues, that's a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs.

Totally understand your point, makes sense, and indeed if the community were to be more supportive with issues/PR it would be very helpful for the project.

Seeing this kind of topic fairly frequently, it would be great to understand the short/mid/long term plan for the project in terms of governance.

I guess we can all agree that having a single maintainer on a +40k stars project with huge adoption (amazing stuff btw) is unsustainable and extremely difficult, and can drive people away from adopting it in big corporations (I've seen a few comments on Github that mention this), and can make early adopters eerie.

I honestly have no idea on how to do that, but some other projects have been able to (fairly) successfully descentralize the development to be able to keep pace with the development.

It's obviously fair and understandable if the long term will still depend entirely on you, being the creator, you obviously have 100% right to do things the way you want, and nobody can argue against that.

I guess it could be helpful to give the community some guidance on what's the idea for the future of project, and whether it will have a more distributed governance or if it will continue being centralized.

Any of those paths is fine of course, I guess it would just help people deciding the framework choice for the future.

Yes, and one of the ways "documented here" is "Create a Pull Request"!

How is creating PRs going to get us "faster progress" when the very complaint from OP is that PRs are left to rot? And some PRs as simple as 1-line critical bugfixes that have been rotting for over 3 months? See, e.g., https://github.com/tiangolo/fastapi/issues/3665#issuecomment...

Shouldn't open PRs be prioritized over open issues anyway? Folks have put in the effort to not just complain about, but to FIX the bugs, and they are ignored.

> typing

I believe there's a third-party package "django-stubs" that provides type hints for Django code. For your own code, it's just Python in the end so you can type-hint it as you normally would.

> Pydantic models integration

There isn't as far as I know. Django has its own model layer however unlike Pydantic, Django's is purely for the DB level, it's not there to (de?)serialize JSON.

In the Django world you'd typically use Django Rest Framework serializers for that. Now you can use Pydantic and it probably won't be too much work to make them work with DRF, but whether it's worth it is a different matter - DRF gives you a lot of stuff for free such as auto-generating serializers based on DB models (including validation and everything) which you wouldn't get with Pydantic.

There is https://django-ninja.rest-framework.com/ which would be an alternative for DRF ,heavily inspired by FastApi, that integrates with Pydantic.

Pydantic allows you to write super clean (in comparison to DRF) serializers using just type hints, as opposed to the declarative approach of DRF serializers. It's really nice and refreshing.

Not to single you out, but are you or your business supporting the project (financially) in any way?

I sometimes get these almost angry emails about Gensim, my open source library. How come I'm not responding faster, merging PRs, fixing issues? For this critical popular project??!

Meanwhile, sponsorships are at 13% of the (not terribly ambitious) goal of $6k/month [0].

Yeah, that's why.

[0] https://github.com/sponsors/piskvorky

> How come I'm not responding faster, merging PRs, fixing issues? For this critical popular project??!

> Meanwhile, sponsorships are at 13% of the (not terribly ambitious) goal of $6k/month

The answer would then be: "because I have to keep another job to pay the bills" then? Hope you can get to your goal ASAP. Going by stupidly quick math, you have 12k stars for gesim alone, and that boils down that if every star on github payed 50 cents you'd already be there. I know that starring doesn't mean anything other than "hey, this looks interesting!", but then again 50 cents is probably cheap enough for a majority of those "stars" that they wouldn't even notice.

Also: thanks for creating and maintaining gensim!

Do you ever respond to these emails telling them that they can hire you to attend to their issue? If my business depended heavily on an open-source component that needed a bug fix, more often than not I would pay the person to spend their time to resolve it.

Often it is easier to get a business to pay a consulting fee for a specific thing rather than make a donation that goes into a general funding pool for a project.

Yes, I do. But it turns out that their issue is pretty much always only tangentially related to Gensim (or any other open source library / technology). They're solving a business problem. That's what brings them money, with which they pay me, and I acknowledge that.

This leaves me with two choices:

1. Help narrowly, with the Gensim part only. Pros: easy for me. Cons: doesn't truly help the customer; feels dirty.

2. Help solve their actual business problem. Even if it means not using ML at all (a very common outcome), or suggesting a different architecture.

In my experience, most companies are so lost as to what to expect from ML, or how to get there, that I didn't feel comfortable with the "narrow" help. Lipstick on a pig.

So I went the full consulting route for a few years. But that felt too draining so I dropped it and created a product instead.

But that triggers different accounting/taxes paths that can be problematic. Not everybody is a freelancer.

Thanks for creating Gensim!

I do with PR, and by strongly recommending the sponsored classes (from testdriven.io in the ads on the doc : https://fastapi.tiangolo.com/) for my company, but you're right that I could push harder for official corporate sponsorship.

I share your thoughts on Typer[0]. It's a super cool project, but lacking proper hooking points to interact with the `click`[1] lib underneath [2], I am not sure if it would be the best decision to use Typer when we're rewriting our CLI.

[0]: https://github.com/tiangolo/typer/

[1]: https://click.palletsprojects.com/

[2]: https://github.com/tiangolo/typer/issues/77

Genuinely curious how you happened to choose FastAPI over something more in the middle, like Flask?

I tried a few tools in FastAPI, and it's fantastic for those, but I think I'd still stick with Flask for something more well rounded (not just as an API server).

I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial, it's a mess of wires and plugs that resembles something like Django anyways but all maintained by you or your team. FastAPI seemed like something that's in a solid middle ground between something beefy like Django but something light like Flask and it's much easier to start with since it gives you REST and form/JSON validation out of the box

That said, FastAPI seems to have a lot of issues and the maintainer doesn't seem to be responding to the numerous PRs that are piling up. I'd much rather just stick with Django at this point

Check out Django Ninja: https://django-ninja.rest-framework.com/

It's like a FastAPI inspired Django Rest Framework. In comparison to DRF it feels very lightweight and modern, but it's still Django underneath so you get to keep the ORM, admin, etc.

Speaking of the ORM, once Django's is async Ninja will really be amazing.

If you wanna experiment Django async you can try this module : https://github.com/rednaks/django-async-orm

I must +1 this, Django ninja is outstanding.

> I would say Flask is genuinely really difficult to use. It's very easy to start with but the moment your project becomes non-trivial

Do you have specific examples?

I've built a number of decently large Flask apps over the years (dozens of blueprints, 100+ models, etc.) and it was never an issue. I've used similar code organizational patterns in both small and large apps and it worked great. It was a combination of solo projects and working with small teams.

I share OP's general statement. I've been using Flask and Django on and off for near a decade.

When deciding between Flask and Django, I look at the following requirements:

User accounts

Object Relational Manager

Database Migrations

User registration/social authentication

Admin Site

As a general rule of thumb if my project is going to need 3 or more of these things I just go with Django.

You CAN do all of that with Flask, but you end up wiring together a bunch of third party dependencies just to end up with what Django would have provided you out of the box.

FastAPI doesn't (directly) help with most of these either, so that's really a Flask vs. Django comparison rather than Flask vs. FastAPI.

> solo projects and working with small teams

As I said, any time a Flask app becomes non-trivial, it's a pain. Engineering scaled up from 10 to 30 and immediately it was apparent what a massive pain it all was. We had to implement auth, access control, caching, API documentation, admin panel etc etc all on our own. Flask plugins are very fickle with a lot of them not being maintained anymore that don't fit our use cases. If you need all these things in a customer facing app, you might as well just use Django. Performance suffers a little but the ease of developer onboarding and batteries included in the framework, coupled with a lot of well maintained popular plugins honestly make Django the de facto choice for web app dev that needs to scale. Flask is good for small services being maintained by small teams

> As I said, any time a Flask app becomes non-trivial, it's a pain

Results may vary. Small teams doesn't mean small apps. You can have 150 models, dozens of screens, caching, background jobs, rate limiting, multiple payment providers, multi-tenancy, public APIs and other features you would expect in a decently sized SAAS app and it's fine. The popular Flask extensions for certain behavior are pretty well maintained. There's also a number of Python libraries that can get used in a Flask app that aren't specific to Flask but are very well maintained like SQLAlchemy and Celery.

I wouldn't say Flask is better than Django or Django is better than Flask but I think you can be wildly successful building an app with either one. It comes down to personal preference. Your post made it seem like Flask is some graveyard of dead libraries and you can't build anything successful with it but that's not the case.

At least for my team we went with FastAPI because we have other tools for everything else, and FastAPI is incredibly simple for new members to pick up. We tend to say that we made a “FastAPI application” but in reality FastAPI is only powering the REST interface for interacting with the platform.

We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together.

> We use SQLAlchemy for database interaction, a lot of direct usage of Pydantic, Celery with RabbitMQ/Redis for task processing. FastAPI provides a really lightweight interface to gluing pieces like this together.

Just wondering, why have you not gone with Django directly if you’ve essentially ended up reimplementing your own version of it?

that's how i feel about all these python "micro frameworks".

you start simple, but then you realize you need some kind of db access, some kind of caching, some kind of authentication, maybe some admin interfaces.... aaand you re-implemented django yet again.

Exactly the reason why I don’t care about either FastAPI or Flask. In my experience you’ll always need more than what it comes with out of the box and you’ll end up building your own (crappy) Django.

There wasn’t really an aversion to or direct decision to not use Django, it just kind of naturally evolved. We were experimenting with FastAPI in some mock APIs used for test suites and some different projects and decided to incorporate it into a larger project.

The pulling in of other tools happened naturally over time. Perhaps we reinvented the wheel and Django may have saved some time or effort, but ultimately in the end we gained a very deep knowledge of the system we have and the things that make it work, and how those individual pieces might be usable in other projects/scenarios.

A large driver was honestly just that we had no organizational experience in Django, and so there was no one that even would have looked at it and said “Hey we’re just recreating what Django already does”.

I used to really like Flask but after trying FastAPI I doubt I'd ever go back. I even rewrote the entire backend for our product in FastAPI and unlike some rewrites I've done in the past am 100% happy with this one. Major benefits for us:

- Faster in general than Flask (thanks to starlette / uvicorn)

- asyncio libs in Python are generally beating out others in terms of perf (e.g. asyncpg vs psycopg2). This isn't to start a whole "asyncio is faster" flamewar, not saying that's necessarily true. Just that it seems the people who are building in asyncio are also people who care about perf, which I do as well. The (non-asyncio) Python community has neglected perf for a bit too long imo.

- asynchronous style works much better with things like WebSockets, which we use

- Auto-generating an OpenAPI schema[1] is nice to have.

- Using type hints for things simultaneously encourages mildly "safer" code while also giving better auto-complete suggestions

[1] https://api.supernotes.app/docs/swagger

Experience told me to be very conservative when picking frameworks. For small projects and personal, sure, just pick whatever you want and have fun! But for serious projects, you should stick with old and stable software.

I made the mistake of picking Flask for a really big project when these microframeworks were a fad and everyone was dismissing the big ones like Django and RoR. That was a very costly mistake. I learned the hard way provides way so many things out-of-box that I always took for granted but I had to manually implement in Flask.

Take tests for example, Django automatically makes sure that any DB operation is cleaned by the end of the test. That's sometimes that I never gave a thought until our Flask tests started leaking everywhere. The way that Django handles that problem is very clever and we had to manually do it Flask.

I'm thinking about using Starlette directly. It doesn't look that much more verbose than FastAPI and I already disagreed and bypassed a few FastAPI features. I wonder how much work would it take to hook the Pydantic models with their SchemaGenerator.

Have you considered moving to Starlette a la carte? I use marshmallow for schemas and a few other minimal deps and it's been a breeze.

Reply on news.ycombinator.com