[Infra] BE Endpoints Improvements

[mykolaharmash]

A few potential improvements that we could do to improve the current state of Infra backend:

• URL pattern restructuring proposed by @crespocarlos
• Utilizing requestContext more instead of passing around a custom libs object
• Unify payload (params/body) validation to use io-ts types to ensure FE ↔ BE type-safety
• Extract repetitive code, like getting source configuration, into some reusable place
• Consider using route repositories pattern similar to how APM does it
• Consider moving route initialization to plugin's start phase. At the moment most of the endpoints require something from start dependencies which requires an async call to get them.
• Review the file structure and make sure it follows a consistent convention

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[cauemarcondes]

• prefix with /internal/ all APIs that are not public.

[roshan-elastic]

Thanks for this, I've reviewed this but in order to prioritise, more info needed in order to understand user value for this.

Are you able to summarise what this value this brings to the user?

[crespocarlos]

@roshan-elastic This is a tech debt, users won't benefit directly from it. This is to address some of the inconsistencies in the infra APIs code and improve it.

[roshan-elastic]

Cheers @crespocarlos - would you say this is one of the best tech debts we could focus on in the backlog or is there something better?

We have space in our top 20 for some tech debt so if you have some candidates, let me know

[crespocarlos]

@roshan-elastic

From that list, I would prioritize the first one. Our APIs need to contain /internal/ in the path.

The items below could be put on hold for now but will be important shortly.

Consider using route repositories pattern similar to how APM does it

• Soon we'll have better reasons to revisit this. We want to change some things so that the Open API specs can be automatically generated

Consider using route repositories pattern similar to how APM does it

• There is already something in @kbn/server-route-repository for that. we just need to use it. Using that, will help with the item above

These are about improving the code base and don't have high priority

Utilizing requestContext more instead of passing around a custom libs object

Review the file structure and make sure it follows a consistent convention

This is a separate topic entirely and needs to be refined and addressed in another ticket

Extract repetitive code, like getting source configuration, into some reusable place

• We can probably remove the concept of "source configuration" altogether.

[roshan-elastic]

Oh sorry @crespocarlos - I meant out of the entire backlog :)

If this is one of the top pain-points, I'll prioritise this as top 20 now...(but if there's something else really bugging you as tech debt...I can prioritse that)