dispatch VS black

They use only sync routes in the project and can’t explain why https://github.com/Netflix/dispatch/issues/1073

By far my favorite production FastAPI app to use as a references of how to use these technologies well is NetFlix Dispatch: https://github.com/Netflix/dispatch

Hey, I have a lot of opinions about this template, but these are just my opinions based on my own experiences being burned by these things so take from them what you will: 1. Your version of poetry is outdated, dependency groups don't work that way anymore and this will fail to install on modern poetry 2. You list pyyaml as a dependency but don't use it anywhere 3. The healthcheck endpoint is interesting, but expensive and a security risk. I like the value this provides, but I don't know if exposing it this way or using it as a healthcheck is a good idea 1. You typically don't want to touch external systems (mongo) as part of a healthcheck as this can cause cascading failure chains that get out of hand quickly 2. You typically don't want to touch the underlying system itself 1. which means you can / should get rid of psutil as a dependency 4. You don't need and shouldn't use pytest-asyncio for a FastAPI project. It comes built-in with its own async test handlers that you should be using 5. Having python-dotenv installed in production has burned me many times. I recommend removing this complete, otherwise just moving it to a dev dep 6. Using the src layout prevents a lot of weird import time problems from cropping up in production, I recommend checking it out 7. The entrypoint for the Docker container should be using 1 worker, as containers really prefer if you have only a single root PID chain and nothing else. Deploying this into k8s would cause a lot of issues 8. Native python logging really isn't great for modern production applications. Structlog or Loguru are great alternatives and much easier to use (which should remove your only dependency on pyyaml) 9. The configuration management may not work the way you want since it is weakly typed. Since FastAPI uses Pydantic, you have access to BaseSettings which is a far superior product for configuration management, especially with environment variables 10. The app and API folder structure is an anti-pattern that doesn't scale past projects the size of a tutorial on how to laern FastAPI. I strongly recommend changing this to move of a vertical slice or folder per feature layout such as is used in https://github.com/Netflix/dispatch/tree/master/src/dispatch 11. FastAPI routes don't need `response_model=` anymore in favor of adding the return type to your function signature such as `async def create_thing() -> Thing:` 12. The uuid_masker function is interesting, but exposing UUIDs in logs usually doesn't pose a security risk and only makes debugging more difficult 13. You have some type lies in your code that could burn you such as https://github.com/alexk1919/fastapi-motor-mongo-template/blob/main/app/db/db.py#L10 . This pattern for the global DB handle has also burned me in the past and I had to go back and refactor out all of them to instead to purely use the FastAPI dependency injection chaining 14. datetime.datetime isn't safe to use as it is in sample_resource_common.py, you need a timezone aware implementation 15. Your test suite is stateful, require a running database, leak a lot of implementation details of the underlying models. This is every anti-pattern in the book for unit testing. And if you are going to do integration tests, then you would be better off with tooling designed for it such as playwright. Again, these are all just my opinions and may alone not be enough to warrant changing anything you have here.

Two random examples I found from 30 seconds of googling: Here’s Netflix using it in their crisis management tool, and here’s Uber using it in their deep learning framework.

netflix dispatch

As someone who uses FastAPI, I find the https://github.com/Netflix/dispatch code to be a great reference.

Besides that paying $21 to $41 per user for this nuts. Set up a VPS with Dispatch (opensourced by Netflix) and save your company some money.

For production ready code examples I use: https://github.com/Netflix/dispatch

$ git commit -m "add pre-commit configuration" [INFO] Initializing environment for https://github.com/psf/black. [INFO] Installing environment for https://github.com/psf/black. [INFO] Once installed this environment will be reused. [INFO] This may take a few minutes... black................................................(no files to check)Skipped [main 6e21eab] add pre-commit configuration 1 file changed, 7 insertions(+)

Black: Known as “The Uncompromising Code Formatter”, Black automatically formats your Python code to conform to the PEP 8 style guide. It takes away the hassle of having to manually adjust your code style.

black @ git+https://github.com/psf/black

In the realm of Python development, there is a multitude of code formatters that adhere to PEP 8 guidelines. Today, we will briefly discuss how to install and utilize black.

Perfect, that worked, thank you!

I thought this could be solved by changing the directory to src/ and then executing that command, but this didn't work.

This also seems to be an issue with the web app, e.g. the repository for the formatter black is only one white dot https://dep-tree-explorer.vercel.app/api?repo=https://github...

Ruff is not only much faster, but it is also very convenient to have an all-in-one solution that replaces multiple other widely used tools: Flake8 (linter), isort (imports sorting), Black (code formatter), autoflake, many Flake8 plugins and more. And it has drop-in parity with these tools, so it is really straightforward to migrate from them to Ruff.

What I am looking for is something like Black for Python, which is opinionated, with reasonable defaults, and auto-fixes most/all issues.

1. LICENSE: This file contains information about the rights and permissions granted to users regarding the use, modification, distribution, and sharing of the software. I already had an MIT License in my project. 2. pyproject.toml: It is a configuration file typically used for specifying build requirements and backend build systems for Python projects. I was already using this file for Black code formatter configuration. 3. README.md: Used as a documentation file for your project, typically includes project overview, installation instructions and optionally, contribution instructions. 4. example_package_YOUR_USERNAME_HERE: One big change I had to face was restructuring my project, essentially packaging all files in this directory. The name of this directory should be what you want to name your package and shoud not conflict with any of the existing packages. Of course, since its a Python Package, it needs to have an __init__.py. 5. tests/: This is where you put all your unit and integration tests, I think its optional as not all projects will have tests. The rest of the project remains as is.

using pylint and black ("the uncompromising code formatter")