While doing some testing to see how this fastapi with sqlalchemy would hold up, my server seemed to lock up when running 100 concurrent requests. If i ran the requests sequentially it was totally fine.

sqlalchemy.exc.TimeoutError: QueuePool limit of size 5 overflow 10 reached,

Is it possible I've made some error while trying to mimic the structure of the code base? Or is it possible the main can lock up in the middleware with the session implementation of sqlalchemy?

Has anyone tested the performance of this cookie cutter project?

Hello,

I see that they are a bunch of PR and the master branch has not been updated since 2020.

Should someone make an official fork of this ? Or something ? That's a very good project, it would be sad if it became obsolete :/

For a few of my projects, I have used this cookiecutter but removed the frontend part.

Would it be useful to create a cookiecutter that followed this project, but removed the frontend? It would allow the project to focus on purely the API, with the frontend in a separate project.

It would also make it easier to swap out the dashboard part and use something like https://github.com/marmelab/react-admin in a separate project.

This PR facilitates the creation of the basic CRUD operations for new db_models objects.

Motivation: get DRYer

If you don't care for IDE embedded auto-completion, you willl not need to copy/paste app.crud.items.py into app.crud.your_model.py file anymore. One line is sufficient in app.crud.__init__.py (with appropriate import):

your_model = CrudBase(YourModel)

If you care about "intellisense", then you will still have a bit of copy-pasting for the sake of auto-completion, and leverage your favorite IDE. But you will still gain time (and lines of code)

Solution The PR therefore defines a CrudBase class, which instances will provide the get/get_multi/create/udpate/delete/remove operations for a given SQLAlchemy object. I have tried to be as detailed as possible in the documentation of app.crud.base.py

Along with this new tool, I have added a new SubItem model that showcases the usage of CrudBase. I have also modified Item with the same objective. Tests have been added or updated consequently.

because we should be DRY 🚀

Bonus 1: reflect the fastapi documentation by using schemas (when pydantic) and models (when sqlalchemy)

I have updated the tree structure to reflect the latest documentation from fastapi (https://fastapi.tiangolo.com/tutorial/sql-databases/). Hence renaming models to schemas and db_models to models.

Bonus 2: run the test more easily

when runing sh tests.sh from the root directory, arguments are forward to scripts/test.sh and then to .../test-start.sh.

Thats allows the user to pass whatever argument he would pass to pytest, like -x -v -k filter --pdb (pick your favorite)

when sh tests.sh fails and you want to quicky run the test again and again (without deleting the entire testing-projectand generating again (including docker image), then you can user sh test-again.sh that will rsync the testing-project src code with your latest modifications.

Bonus 3: easy casting from schema to model (and vice versa)

Not only we I have tried to be very explicit on which kind object is used, i.e

from app.models import subitem as models_subitem
from app.schemas import subitem as schemas_subitem

subitem = CrudBase(models_subitem.SubItem, schemas_subitem.SubItem)

But the models provide 2 functions to ease the casting_

class CustomBase(object):

    def to_schema(self, schema_cls):
        return schema_cls(**self.__dict__)

    @classmethod
    def from_schema(cls, schema_obj):
        return cls(**jsonable_encoder(schema_obj))

which allows you to easily cast a model instance to any schema you provide, or create the model object from a schema instance.

Those 2 functions are used in the base crud definitions of update and create, and makes sure that all types will be properly cast (in particular non directly JSONable ones like datetime or enums)

Bonus 4: normal user for tests

without the need to create a new one in each and every tests...

That basically comes from PR #20

Describe the bug

The application crashes at start-up, when initializing data if :

1. a relationship is defined ...
2. ... with a model not already imported at the time of execution.

backend_1        | INFO:__main__:Starting call to '__main__.init', this is the 2nd time calling it.
backend_1        | INFO:__main__:Service finished initializing
backend_1        | INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
backend_1        | INFO  [alembic.runtime.migration] Will assume transactional DDL.
backend_1        | INFO  [alembic.runtime.migration] Running upgrade  -> d4867f3a4c0a, First revision
backend_1        | INFO  [alembic.runtime.migration] Running upgrade d4867f3a4c0a -> ea9cad5d9292, Added SubItem models
backend_1        | INFO:__main__:Creating initial data
backend_1        | Traceback (most recent call last):
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/ext/declarative/clsregistry.py", line 294, in __call__
backend_1        |     x = eval(self.arg, globals(), self._dict)
backend_1        |   File "<string>", line 1, in <module>
backend_1        | NameError: name 'SubItem' is not defined
...
backend_1        | sqlalchemy.exc.InvalidRequestError: When initializing mapper mapped class Item->item, expression 'SubItem' failed to locate a name ("name 'SubItem' is not defined"). If this is a class name, consider adding this relationship() to the <class 'app.db_models.item.Item'> class after both dependent classes have been defined.
base-project_backend_1 exited with code 1

To Reproduce

create a new db_models/subitems.py (could be copied from item.py)

It is important that this new model has a relationship to another one, e.g Item

from sqlalchemy import Column, ForeignKey, Integer, String
from sqlalchemy.orm import relationship

from app.db.base_class import Base


class SubItem(Base):
    id = Column(Integer, primary_key=True, index=True)
    title = Column(String, index=True)
    description = Column(String, index=True)
    item_id = Column(Integer, ForeignKey("item.id"))
    item = relationship("Item", back_populates="subitems")

Adapt db_models/item.py with the new relationship

...

class Item(Base):
    ...
    subitems = relationship("SubItem", back_populates="item")

Declare the new SubItem in db/base.py as per the documentation

# Import all the models, so that Base has them before being
# imported by Alembic
from app.db.base_class import Base  # noqa
from app.db_models.user import User  # noqa
from app.db_models.item import Item  # noqa
from app.db_models.subitem import SubItem  # noqa

Re-build and start the application. The full traceback follows

backend_1        | INFO:__main__:Creating initial data
backend_1        | Traceback (most recent call last):
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/ext/declarative/clsregistry.py", line 294, in __call__
backend_1        |     x = eval(self.arg, globals(), self._dict)
backend_1        |   File "<string>", line 1, in <module>
backend_1        | NameError: name 'SubItem' is not defined
backend_1        |
backend_1        | During handling of the above exception, another exception occurred:
backend_1        |
backend_1        | Traceback (most recent call last):
backend_1        |   File "/app/app/initial_data.py", line 21, in <module>
backend_1        |     main()
backend_1        |   File "/app/app/initial_data.py", line 16, in main
backend_1        |     init()
backend_1        |   File "/app/app/initial_data.py", line 11, in init
backend_1        |     init_db(db_session)
backend_1        |   File "/app/app/db/init_db.py", line 12, in init_db
backend_1        |     user = crud.user.get_by_email(db_session, email=config.FIRST_SUPERUSER)
backend_1        |   File "/app/app/crud/user.py", line 16, in get_by_email
backend_1        |     return db_session.query(User).filter(User.email == email).first()
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/scoping.py", line 162, in do
backend_1        |     return getattr(self.registry(), name)(*args, **kwargs)
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/session.py", line 1543, in query
backend_1        |     return self._query_cls(entities, self, **kwargs)
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/query.py", line 168, in __init__
backend_1        |     self._set_entities(entities)
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/query.py", line 200, in _set_entities
backend_1        |     self._set_entity_selectables(self._entities)
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/query.py", line 231, in _set_entity_selectables
backend_1        |     ent.setup_entity(*d[entity])
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/query.py", line 4077, in setup_entity
backend_1        |     self._with_polymorphic = ext_info.with_polymorphic_mappers
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/util/langhelpers.py", line 855, in __get__
backend_1        |     obj.__dict__[self.__name__] = result = self.fget(obj)
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/mapper.py", line 2135, in _with_polymorphic_mappers
backend_1        |     configure_mappers()
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/mapper.py", line 3229, in configure_mappers
backend_1        |     mapper._post_configure_properties()
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/mapper.py", line 1947, in _post_configure_properties
backend_1        |     prop.init()
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/interfaces.py", line 196, in init
backend_1        |     self.do_init()
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/relationships.py", line 1860, in do_init
backend_1        |     self._process_dependent_arguments()
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/relationships.py", line 1922, in _process_dependent_arguments
backend_1        |     self.target = self.entity.persist_selectable
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/util/langhelpers.py", line 855, in __get__
backend_1        |     obj.__dict__[self.__name__] = result = self.fget(obj)
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/orm/relationships.py", line 1827, in entity
backend_1        |     argument = self.argument()
backend_1        |   File "/usr/local/lib/python3.7/site-packages/sqlalchemy/ext/declarative/clsregistry.py", line 306, in __call__
backend_1        |     % (self.prop.parent, self.arg, n.args[0], self.cls)
backend_1        | sqlalchemy.exc.InvalidRequestError: When initializing mapper mapped class Item->item, expression 'SubItem' failed to locate a name ("name 'SubItem' is not defined"). If this is a class name, consider adding this relationship() to the <class 'app.db_models.item.Item'> class after both dependent classes have been defined.
base-project_backend_1 exited with code 1

Expected behavior The solution should have started normally

Additionnal context In (most of) real use-cases, the application would have defined some CRUD operation on the new defined model, and consequently imported it here and there.

Thus making it available at the time when creating initial data.

Nevertheless, the error is so annoying and obscure (when it happens) that it deserves a safeguard (see my PR for a suggestion)

I would assume that one or the other (or even a requirements.txt) would be used for setting up the python dependencies.

I've seen so MANY nice libraries/abstractions already used throughout this cookiecutter, that I'm surpised that there is no strict way of controlling python package dependency versions.

I am a newbie to docker and backend web development so this issue might seem trivial. I am working on deploying the project to ECS Fargate using ecs-cli. However ecs-cli does not support several docker parameters (eg. network). So inorder to deploy it to ECS Fargate, I pushed all the images to AWS Elastic Container Registry and then created a new docker-compose file as follows:

version: '3'
services:
    backend:
        image: 123456789123.dkr.ecr.ap-south-1.amazonaws.com/fast-api/backend
        ports:
            - "8888:8888"
        env_file:
            - .env
        environment:
            - SERVER_NAME=${DOMAIN?Variable not set}
            - SERVER_HOST=https://${DOMAIN?Variable not set}
            # Allow explicit env var override for tests
            - SMTP_HOST=${SMTP_HOST}
        logging:
            driver: awslogs
            options: 
                awslogs-group: tutorialv3
                awslogs-region: ap-south-1
                awslogs-stream-prefix: fastapi-docker
    celeryworker:
        image: 123456789123.dkr.ecr.ap-south-1.amazonaws.com/fast-api/celeryworker
        env_file:
            - .env  
        environment:
            - SERVER_NAME=${DOMAIN?Variable not set}
            - SERVER_HOST=https://${DOMAIN?Variable not set}
            # Allow explicit env var override for tests
            - SMTP_HOST=${SMTP_HOST?Variable not set}
        logging:
            driver: awslogs
            options: 
                awslogs-group: tutorialv3
                awslogs-region: ap-south-1
                awslogs-stream-prefix: fastapi-docker
    
    frontend:
        image: 123456789123.dkr.ecr.ap-south-1.amazonaws.com/fast-api/frontend
        logging:
            driver: awslogs
            options: 
                awslogs-group: tutorialv3
                awslogs-region: ap-south-1
                awslogs-stream-prefix: fastapi-docker

    queue:
        image: 123456789123.dkr.ecr.ap-south-1.amazonaws.com/fast-api/rabbitmq
        logging:
            driver: awslogs
            options: 
                awslogs-group: tutorialv3
                awslogs-region: ap-south-1
                awslogs-stream-prefix: fastapi-docker
            
    pgadmin:
        image: 123456789123.dkr.ecr.ap-south-1.amazonaws.com/fast-api/pgadmin4
        ports:
            - "5050:5050"
        env_file:
            - .env
        logging:
            driver: awslogs
            options: 
                awslogs-group: tutorialv3
                awslogs-region: ap-south-1
                awslogs-stream-prefix: fastapi-docker

    db:
        image: 123456789123.dkr.ecr.ap-south-1.amazonaws.com/fast-api/db
        ports:
            - "5432:5432"
        env_file:
            - .env
        environment:
            - PGDATA=/var/lib/postgresql/data/pgdata
        logging:
            driver: awslogs
            options: 
                awslogs-group: tutorialv3
                awslogs-region: ap-south-1
                awslogs-stream-prefix: fastapi-docker

    flower:
        image: 123456789123.dkr.ecr.ap-south-1.amazonaws.com/fast-api/flower
        ports:
            - "5555:5555"
        env_file:
            - .env
        command:
            - "--broker=amqp://[email protected]:5672//"

Along with this there are 2 other files:

• .env
• ecs-params.yml (Contains task definition for containers with memory & CPU unit format for which is linked in the guide below)

Using the guide I am able to deploy the containers and the cluster reaches a stable state with all containers running. However I am not able to login. Upon checking the logs I came across this for the backend, celeryworker : INFO:__main__:Starting call to '__main__.init', this is the 300th time calling it. ERROR:__main__:(psycopg2.OperationalError) could not translate host name "db" to address: Name or service not known Since the networks parameter is not supported the containers are not ale to communicate with each other and the backend / celeryworker psycopg2 clients are not able to connect to the db.

Since all the containers are deployed in a single cluster so they can communicate over localhost and the networking is possible only through awsvpc, is traefik network mandatory for the project to run on ECS Fargate? Is there a workaround to use 'Networks' parameter in docker compose? Is BACKEND_CORS_ORIGIN preventing the backend container to access the db?

For now its up to 2 days while I'm struggling with postgres docker container and it would've been great if there was any guidelines/ ready compose file to launch them locally and debug that locally.

docker-compose up -d starts each one of the services, but backend service fails with the following:

docker-compose logs backend

Attaching to iaas_backend_1
backend_1        | Checking for script in /app/prestart.sh
backend_1        | There is no script /app/prestart.sh
backend_1        | INFO: Uvicorn running on http://0.0.0.0:80 (Press CTRL+C to quit)
backend_1        | INFO: Started reloader process [1]
backend_1        | ERROR: Error loading ASGI app. Import string ":app" must be in format "<module>:<attribute>".
backend_1        | INFO: Stopping reloader process [1]

I tried to get into the backend's bash to try debugging, but it also fails:

docker-compose exec backend bash

ERROR: No container found for backend_1

Hello I've tried running project locally on Windows server (using cookiecutter), but backend is not starting. docker logs shows: Checking for script in /app/prestart.sh Running script /app/prestart.sh : not foundad.sh: 2: /app/prestart.sh:

It all started when I tried to use a celery.chord to run two tasks in parallel, followed by another task to consume their result. I received an exception similar to the one described here: https://stackoverflow.com/q/45240564/95989.

This issue is not about that. I found this comment https://github.com/tiangolo/full-stack-fastapi-postgresql/issues/293#issuecomment-708665327 , which appeared to resolve a similar issue:

After a deleting all the volumes and images and rebuilding everything again with docker-compose up -d, it works now!

So I decided to try that as well. Unfortunately, upon attempting to rebuild, I encountered this error:

#7 3.111 Installing version: 1.1.6
#7 3.111   - Downloading poetry-1.1.6-linux.tar.gz (72.33MB)
#7 3.111 Traceback (most recent call last):
#7 3.111   File "<stdin>", line 1086, in <module>
#7 3.111   File "<stdin>", line 1082, in main
#7 3.111   File "<stdin>", line 363, in run
#7 3.111   File "<stdin>", line 528, in install
#7 3.111   File "<stdin>", line 548, in make_lib
#7 3.111   File "<stdin>", line 625, in _make_lib
#7 3.111 RuntimeError: Hashes for poetry-1.1.6-linux.tar.gz do not match: a812d3e0e1ff93b6a69fa04bd2fdd81bd502d8788314387fb554b5807c2628f6 != 763eae856b0eca592c0fecb0247d8486b8e72eb35215be2fe993a32e9c1f1c06

Guessing that it had something to do with Docker caching, I tried appending ?foo=bar to the URL to get-poetry.py in backend.dockerfile in order to bust the cache:

 11 RUN curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py?foo=bar | POETRY_HOME=/opt/poetry python && \
...

Unfortunately this did not resolve the issue.

Disconcertingly, I'm not able to find any results for this issue online, i.e. https://www.google.com/search?q=%22get-poetry.py%22+%22runtimeerror%22+%22hashes%22+%22do+not+match%22 returns only four results, none of which are helpful.

The source appears to be https://github.com/python-poetry/poetry/blob/master/get-poetry.py#L624 , and that line has been unchanged for three years.

Any suggestions would be appreciated!

I forked this repo more than a year ago for a major project and, with help from @br3ndonland, consolidated it on his Inboard FastAPI images, added in support for Neo4j (so I could use it for search), and fixed some of the things what were broken.

With several big generational updates on core dependencies, I've spent the last two weeks updating and refactoring. All dependencies upgraded to the latest long-term support & working versions, and I built a tiny blog-type app as the base stack. Still a Cookiecutter template.

Key updates:

• Inboard 0.10.4 -> 0.37.0, including FastAPI 0.88
• SQLAlchemy 1.3 -> 1.4
• Celery 4.4 -> 5.2
• Postgresql 12 -> 14
• Neo4j pinned to 5.2.0
• Nuxt.js 2.5 -> 3.0
• Pinia for state management (replaces Vuex)
• Vee-Validate 3 -> 4
• Tailwind 2.2 -> 3.2
• Authentication refresh token tables and schemas for long-term issuing of a new JWT access token.

I also rebuilt the auth 'n auth to make it a bit more reliable. I haven't rebuilt the tests yet.

Here's instructions for use and I'd appreciate your trying it out and letting me know if it is helpful.

Projects it was used for:

• openLocal.uk - visual data explorer for a quarterly-updated commercial location database for England and Wales.
• Qwyre.com - online ereader and collaborative self-publishing.

Next project for the rebuild: Enqwyre.com - implementation of a "no code" method for schema-to-schema data transformations for interoperability.

I'm beginner use command with this work flow

pip install cookiecutter
cookiecutter https://github.com/tiangolo/full-stack-fastapi-postgresql

# cd to project and run with docker compose up
docker compose up

error-docker-compose

I meet an issue when docker-compose up -d

ImportError: cannot import name 'Celery' from 'celery' (/usr/local/lib/python3.7/site-packages/celery/__init__.py)

I fix it in this way.

(at data-backend/app/pyproject.toml)

...
[tool.poetry.dependencies]
python = "^3.7"
uvicorn = "^0.11.3"
fastapi = "^0.54.1"
python-multipart = "^0.0.5"
email-validator = "^1.0.5"
requests = "^2.23.0"
celery = "^4.4.2"
passlib = {extras = ["bcrypt"], version = "^1.7.2"}
tenacity = "^6.1.0"
pydantic = "^1.4"
emails = "^0.5.15"
raven = "^6.10.0"
gunicorn = "^20.0.4"
jinja2 = "^2.11.2"
psycopg2-binary = "^2.8.5"
alembic = "^1.4.2"
sqlalchemy = "^1.3.16"
pytest = "^5.4.1"
python-jose = {extras = ["cryptography"], version = "^3.1.0"}
importlib-metadata = "<5.0"
...

Reference Issue

https://github.com/celery/celery/issues/7783

This project does not work anymore.

With a clean cookiecutter, if you follow the directions in dockerswarm.rocks you get the error: "Unsupported compose file version 1.0"

This happens when you get to docker stack in /scripts/deploy.sh

I think it's because docker stack and docker compose are not compatible.

If you try to add a version to the top of the file after the compose config, i.e. ...

(echo -e "version: '3.8'\n"; DOMAIN=${DOMAIN?Variable not set} \
TRAEFIK_TAG=${TRAEFIK_TAG?Variable not set} \
STACK_NAME=${STACK_NAME?Variable not set} \
TAG=${TAG?Variable not set} \
docker-compose \
-f docker-compose.yml \
config)

... then you still get this error "(root) additional property **name** is not allowed"