Request -> UI - What can access what and how to edit the URL

[casperlundberg]

Generated interfaces/clients should be a function that can be called from the ui or maybe even be their own class? Class seems overhead as long as the RequestClass can provide what's needed to handle the request->response and get metric data. BUT, having the interface as a class means we can save each interface in a list in the ui and easily call them to get data, also allows for the removal of RequestClass and instead make a function that gets the metrics which will be the same for each interface class.

Creating the interface code in a function gives us the ability to call them from the ui and therefore get direct updates, no need to have ui.update(client) anymore which will help a lot.

[casperlundberg]

Classes for generated endpoints Cons:

• A lot of overhead and hard-coded strings in code generation
• A lot of duplicated code to the overhead

Pros:

• Highly flexible for the future additions

Workarounds:

• Use helper functions/class for repetitive task, lower overhead and code duplication

Functions for generated endpoints Cons:

• Low flexibility
• Don't know how well the UI would be able to use more than one function per interface/file

Pros:

• Low overhead
• Next to no code duplication

Workaround:

• Use RequestClass to handle all generic behavior

What solution is best? For the UI, the class version is best since it will act as a config for the helpers that do the actual request.

[casperlundberg]

How should the UI work? Should it be one generated UI component for each interface? Maybe a central UI that got all interface classes saved in a list which will be used in a general way? -> how to process responses from that when we are locked in a non-generated environment? A generated code processer for each interface that parses the response body and gives the user the ability to choose what data to visualize??

[casperlundberg]

How should the UI work? Should it be one generated UI component for each interface? Maybe a central UI that got all interface classes saved in a list which will be used in a general way? -> how to process responses from that when we are locked in a non-generated environment? A generated code processer for each interface that parses the response body and gives the user the ability to choose what data to visualize??

The ui will have a list of generic panels that each is created with the name of the client that they are connected to, this panel obj will then create a client obj to do request (using RequestHelper).

[casperlundberg]

Classes for generated endpoints Cons:

• A lot of overhead and hard-coded strings in code generation
• A lot of duplicated code to the overhead

Pros:

• Highly flexible for the future additions

Workarounds:

• Use helper functions/class for repetitive task, lower overhead and code duplication

Functions for generated endpoints Cons:

• Low flexibility
• Don't know how well the UI would be able to use more than one function per interface/file

Pros:

• Low overhead
• Next to no code duplication

Workaround:

• Use RequestClass to handle all generic behavior

What solution is best? For the UI, the class version is best since it will act as a config for the helpers that do the actual request.

Solution: Create objects and not classes with http config to get the data using the RequestClass. We already know the structure since the openapi specification is static and de-referenced at that point