ENG-0000 - Refresh + API Client Architecture

[mcnielsen]

Summary

• Updated type script to 4.7.x
• Updated other packages to corresponding latest version
• AlApiClient renamed to AlXHRAdapter for accuracy
• AlDefaultClient renamed to AlRootClient (again, for accuracy)
• Added @ServiceClient decorator and AlBaseServiceClient, allowing JIT
  service instantiation and better tree shaking
• Updated AIMSClient and SubscriptionsClient to use new client model
• Retired some obsolete content

Client Architecture:

Previously, our API Client architecture has consisted of declaring the
client class and then immediately instantiating it as a global variable.
In practice, this means that clients a) cannot be tree shaken or bundled
outside of the main bundle, and b) every client must by compiled and
instantiated before application bootstrap. This is dumb.

The new model uses a decorator to identify classes that represent a
client. The decorator stores the class's constructor and some default
settings for it into a dictionary, which can be used to instantiate the
client on-demand.

For example:

@ServiceClient( {
    service_name: "gestalt",
    service_stack: AlLocation.GestaltAPI,
    version: 1
} )
export class AlsGestalt extends AlBaseServiceClient {
    ...
}

Or

@ServiceClient( {
    service_name: "iris",
    version: 'v3',
    residencyAware: true
} )
export class AlsIris extends AlBaseServiceClient {
    ...
}

These classes do not need to be instantiated until they are actually
needed. Additional, the properties provided to the ServiceClient
decorator as used as defaults, and the AlBaseServiceClient provides
convenience get, put, post, delete, and request methods to
facilitate extremely minimal implementations.

Nomenclature:

Client classes should begin with an "Als" prefix, and be stored with a
.service-client.ts extension.

[al-cibot]

CI Service Job Number 606 Logs - FAILURE

alps ci job-logs --organization alertlogic --repository nepal-core --job-num 606 -g

Stages Run:

• PR Test

[mcnielsen]

test it

[al-cibot]

CI Service Job Number 607 Logs - FAILURE

alps ci job-logs --organization alertlogic --repository nepal-core --job-num 607 -g

Stages Run:

• PR Test

[al-cibot]

CI Service Job Number 608 Logs - FAILURE

alps ci job-logs --organization alertlogic --repository nepal-core --job-num 608 -g

Stages Run:

• PR Test

[al-cibot]

Unit Test Coverage Report

branches

64.35% 1105/1717

branchesTrue

100% 0/0

functions

72% 450/625

lines

73.2% 2054/2806

statements

73.42% 2130/2901

[al-cibot]

CI Service Job Number 609 Logs - SUCCESS

alps ci job-logs --organization alertlogic --repository nepal-core --job-num 609 -g

Stages Run:

• PR Test

[parky128]

This is pretty damn cool, you really are a 🧙‍♂️ aren't you?

I'm loving how those convenience methods for get, post, etc mean you now dont have to repeat yourself adding the service name, stack and versions.

In terms of consumption it looks like its just a case of changing something like

import {DashboardsClient} from '@al/dashboards'
...
DashboardsClient.getUserDashboardItem(...)

to be

import {
    AlRootClient,
    AlsDashboards,
} from "../core";
...
AlRootClient.getClient( AlsDashboards ).getUserDashboardItem(...)

I guess to help with adopting this new approach, where our guys are used to importing the global instances, they could just assign the result of getClient into a variable in say their component\service constructors and reference it accordingly.

const dashboardsClient = AlRootClient.getClient(AlsDashboards)
dashboardsClient.getUserDashboardItem(...)

Im also assuming for the non core clients, so those we currently have as separate packages, these would now get folded into the main src/client directory and we no longer publish individual libs?

As for next steps, do you want any assistance with migrating rest of the codebase and then we try and suck into a feature branch of magma, or you already on that?