Conversation
Introduced `useState` to manage button disabled states for both forms, preventing multiple submissions. Updated the corresponding buttons to respect the newly added states, enhancing user experience and ensuring better form handling.
Switched to dynamic frontend domain in the nginx config for flexibility. Added a new `docker-compose.frontend.dev.yml` file for improved local development. Updated documentation to reflect changes, including steps for running services and frontend separately.
|
@isik-kaplan here is the new PR for the nginx stuff. |
Introduce modular Docker Compose files for frontend, backend, and other services, including base, server, and database configurations, to enhance deployment flexibility. Updates to the Nginx template now support environment-specific backend domain variables for improved configurability. Documentation and environment examples were updated accordingly.
Reorganized backend Docker Compose configurations and adjusted file paths for better modularity and maintainability. Updated documentation to reflect the changes in the Docker Compose file structure and commands.
|
@isik-kaplan i sliced all of the services and made a "combined" docker-compose file for backend only and frontend only. Is this how you wanted it? |
Sorry for misleading, I meant a single docker-compose-development.yml that is ready for local development that has all the necessary services in it. I figured it would include the existing docker-compose.yml as is and then add volumes for backend and frontend so we only have 2 docker compose files to worry about. But I think you want 2 separate files for backend and front-end (do I understand that right?) Is there a reason for separating them and not using a single development compose file? |
|
I am not the best docker-compose specialist and i think it is a little bit more intuitive to have it seperate. Instead of having one LONG command selecting each service you want or not, just do docker-compose -f frontend.... or backend..... up --build
|
|
What is the use case you are trying to solve for exactly? After having your .env file in the project root are you trying to avoid I really don't like putting preferences into the codebase so I'm trying to understand if this is something you can maybe just |
|
Yeah i guess we should differ between dev and prod docker folders. I will move and rename it. Of course i can just have them outside the project. But in the terms of new contributor friendlyness its a bit uncomfortable |
|
Okay then, can you just add all of these under a development folder like docker-compose-dev and keep the prod version as is? So everything related to development is stashed under its own folder while prod still lives in the root of the project so I don't have to change how I deploy things until necessary |
Moved docker-compose files to a `docker-compose-dev` directory and updated file paths accordingly. Adjusted documentation to reflect these changes, ensuring consistency and clarity for local development workflows.
…nt' into feature/local-frontend-development
|
Adjusted it. |
Updated relative paths in Docker Compose files for consistency and simplified management. Removed redundant `dockerfile` directives where defaults suffice and adjusted documentation for clarity in local development.
Reorganized Docker Compose files to utilize the `extends` directive, simplifying service definitions and improving maintainability. Updated development instructions in the documentation to reflect these changes. Adjusted file paths and service dependencies for consistency and correctness.
|
I'm happy with this if you are, I'm seeing some extra commits after your comment so I don't know if this is ready to merge on your end but I can merge it whenever you say it is ready |
|
Yeah i am sorry had some weird docker build cache issues but i fixed them those are working now. |
2 participants
No description provided.