You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 20, 2023. It is now read-only.
What should we add or change to make your life better?
Ability to define and run multiple "apps". Currently, the paradigm is a single "app" that can contain any number of services. An "app" being a collection of services that fall under the same namespace.
A new or changed schema and subsequent ability to run and deploy (or at least configure), selectively, any number of "apps" would allow for a larger platform definition and be more flexible for the local development story. Changes to the dashboard would be needed for a hierarchy (e.g., two levels for app and then it's services).
Ideally, I believe, you would be able to define a service once that could be used in multiple "apps".
Why is this important to you?
Our desired unit of deployment is an "app", we'll call a "microservice". This is a collection of component services. There may be other microservices which have their own version of a particular component service. Say, for example, there is an API layer which is it's own unit of deployment and namespace which calls into a "microservice". We want to be able to run this API and microservice at the same time. Additionally, a schema with this higher order ability should also allow for less duplicated configuration.
This is something we are looking to do and curious really if this would be helpful for others or even if others have solved this problem in a different way.
The text was updated successfully, but these errors were encountered:
You could have a tag for all the services that belong to your app for examaple.
Thanks for the suggestion, that's exactly what we are planning to do, use tags. We've created our own tool which will generate a single tye yaml from our own specification file with everything. Subsequently will utilize tags for the developer loop to run just what is wanted.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What should we add or change to make your life better?
Ability to define and run multiple "apps". Currently, the paradigm is a single "app" that can contain any number of services. An "app" being a collection of services that fall under the same namespace.
A new or changed schema and subsequent ability to run and deploy (or at least configure), selectively, any number of "apps" would allow for a larger platform definition and be more flexible for the local development story. Changes to the dashboard would be needed for a hierarchy (e.g., two levels for app and then it's services).
Ideally, I believe, you would be able to define a service once that could be used in multiple "apps".
Why is this important to you?
Our desired unit of deployment is an "app", we'll call a "microservice". This is a collection of component services. There may be other microservices which have their own version of a particular component service. Say, for example, there is an API layer which is it's own unit of deployment and namespace which calls into a "microservice". We want to be able to run this API and microservice at the same time. Additionally, a schema with this higher order ability should also allow for less duplicated configuration.
This is something we are looking to do and curious really if this would be helpful for others or even if others have solved this problem in a different way.
The text was updated successfully, but these errors were encountered: