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
While I understand that this project has been created mainly to be able to handle nodejs resource generation, I feel like this strays away from the original goal of dekorate. Maybe I'm wrong but I thought I should at least write down my point of view. Feel free to close this issue if irrelevant.
From my point of view, dekorate is best when it is transparent i.e. as part of a build like what happens on the Java side of things. It's a thin annotation/properties layer added to my project that automatically creates k8s resources for me. If I need to use an external tool to generate these resources, then the dekorate value proposition decreases for me.
If the goal is to offer an interactive mode to incrementally generate / populate k8s resources, then it steps into the territory of other tools (odo or kn most notably). I would assume that an organization would want to limit the number of such tools needed to deploy the project to the cluster and dekorate CLI could be seen as competing with these tools, especially when support for what the dekorate CLI already exists in these tools or is on their roadmap.
Finally, if I was a nodejs developer, I would ideally want to deal with nodejs tools exclusively and would like dekorate to integrate with my code as it does on the java side, i.e. generating the k8s resources during npm install for example. If that's not possible, I'm considerably less likely to use dekorate.
The text was updated successfully, but these errors were encountered:
While I understand that this project has been created mainly to be able to handle nodejs resource generation, I feel like this strays away from the original goal of dekorate. Maybe I'm wrong but I thought I should at least write down my point of view. Feel free to close this issue if irrelevant.
From my point of view, dekorate is best when it is transparent i.e. as part of a build like what happens on the Java side of things. It's a thin annotation/properties layer added to my project that automatically creates k8s resources for me. If I need to use an external tool to generate these resources, then the dekorate value proposition decreases for me.
If the goal is to offer an interactive mode to incrementally generate / populate k8s resources, then it steps into the territory of other tools (
odo
orkn
most notably). I would assume that an organization would want to limit the number of such tools needed to deploy the project to the cluster anddekorate
CLI could be seen as competing with these tools, especially when support for what thedekorate
CLI already exists in these tools or is on their roadmap.Finally, if I was a nodejs developer, I would ideally want to deal with nodejs tools exclusively and would like dekorate to integrate with my code as it does on the java side, i.e. generating the k8s resources during
npm install
for example. If that's not possible, I'm considerably less likely to use dekorate.The text was updated successfully, but these errors were encountered: