This cookiecutter but without the frontend #64
Comments
|
Hi @nyejon , I was also thinking on using a React frontend instead of a vue.js one I think that having an embedded frontend is great, and helps fastening the project creation process. What about enriching the project with the react frontend ? A bit like we have That would be a PR I would like to help with 😄 Just an idea though... 🎈 |
|
Hi @ebreton That would be an interesting idea. Have you used the react-admin before? My gripe with the frontend in the same project is there are many cases where one would prefer to use a different frontend depending on the team/project. That way me deciding to use fastapi doesn't impact other members that might work on the frontend part. Would having a separate cookiecutter project. for each of the different frontends that one wanted to support, be an option? |
I would think that the frontend repos would just be drowned in the github oceans among many other react-admin / vue-js frontend framework. + It would probably be less straightforward to integrate with the backend if they are in 2 different repos, especially if you take into account time... and its divergence effect. But I think @tiangolo would be the one to know here 😄
I agree, but those people could follow the same way you did: just ignoring the frontend and replacing it with theirs, couldn't they ?
not this one, but my company is using react when it comes to frontend. That's why I am curious |
|
Maybe it could be a parameter in the cookiecutter to decide whether a frontend is wanted or not? I've never configured a cookiecutter project, but it sounds like something that should be doable. I also had to remove the frontend from the project and I think might be a rather common thing people do. I do like having a front-end in the project as a demo of how it can be done though... And personally, I use vue.js rather than react, but not in this project :) |
|
@nyejon Could you summarize what's necessary to remove the frontend part? I really like this cookiecutter but would like to see a more modular approach. Besides removing the front end, I'd like the option of not using postgresql in a container but rather use an dedicated external database like a Digital Ocean managed database cluster. |
|
Hi @sliptonic I have ended up making quite a few significant changes to the template, which I would like to simplify and release in a separate cookiecutter. I am also more in favor of a modular approach. The steps I did were to delete the frontend folder, move the backend stuff up one level, simplify the dockerfiles/compose, simplify the testing to use the TestClient and integrate some of the changes still open as a PR in this repo. What other functionality would you like to have? For your database, you could update the postgres connection settings and delete the bits from the various compose files. |
Would also love to have the option for React front-end. I still think thou that Vue is better than nothing, because it at least gives you an example on how to do it, and one could follow for React/Angular. |
|
Hi @nyejon ,
I'm also looking into removing the frontend entirely and any help would be appreciated. |
|
@Amiram1 Not yet.. Would this still be useful to you? |
|
I would second Amiram1, and would also like to remove the frontend entirely. |
|
@nyejon , certainly. Seems logical to have an option to decouple the frontend altogether . |
|
Following.... |
|
Thanks for the discussion here everyone! About the frontend wars 😂 ⚔️ ... I actually have a (subjective) opinion. After having worked for at least a year with AngularJS, Angular, and Vue.js, my favorite is React, even though I used to hate it and hate JSX when I first saw that. But now React has TypeScript support, that combined with hooks, and the (strangely) great editor support for JSX, makes it have the best autocompletion support I've had while reducing code duplication as much as possible. So, I would actually like to replace the current Vue.js frontend with React. Another project idea I've had is to integrate react-admin with FastAPI, or to create a similar alternative that can work by default, based on OpenAPI, like Swagger UI does, but for admin. Now, about removing it, the maintenance burden of these project generators is kinda high 😰 , so I would prefer not to create a new project just removing the frontend, as that would mean that there would be another project to keep in sync with this, adding there all the features added here, etc. But maybe we could add the frontend conditionally. Nevertheless, that would probably mean using conditional templates in a directory name, and that is not supported in Windows (there's some info about that in issues in the Cookiecutter repo). That would break generating this project in Windows, so it wouldn't be acceptable I like about the current structure that it's relatively easy to just remove a part after generating the project. Like removing the frontend is just a matter of removing the On the other side, if the current problem is that there are too many Docker Compose files to remove the frontend section from, I do think there are currently many Docker Compose files 😅 . I tried to eliminate all the possible config duplication by separating them into multiple small files, that way updating a configuration would require updating it in one single place, not in multiple files that had to be kept in sync. But now I think that having so many Docker Compose files adds mental complexity and makes it look more complex than it actually is, and there's no way to look at a single file and have a general idea of the whole stack. Maybe it would be better to have fewer files even while they duplicate a lot of the configs for each environment, and having to keep them in sync by hand, but that would probably still be a better option 🤔 If that's the case, then merging the configs to just some files (let's say just 3 Docker Compose files) would mean that removing the frontend would be a lot easier. What are your thoughts on that? |
|
About simplifying the Docker Compose files, I created this issue to keep track of that: #143 Your feedback there would be much appreciated. |
❤️ |
|
I just finished the refactor with the simplification fo the Docker Compose files, env files and setup. And taking this issue into account, I added docs for removing the frontend: https://github.com/tiangolo/full-stack-fastapi-postgresql/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/README.md#removing-the-frontend For completeness I copy those docs here:
Done, you have a frontend-less (api-only) app. 🔥 🚀 About frontend, I plan on moving to React with TypeScript and hooks, as that has been providing me the best development experience so far (completion, type checks, etc). I have also been wanting to check react-admin, but haven't had the time yet. But with the refactor and the new docs, I think that should solve this use case of easily creating an API-only project, right? |
|
Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues. |
@ebreton I made a React + react-admin fullstack template with FastAPI for my own projects, based strongly off of this Vue one. Check it out: https://github.com/Buuntu/fastapi-react. There are still a few things I'd like to add (such as emails on user creation and being able to reset passwords). Let me know if you'd like to help 😄 |
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.
The text was updated successfully, but these errors were encountered: