tiangolo / full-stack-fastapi-template

Full stack, modern web application template. Using FastAPI, React, SQLModel, PostgreSQL, Docker, GitHub Actions, automatic HTTPS and more.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is this project dead?

BSpendlove opened this issue · comments

Is it dead? not in a valid state/doesn't work when you run the project

As this is linked directly from the FastAPI SQLAlchemy documentation, and labelled 'official', it would be great to see this project get some love.

Any news?

+1

As this is linked directly from the FastAPI SQLAlchemy documentation, and labelled 'official', it would be great to see this project get some love.

+1

commented

Is it dead? not in a valid state/doesn't work when you run the project

Hope not, but pull requests still opent since 2020.
This projects is great, but still having a lot of bugs. May be anybody has created another project as working version of this one.

Is it dead? not in a valid state/doesn't work when you run the project

Hope not, but pull requests still opent since 2020. This projects is great, but still having a lot of bugs. May be anybody has created another project as working version of this one.

I've been searching around for a forked project that has been updated more recently.

I've been searching around for a forked project that has been updated more recently.

May you please share it here in case you find it?

Unfortunately yup, I suppose it's kinda dead and tiangolo is obviously a busy man now.

@mbnoimi
There was the discussion about alternatives/templates based on this one in this issue #422 some few months ago, one of them is mine by the way, but at least it is a start for one that is looking for favorite one.

There are probably much more by now, people are facing this very same issue for a long time.

I've been searching around for a forked project that has been updated more recently.

May you please share it here in case you find it?

Sure- but it's mostly me manually updating it for my personal project use and then Frankensteining together various projects with recent updates. I haven't found one that is a build-ready mirror of this yet.

Would love the location of a working build...

To everyone: It is an open source project.
Everyone can just fix something and then submit a pull request of the fix. This way life gets better for everybody.

I'd like to start using this for an internal project, but the fact it has gone un-loved for nearly 2 years worries me.

If it is not being updated here, is it worth those of us who would like to continue using it - forking it to another project and implementing the pull requests there? Many hands make light work etc?

To everyone: It is an open source project. Everyone can just fix something and then submit a pull request of the fix. This way life gets better for everybody.

I fully agree with this, however, thats what has been happening and no pull requests have been merged :(

For those stumbling upon this GitHub issue hoping to find something along the lines of "what do I need to make this project work in September 2022?" I was able to get this project running on a macOS 12.5.1 machine by doing the following:

  • Install Python
    • brew install python3
    • Add aliases to .zshrc
      • alias python='$(brew --prefix)/opt/python/libexec/bin/python'
      • alias pip='$(brew --prefix)/opt/python/libexec/bin/pip'
  • Install Docker
    • brew install --cask docker
    • Run Docker.app
    • Preferences > Use Docker Compose V2 (since I'm running an Apple Silicon Mac)
  • Create App
    • pip install cookiecutter
    • cookiecutter https://github.com/tiangolo/full-stack-fastapi-postgresql
    • Follow instructions here
  • Fix Install (👈 These are the important things if you've made it to this GitHub issue probably)
  • Run Docker
    • docker-compose up -d
  • Launch App 🎉

Of course the standard your milage may vary notice applies and I'm far from an expert on FastAPI or Python web servers. But this is what worked for me so hopefully this will save someone a couple hours of work/debugging.

commented

For those stumbling upon this GitHub issue hoping to find something along the lines of "what do I need to make this project work in September 2022?" I was able to get this project running on a macOS 12.5.1 machine by doing the following:

  • Install Python

    • brew install python3

    • Add aliases to .zshrc

      • alias python='$(brew --prefix)/opt/python/libexec/bin/python'
      • alias pip='$(brew --prefix)/opt/python/libexec/bin/pip'
  • Install Docker

    • brew install --cask docker
    • Run Docker.app
    • Preferences > Use Docker Compose V2 (since I'm running an Apple Silicon Mac)
  • Create App

    • pip install cookiecutter
    • cookiecutter https://github.com/tiangolo/full-stack-fastapi-postgresql
    • Follow instructions here
  • Fix Install (👈 These are the important things if you've made it to this GitHub issue probably)

  • Run Docker

    • docker-compose up -d
  • Launch App 🎉

Of course the standard your milage may vary notice applies and I'm far from an expert on FastAPI or Python web servers. But this is what worked for me so hopefully this will save someone a couple hours of work/debugging.

thanks for advice!
compose started successfully...but there are log in with first_superuser creds problems

@simonzen I was able to login to http://localhost/login via the username and password provided with pgadmin_default_user/pgadmin_default_user_password during the cookiecutter setup. By default I believe these should match the username and password for first_superuser/first_superuser_password (unless they were changed). When logging into the app itself (via the REST API) you will need to use first_superuser/first_superuser_password though (or another created user).

commented

@simonzen I was able to login to http://localhost/login via the username and password provided with pgadmin_default_user/pgadmin_default_user_password during the cookiecutter setup. By default I believe these should match the username and password for first_superuser/first_superuser_password (unless they were changed). When logging into the app itself (via the REST API) you will need to use first_superuser/first_superuser_password though (or another created user).

Thanks for advice! I tried different login/passwords, but it didn't work. I think problem should be in flower or celery on my side (I added a lot of changes from prs from this project).

UPDATE: it was dumb problem - needed to remove old docker postgres volume

If anyone is looking for an updated version of this project, I've got a working fork here that I intend to maintain. I've updated the frontend and backend dependencies as much as possible, mainly focused on getting this template working without rewriting too much. In my fork I've:

  • Updated to python 3.10
  • Updated backend dependencies to current versions, including FastAPI and sqlalchemy
  • Updated frontend dependencies to current versions where possible
  • Refactored frontend to support Vuetify 2 and Vee-Validate 3, using 165 as a guide (also included the eslint and prettier additions from that PR)
  • Incorporated the steps in tiangolo/uvicorn-gunicorn-docker into backend.dockerfile, so that the update to python 3.10 was possible, and I rather prefer that the start.sh, start-reload.sh, and gunicorn_conf.py files are present in this repo anyways so its clear what the backend container is doing
  • Updated the base image for the build stage in the frontend Dockerfile to node:18, no longer tiangolo/node-frontend which is out of date
  • A handfuls of issue fixes

A couple notes based on the PR activity in this repo:

  • An update to Vue 3 is blocked by the release of Vuetify 3, so that's on the back burner for now. May look at ditching Vuetify for something that does support Vue 3, or just trusting the Vuetify 3 beta. Should also swap vue cli for create-vue/Vite
  • I held off on the update to async sqlalchemy and sqlalchemy 2.0 query style since async is still in beta

Thanks for the work to put that together, @pyb4430! That seems like a promising fork. 🎉

Yeah, proper cracking job @pyb4430 !

One last thing I had to do to get your project running @pyb4430 , the backend keep crashing on me due to an error on this project, specifically:

backend_1       |   File "/app/app/models/item.py", line 17, in Item
backend_1       |     owner: User = relationship("User", back_populates="items")
backend_1       | NameError: name 'User' is not defined

within both the item.py and user.py models on the backend, noqa: F401 is attempting to provide us with autocompletion but breaks the whole backend, I had to change the following to get the backend running properly:

backend/app/app/models/item.py, line 17

owner: User = relationship("User", back_populates="items")
to
owner: relationship("User", back_populates="items")

and

backend/app/app/models/user.py, line 179

items: List[Item] = relationship("Item", back_populates="owner")
to
items = relationship("Item", back_populates="owner")

I can log in now and everything seems to work so far after changing those 2 files

Edit: Ignore this as I'm so stupid

Ah yep, just pushed a fix for that that'll keep mypy happy

For those stumbling upon this GitHub issue hoping to find something along the lines of "what do I need to make this project work in September 2022?" I was able to get this project running on a macOS 12.5.1 machine by doing the following:

  • Install Python

    • brew install python3

    • Add aliases to .zshrc

      • alias python='$(brew --prefix)/opt/python/libexec/bin/python'
      • alias pip='$(brew --prefix)/opt/python/libexec/bin/pip'
  • Install Docker

    • brew install --cask docker
    • Run Docker.app
    • Preferences > Use Docker Compose V2 (since I'm running an Apple Silicon Mac)
  • Create App

    • pip install cookiecutter
    • cookiecutter https://github.com/tiangolo/full-stack-fastapi-postgresql
    • Follow instructions here
  • Fix Install (👈 These are the important things if you've made it to this GitHub issue probably)

  • Run Docker

    • docker-compose up -d
  • Launch App 🎉

Of course the standard your milage may vary notice applies and I'm far from an expert on FastAPI or Python web servers. But this is what worked for me so hopefully this will save someone a couple hours of work/debugging.

Legend! Thank you

Ah yep, just pushed a fix for that that'll keep mypy happy

thanks :)

Hello all! Nope, the project is not dead, in fact, I've been building stuff for it.

I created SQLModel precisely to use it in this project, to simplify a lot of the code here.

I also want to migrate Celery to ARQ, Vue to React with TypeScript and hooks, and the GitLab CI to GitHub Actions, and Docker Swarm to Kubernetes... Lots to do.

But first, I need to finish and polish things in SQLModel, that's what's kept me from doing more stuff here, and it's what will have the biggest impact too.

Hello all! Nope, the project is not dead, in fact, I've been building stuff for it.

I created SQLModel precisely to use it in this project, to simplify a lot of the code here.

I also want to migrate Celery to ARQ, Vue to React with TypeScript and hooks, and the GitLab CI to GitHub Actions, and Docker Swarm to Kubernetes... Lots to do.

But first, I need to finish and polish things in SQLModel, that's what's kept me from doing more stuff here, and it's what will have the biggest impact too.

Omg - Thats sounds sooooo great. Thank you soooo much!

commented

Hello all! Nope, the project is not dead, in fact, I've been building stuff for it.

I created SQLModel precisely to use it in this project, to simplify a lot of the code here.

I also want to migrate Celery to ARQ, Vue to React with TypeScript and hooks, and the GitLab CI to GitHub Actions, and Docker Swarm to Kubernetes... Lots to do.

But first, I need to finish and polish things in SQLModel, that's what's kept me from doing more stuff here, and it's what will have the biggest impact too.

Amazing! Thanks for all the open source you have done!

commented

Hello all! Nope, the project is not dead, in fact, I've been building stuff for it.

I created SQLModel precisely to use it in this project, to simplify a lot of the code here.

I also want to migrate Celery to ARQ, Vue to React with TypeScript and hooks, and the GitLab CI to GitHub Actions, and Docker Swarm to Kubernetes... Lots to do.

But first, I need to finish and polish things in SQLModel, that's what's kept me from doing more stuff here, and it's what will have the biggest impact too.

Sounds really awesome! If it could also have next-auth for authentication and file storage (local storage, s3, etc) support, then it will become a full functional BaaS solution (and a good alternative for Supabase).

Hello all! Nope, the project is not dead, in fact, I've been building stuff for it.

I created SQLModel precisely to use it in this project, to simplify a lot of the code here.

I also want to migrate Celery to ARQ, Vue to React with TypeScript and hooks, and the GitLab CI to GitHub Actions, and Docker Swarm to Kubernetes... Lots to do.

But first, I need to finish and polish things in SQLModel, that's what's kept me from doing more stuff here, and it's what will have the biggest impact too.

I'm just pinging to see how far it has gone until now

Keep up the good work 👍

Hello all! Nope, the project is not dead, in fact, I've been building stuff for it.

I created SQLModel precisely to use it in this project, to simplify a lot of the code here.

I also want to migrate Celery to ARQ, Vue to React with TypeScript and hooks, and the GitLab CI to GitHub Actions, and Docker Swarm to Kubernetes... Lots to do.

But first, I need to finish and polish things in SQLModel, that's what's kept me from doing more stuff here, and it's what will have the biggest impact too.

Cool!

GitlabCi to GH actions and docker sw to k8s its kinda obvious of me, but Celery to arq, and Vue to react + Typescript its not, what are the reasons behind?
Dramatiq seems to be srong option atm isnt it?
ty

commented

Any progress?

@tiangolo There are too many issues and pull requests, which some may bring bug fixes already on the issue itself. I can help pointing those out, but it would require also some effort to the community to make some prior considerations, like organization, or even permission to join the collaborator staff.

PS.: I was trying to perform something like yours here.