We are the same team behind FastAPI, building FastAPI Cloud.
We're looking for a Design Engineer who can also code frontend (or is learning to), to help us (mainly) make the dashboard the best developer experience possible for deploying FastAPI apps.
We prefer candidates with strong design skills over only strong frontend skills.
I’m a product designer with a Master’s in HCI and 4+ years of experience designing dashboards and dev-facing tools in fintech and healthcare. I also have a background in computer science and have worked with HTML, CSS3, and PHP, which helps me collaborate closely with engineers and build feasible, scalable interfaces.
I’d love to chat more about the role and share relevant projects.
Astral's tools (Ruff, uv) are awesome, I'm a big fan. I'm using them every time I can and recommending them everywhere. I use them for my open source projects (FastAPI, Typer, SQLModel, etc.) and also for private things, small and big, even small scripts, everything. Also, they have great docs, and I'm kinda picky with docs. I'm looking forward to whatever they build next, I'm pretty sure I'll like it. By now, it's not just by chance that they built one great thing, it's a trend, they build great stuff.
I don't have chocolates for you all, but you might like this.
Migrating from Flask to FastAPI, Part 2.
This is the juicy part, all the main code changes from Flask to FastAPI, including some auth and dependencies.
From Forethought with love.
For the advanced stuff, including the g pseudo-global variable, more techniques migrating from Flask to FastAPI, and mixing async and await with blocking code, wait for the next part.
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.
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.
We are the same team behind FastAPI, building FastAPI Cloud.
We're looking for a Design Engineer who can also code frontend (or is learning to), to help us (mainly) make the dashboard the best developer experience possible for deploying FastAPI apps.
We prefer candidates with strong design skills over only strong frontend skills.
Please include your portfolio link or PDF and CV.
Email jobs@fastapilabs.com