Enable backend API port access on Dev server for frontend testing #224

placek · 2024-02-19T13:27:57Z

As a frontend developer,

I want to access the backend API on the dev server,

So that I can test the API without setting up the entire application stack locally.

Summary:

To facilitate API testing without the need for local setup of the resource-greedy full stack, saving on RAM and disk capacity we need to implement an exception for accessing the backend API on the dev server via a designated port.

The problem is that developers cannot utilize the dev server's backend API because of CORS policy preventing localhost.

Acceptance Criteria:

The docker-compose configuration must be modified to include an exception that opens a specific port for backend API access exclusively in the dev environment only.
This configuration should not affect other services or environments (staging, test, beta) to ensure security and integrity.
Frontend developers should be able to connect to the backend API using the specified port without initiating other services in the stack.
Documentation must be updated to include instructions on how to access the backend API using the new configuration.
The solution must be tested to confirm that it does not introduce any new security vulnerabilities.

placek · 2024-02-20T10:33:13Z

To create an exception in our deployment configuration that solves this issue we need to spawn many docker compose files with dedicated setup for each environment.

This introduces an issue with redundancy and opens possibility of mistakes in the configuration when the change is supposed to be a global (inter jenvironmental).

First stage of that solution will be to introduce the change in the stack without a corresponding configuration. At the second stage I plan to use template to generate docker compose file with given params.

placek · 2024-02-21T08:42:53Z

The frontend developers need an allowed origin in CORS setup for backend, not a port.

This is a pre-step before implementing an exception that will be applied only to dev environment. This update facilitates easier development and testing by allowing local frontend applications to communicate with the backend without CORS restrictions. For development purposes, Cross-Origin Resource Sharing (CORS) settings have been updated to include `localhost` in the list of allowed origins. In next step the configuration for different environments will be stated explicite in target docjer-compose file.

In preparation for a more modular and environment-specific docker-compose setup, the existing docker-compose configuration has been renamed to `docker-compose.node+dbsync.yml`. This change marks a pre-step towards introducing separate docker-compose files for each environment, aiming to streamline development processes and improve clarity.

As part of streamlining the development environment and preparing for a more granular docker-compose file strategy, the unused `docker-compose.yml` file within the `scripts/govtool` directory has been removed. This removal is in alignment with efforts to declutter the project's configuration files and ensure that only relevant and environment-specific docker-compose files are maintained. This change aids in reducing confusion and simplifying the setup process for developers, ensuring a focus on necessary services and configurations for development and testing.

…ction Updated the Makefile within the `scripts/govtool` directory to dynamically select the docker-compose file based on the `cardano_network` variable. This change introduces a new variable `docker_compose_file` that constructs the docker-compose filename from the given network environment (e.g., `docker-compose.mainnet.yml` or `docker-compose.testnet.yml`). This adjustment allows for more flexible deployment processes by automatically selecting the appropriate docker-compose configuration for different Cardano network environments during deployment, toggling maintenance mode, and executing other docker-compose commands. The intent is to streamline deployment workflows and enhance maintainability by reducing hardcoded references to specific docker-compose files.

As part of improving the deployment process and environment management, separate docker-compose files have been created for each environment: development (dev), testing (test), staging, and beta. This change allows for tailored configurations per environment, enhancing the ability to manage unique settings, dependencies, and services required by each. The `docker-compose.sanchonet.yml` file has been renamed to `docker-compose.beta.yml` to align with this new structure. Additionally, the Makefile has been updated to dynamically select the docker-compose file based on the `env` variable, further streamlining deployment operations. This modular approach not only simplifies environment-specific deployments but also improves the overall manageability and scalability of the infrastructure.

Updated the Docker Compose files for beta, dev, staging, and test environments to hardcode the domain names for each respective environment. This change ensures that the services within each environment are accessible through predefined, environment-specific URLs, enhancing clarity and reducing the reliance on dynamically generated domain names based on environment variables. Specifically, the changes include hardcoding the Grafana URL, status-service, backend API, and frontend service URLs to their respective environment-specific domains. This change also addresses the original issue stated in #224 - an exception on dev sever to apply specific CORS policy only there. This adjustment facilitates more predictable deployment and access patterns for services across different deployment stages.

This is a pre-step before implementing an exception that will be applied only to dev environment. This update facilitates easier development and testing by allowing local frontend applications to communicate with the backend without CORS restrictions. For development purposes, Cross-Origin Resource Sharing (CORS) settings have been updated to include `localhost` in the list of allowed origins. In next step the configuration for different environments will be stated explicite in target docjer-compose file.

In preparation for a more modular and environment-specific docker-compose setup, the existing docker-compose configuration has been renamed to `docker-compose.node+dbsync.yml`. This change marks a pre-step towards introducing separate docker-compose files for each environment, aiming to streamline development processes and improve clarity.

As part of streamlining the development environment and preparing for a more granular docker-compose file strategy, the unused `docker-compose.yml` file within the `scripts/govtool` directory has been removed. This removal is in alignment with efforts to declutter the project's configuration files and ensure that only relevant and environment-specific docker-compose files are maintained. This change aids in reducing confusion and simplifying the setup process for developers, ensuring a focus on necessary services and configurations for development and testing.

…ction Updated the Makefile within the `scripts/govtool` directory to dynamically select the docker-compose file based on the `cardano_network` variable. This change introduces a new variable `docker_compose_file` that constructs the docker-compose filename from the given network environment (e.g., `docker-compose.mainnet.yml` or `docker-compose.testnet.yml`). This adjustment allows for more flexible deployment processes by automatically selecting the appropriate docker-compose configuration for different Cardano network environments during deployment, toggling maintenance mode, and executing other docker-compose commands. The intent is to streamline deployment workflows and enhance maintainability by reducing hardcoded references to specific docker-compose files.

As part of improving the deployment process and environment management, separate docker-compose files have been created for each environment: development (dev), testing (test), staging, and beta. This change allows for tailored configurations per environment, enhancing the ability to manage unique settings, dependencies, and services required by each. The `docker-compose.sanchonet.yml` file has been renamed to `docker-compose.beta.yml` to align with this new structure. Additionally, the Makefile has been updated to dynamically select the docker-compose file based on the `env` variable, further streamlining deployment operations. This modular approach not only simplifies environment-specific deployments but also improves the overall manageability and scalability of the infrastructure.

Updated the Docker Compose files for beta, dev, staging, and test environments to hardcode the domain names for each respective environment. This change ensures that the services within each environment are accessible through predefined, environment-specific URLs, enhancing clarity and reducing the reliance on dynamically generated domain names based on environment variables. Specifically, the changes include hardcoding the Grafana URL, status-service, backend API, and frontend service URLs to their respective environment-specific domains. This change also addresses the original issue stated in #224 - an exception on dev sever to apply specific CORS policy only there. This adjustment facilitates more predictable deployment and access patterns for services across different deployment stages.

pmbinapps · 2024-02-21T14:58:39Z

Not merged to test and deployed yet.