FastAPI starter setup question

[asynckeel-max]

Hi! I saw your FastAPI template repository and really liked the clean structure.

I'm currently researching different FastAPI project setups because I'm building a small SaaS backend starter called AsyncKeel.

When you first created this template, what problem were you trying to solve for yourself or other developers?

[seapagan]

Hi @asynckeel-max, sorry for the delay in resonding.

I originally wrote this template when I was learning FastAPI, as there were actually very very few examples I could learn from, and even less tutorials outside the official documentation. My idea in open-sourcing this was to help other users in the same situation get a leg up by providing a working base they can build on.

I wanted a clear obvious setup that could just be cloned and used without needing extensive setup, and preferably would just work without needing troubleshooting. True, this project has grown considerably past that initial vision!

Regarding the structure, I tend to be very strict with the layout of all my projects, using individual modules for clarity and obvious grouping. Likewise, the 'manager' pattern seemed to be a perfect fit - keep your routes lean with all the logic in specific managers (I am an old Ruby coder and used Ruby on Rails since the first version), each manager and its methods doing one thing well.

This is especially important for open-source projects when you want contributions - if users can understand your code easily then they can contribute easily! Hence, the early decision to have a CONTRIBUTING.md file to make it completely clear how to do so, and a clear website

I started with standard sync database access using encode/database but later migrated to sqlalchemy for async. This also at the time was woefully difficult to get any information on so I researched and created my own examples in the fastapi_async_sqlalchemy2_example repo.

Another important design decision was Dont reinvent the wheel - there are many amazing helper packages out there that are extensively used and tested and simple to drop in when you need specific functionality. The only exception I made to this was rolling my own Auth module, as I feel that since this is such a critical part of the API that you should really understand it and the security implications. However, there are also a good few battle-tested third-party libraries that can do this too.

Saying the above, you will note that even though I use third-party caching and rate-limiting packages, I actually have my own wrappers around them instead of using their API's directly - this keeps the base functionality as the libraries own, tested and validated code but allows me to customize how my users interact with it - not required but it does mean that if their API changes in the future that users of this template may not need to (once the template is updated to the new API of course!). Users are of course perfectly able to ignore my wrapper and use the original package API directly.

I still have a lot to add to this template, though other work has intruded recently, the TODO is quite long!

Sorry for the wall of text, but hope that helps a little 😁 Good luck with AsyncKeel!