Business logic to act as API layer?

[dharmit]

This was originally discussed on #5293 (comment).

odo has a few gaps when it comes to JSON output. To be specific, the outputs are inconsistent at few places, incomplete at other, and overall unreliable as we keep changing things. Sometimes even between patch releases (z stream).

Part of this is attributed to not having API documentation and design; we keep adding/modifying/removing things as it dims fit to us at CLI level without much thought into how it would impact tooling created on top of odo. Another reason for this problem is that we never had, what @feloy described as, a "contract" that gave an idea about what to expect in terms of JSON output for various commands.

As mentioned in the original discussion linked above and conversation with @deboer-tim, we should return structs from the business logic layer such that:

• if the CLI user requested JSON output, the CLI layer could simply marshal these structs into JSON
• if the CLI user requested human-readable output, CLI layer could use these structs to construct one

Maybe getting too optimistic here, but this could also make odo usable as a library instead of just CLI.

/kind discussion

[mohammedzee1000]

On Thu, Jan 6, 2022, 11:34 Dharmit Shah ***@***.***> wrote: This was originally discussed on #5293 (comment) <#5293 (comment)>. odo has a few gaps when it comes to JSON output. To be specific, the outputs are inconsistent at few places, incomplete at other, and overall unreliable as we keep changing things. Sometimes even between patch releases (z stream). Part of this is attributed to not having API documentation and design; we keep adding/modifying/removing things as it dims fit to us at CLI level without much thought into how it would impact tooling created on top of odo. Another reason for this problem is that we never had, what @feloy <https://github.com/feloy> described as, a "contract" that gave an idea about what to expect in terms of JSON output for various commands. As mentioned in the original discussion linked above and conversation with @deboer-tim <https://github.com/deboer-tim>, we should return structs from the business logic layer such that: - if the CLI user requested JSON output, the CLI layer could simply marshal these structs into JSON - if the CLI user requested human-readable output, CLI layer could use these structs to construct one - +1 this is how it should have been from beginning. Right now we have an

unnecessary amount of peaky abstractions There should be clear seperation of concern between layers and a clear communication interface in terms of well defined structures.

…

- Maybe getting too optimistic here, but this could also make odo usable as a library instead of just CLI. /kind discussion — Reply to this email directly, view it on GitHub <#5317>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBG3ENO7LPPQANVHGOG4IDUUUWG3ANCNFSM5LLSN3HQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dharmit]

• odo should itself be the consumer of odo's JSON output.
• Add more struct types at business logic layer
• All operations that odo does should be methods of these structs
• Business logic to return these structs whenever CLI layer requests for anything
• Human readable output should be generated at CLI layer from the structs returned by business layer. This info should be the single source of truth unlike the current approach where CLI layer does its own thing at times
• url/endpoint and storage information are stored in .odo/env/env.yaml as 1-1 mappings aren't available in devfile. We could store this info in devfile as attributes