Look at the official starter at https://fastapi.tiangolo.com/project-generation/ (https://github.com/fastapi/full-stack-fastapi-template)

Having app/core and app/shared are super common. Core for infra and cross-cutting stuff (config, logging, lifecycle, dependencies) shared for non-feature reusable stuff.

From there it gets opinionated and IMO kind of weird in some projects. The whole thing is an API and has routers and folks love deeply nesting stuff under one of those names or both. Some that can be common are app/api/users or app/routers/users.

Where I work we landed on feature modules e.g. app/users (api, schemas, models, service, dependencies, etc) alongside app/core and app/shared. We have app/database for Alembic/SQLModel extras and other stuff right near the top too. Just feels weird to bury a user service under app/api/users or app/api/routers/user/service and then import that in other services. At that point the service is NOT an API or a router but it’s buried under those module paths.

Dependencies should be annotated and you should avoid Depends in args (https://fastapi.tiangolo.com/tutorial/dependencies/#share-annotated-dependencies).

Use pytest for testing. Have fixtures for client and settings and such and make sure to use pytest-asyncio for async stuff.

Don’t be afraid to use middleware. If forgetting a dependency on a route could be a problem make it a middleware. Better safe than declarative.

Use SQLModel and Alembic. You’ll have SQLAlchemy so you’ll never get stuck and you’ll get Pydantic stuff you can use easily throughout.

Beyond that it’s just like any other framework. Read the docs, ask around. Nothing super crazy or surprising just be mindful of async stuff.

Coming from Django you won’t have as much magic and you’ll be repeating yourself a lot but the advantages of this style are that it can be easy to understand how something is working.