Skip to content

Discussion: Handling multiple environment API entities #148

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
stijnbrouwers opened this issue Feb 15, 2025 · 0 comments
Open

Discussion: Handling multiple environment API entities #148

stijnbrouwers opened this issue Feb 15, 2025 · 0 comments

Comments

@stijnbrouwers
Copy link
Contributor

I am currently using Harmonix to manage multiple resources. One of the AWS resources we are managing are API gateways, which are deployed across multiple environments. I am facing a challenge in managing enitities of kind "API" that differ for each environment and would appreciate your insights on the best approach to handle this scenario.

Current Challenges

We have API gateways deployed to multiple environments (e.g., DEV, STAGING, PROD).
The API entities associated with these gateways can vary between environments.
We need an efficient way to manage and reference these API resources without causing confusion or complexity.

Possible Solutions

Single API Version for DEV

Create only a single API version for the DEV environment, which is the most recent and relevant.

Pros: Simplifies management by focusing on a single version.
Cons: May not accurately represent the resources available in other environments.

API Version per Environment

Create separate API versions for each environment.

Pros: Provides accurate representation of resources for each environment.
Cons: Could lead to an explosion of APIs, making it difficult to reference the correct API from components deployed to specific environments.

Modify api-docs Plugin

Modify the api-docs plugin to:

  • Expose an AWS Environment selector at the top of the screen.
  • Reuse the process for exposing environment-specific information for components (using the appData property), where one of these properties is a link to the environment definition (e.g., dev-api.json).
  • Make changes to the ApiDefinitionCard/ApiDefinitionDialog to check if there is a appData definition to be used, based on the value of the environment selector
  • Have a default (empty dummy or DEV version) definition, since it is a required property in the schema for the entity of kind "API"

Pros: Provides a dynamic and flexible way to manage environment-specific API resources that is in line with the current process.
Cons: May require additional development effort to implement.

Questions:

What is your recommendation for managing API resources across multiple environments in Harmonix?
Are there any best practices or existing solutions within Harmonix that address this issue?
Would adapting the api-docs plugin as described be a viable solution, or are there better alternatives?
Thank you for your time and consideration. I look forward to your feedback and suggestions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant