Live data from Hacker News

FastAPI 0.100.0 release notes

fastapi.tiangolo.com

41–50 of 115 posts

Re: FastAPI 0.100.0 release notes

#41
post #6

Did not take long at all to see Pydantic version 2 support. Nice!

I still can't stand Pydantic's API and its approach to non-documentation. I respect the tremendous amount of hard work that goes into it, but fundamentally I don't like the developer experience and I don't think I'll ever feel otherwise. I use it because my coworkers like it and I've learned its advanced features because I had to in order to get things done, not because I like it. I would love to see a FastAPI altern…

Could you simplify your point? I was an ardent marshmallow user and when I finally switched to pydantic, it felt like I finally sat down in my life after standing forever. The documentation sounds good enough to me, but importantly the interface pydantic provides to define your json schema is the most elegant interface I’ve seen in any language and miles better than the mess marshmallow provided.

For many of us especially in the SaaS side, speed of these operations is a distant third priority compared to ease of writing and understanding the code, and ensuring reliable less buggy code. The actual compute happens on a cluster with spark or snowflake anyway.

Re: FastAPI 0.100.0 release notes

#42
post #13

I'm really curious about why you would want to use FastAPI over Django Rest Framework. Are there signficant advantages to FastAPI?

They're totally different in terms of the scope of the project they're meant to be used for.

FastAPI is much closer to Flask in that it's trivial to throw up a single file with a couple of routes, and you can use something like SQLite yourself for persistence to disk, or install a couple of libraries for authentication or such (not sure if that's built in by now).

Django, on the other hand, requires a multi-step process to even start a project and creates a dozen of files, most of which are boilerplate, before you can even see a "hello world" route.

But in exchange, you get not just a program which deals with routing and templates and status codes, but much more - a world-class ORM which integrates pretty much transparently with multiple data stores like Postgres or SQLite, an amazing dashboard out of the box which is really handy for sharing with non-techies, a very mature ecosystem, and perhaps most importantly, the "one right way to do things", which makes it a lot more effective for collaboration between a bunch of engineers. It's of course not infallible, has a learning curve, and comes with a good few footguns that get the uninitiated, but the upside is a real upside. Migrations alone might justify it - for all the grief of merge conflicts between migrations right before a code freeze, I can't imagine how much worse it would be to not have them.

So I wouldn't say there's significant advantages to using either - they're different tools for different use cases. If you want to get something up quick that isn't too complex, FastAPI is great for that. If you know you're eventually going to rewrite Django but worse, you may as well use the real thing.

Re: FastAPI 0.100.0 release notes

#43

> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

This is using semver in the exact way it’s intended but with predictably silly outcomes. For several years now I’ve been of the opinion that this particular aspect of semver is … very bad actually.

For personal projects I skip any zero major prefixes. In their place, I use alpha/beta suffixes and version Major/minor/patch from an initial 1.0 alpha. Hasn’t caused any problems for me.

Re: FastAPI 0.100.0 release notes

#44

> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

Because it seems like devs believe that 1.0.0 means "the API is perfect, it won't break ever again".

Somehow they feel like having a version 15.2.3 looks unprofessional (because the API got broken 14 times), but 0.100.0 is perfectly fine.

I just don't get it.

Re: FastAPI 0.100.0 release notes

#45

> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

This is using semver in the exact way it’s intended but with predictably silly outcomes. For several years now I’ve been of the opinion that this particular aspect of semver is … very bad actually. For personal projects I skip any zero major prefixes. In their place, I use alpha/beta suffixes and version Major/minor/patch from an initial 1.0 alpha. Hasn’t caused any problems for me.

And to clarify the approach, the equivalent version would be 1.0.0-alpha.100.0. Clear in its meaning, clear in versioning resolution, ambiguous only in its maturity but that’s what the project is trying to do.

Edit: or probably it’s 1.0.0-beta.100.0. That’s still much clearer

Re: FastAPI 0.100.0 release notes

#46

> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

I prefer straight integer version numbers. It's a tendency of developers to make things complex.

Actually, semver would make sense if people used it correctly.

Changing the major means that it breaks backward compatibility. Changing the minor means that it has new features. Changing the patch means that it had bugfixes.

That's useful for libraries. Of course it's a bit less useful for executables. I just increase the major for executables, but if I need to backport a feature or a fix (to somebody who still uses an older version), then I use the minor/patch.

Re: FastAPI 0.100.0 release notes

#47

> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

FWIW other frameworks (namely, flask) took a similar approach of not moving to 1.0 for a while.

Which sucks, to be honest. Just accept that your major can go up to 23.8.3, and it does not make it less professional than 0.231.0. Actually it's better because it said which releases broke backward compatibility and which ones did not.

Re: FastAPI 0.100.0 release notes

#48
post #8

> FastAPI is already being used in production in many applications and systems. And the test coverage is kept at 100%. But its development is still moving quickly. New features are added frequently, bugs are fixed regularly, and the code is still continuously improving. That's why the current versions are still 0.x.x, this reflects that each version could potentially have breaking changes.[1] What kind of weird reaso…

Semver specifically allows you to use 0.x for this purpose: https://semver.org/#spec-item-4 > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. That said, I'd argue that this is a little silly. Maybe a better design is to use something I am calling "zero-calver": 0.YYYY.MM.DD. Then use semantic versioning once stability is reached.

Just use semver from the moment it is usable by a third party.

Then maybe it goes up to 41.x.x until stability is reached. So what? It's not less professional than keeping 0.x.x forever.

Re: FastAPI 0.100.0 release notes

#49
post #21

The rustification of Python libraries and tooling continues and it has been brilliant. In the past 6 months I have personally switched projected to ruff[0], polars and now - as of this morning[1] - pydantic 2 and FastAPI 0.100 [0] has replaced pylint, flake8, pyupgrade, isort, mccabe and pydocstyle [1] bump-pydantic worked well, after porting settings to pydantic_settings.

At the cost of bigger downloads, not working with other python implementations, and in the case of pydantic, the performance gains aren't that impressive compared to pure python libraries.

Re: FastAPI 0.100.0 release notes

#50
https://litestar.dev is also reaching 2.0 .it is a lot faster than FastAPI yet much better maintained. Has DTO, event and channels, Repository, Service DDD style framework built-in. No promotional commits. I had written the reason of moving away from FastApi here and intro to Litestar 2.0.

https://dev.to/v3ss0n/litestar-20-beta-speed-of-light-power-...

Post reply on HN