feat: new CLI architecture

[Amzani]

Resolves https://github.com/asyncapi/server-api/issues/485 Resolves https://github.com/asyncapi/cli/issues/781

This PR introduces changes discussed in https://github.com/asyncapi/server-api/issues/485#issuecomment-1961317382 and https://github.com/asyncapi/cli/issues/781#issuecomment-1990571897

New features

New architecture/flags extractions

.
├── adapters
│   ├── api
│   │   ├── controllers
│   │   │   ├── generator.controller.ts
│   │   │   └── ping.controller.ts
│   │   └── core
│   │       ├── app.ts
│   │       ├── constants.ts
│   │       ├── exceptions
│   │       ├── interfaces.ts
│   │       ├── logs
│   │       ├── middlewares
│   │       └── server-api.d.ts
│   └── cli
│       ├── commands
│       │   ├── bundle.ts
│       │   ├── config
│       │   ├── convert.ts
│       │   ├── diff.ts
│       │   ├── generate
│       │   ├── new
│       │   ├── optimize.ts
│       │   ├── start
│       │   └── validate.ts
│       └── core
│           ├── base.ts
│           ├── flags
│           ├── global.d.ts
│           ├── globals.ts
│           ├── hooks
│           ├── models
│           └── parser.ts
├── api.ts
├── core
│   └── services
│       ├── archiver.service.ts
│       └── generator.service.ts
├── errors
│   ├── context-error.ts
│   ├── diff-error.ts
│   ├── generator-error.ts
│   ├── specification-file.ts
│   └── validation-error.ts
├── index.ts
├── logs
├── ports
│   └── generator.interface.ts
└── utils
    ├── ajv.ts
    ├── generator.ts
    ├── logger.ts
    └── temp-dir.ts

This architecture will enable CODE Maintainers split discussed in https://github.com/asyncapi/cli/issues/781

API foundations

To test the API

./bin/run start api -p 3001
curl --location 'http://localhost:3001/v1/generate' \
--data-raw '{
    "asyncapi": "asyncapi: 3.0.0\ninfo:\n  title: Account Service\n  version: 1.0.0\n  description: This service is in charge of processing user signups\nchannels:\n  userSignedup:\n    address: user/signedup\n    messages:\n      UserSignedUp:\n        $ref: '\''#/components/messages/UserSignedUp'\''\noperations:\n  sendUserSignedup:\n    action: send\n    channel:\n      $ref: '\''#/channels/userSignedup'\''\n    messages:\n      - $ref: '\''#/channels/userSignedup/messages/UserSignedUp'\''\ncomponents:\n  messages:\n    UserSignedUp:\n      payload:\n        type: object\n        properties:\n          displayName:\n            type: string\n            description: Name of the user\n          email:\n            type: string\n            format: email\n            description: Email of the user",
    "template": "@asyncapi/html-template",
    "parameters": {
        "pdf": "true"
    }
}'

http://localhost:3001/v1/ping is also available

./bin/run new file
(When Asked to open Studio - the local API will start as well

Scope

• [x] Migrate /generate API endpoint
• [x] Create Generator service
• [x] Add some tests
• [x] Extract Flags

[sonarqubecloud[bot]]

Quality Gate passed

Issues
78 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[Amzani]

As this PR is quite big, I'll create additional issues for

• [ ] Add Parser middleware in /generate
• [ ] Deploy - CI/CD API

[derberg]

regarding this new architecture, where current package.json lands? probably each adapter will have its own, but will we use npm workspaces and keep generic package.json in root? it is needed for release pipelines so we do not have to customize them just for this repo.

also, looking at new architecture proposal. Let's imagine that I want to propose that some repos for libraries that are used in CLI and Studio should be merged here. Let's say (not consulted with anyone, just in my head for a while) we decide to merge https://github.com/asyncapi/optimizer/ in, still released as independent package, but source code developed under CLI repo. Would that be another adapter?

[Amzani]

All commands + API share the same package.json, didn't complicate things for now.

The input adapters that we have for now are CLI and API, in the example you provided it feels more like a business logic that needs to be merged and used by the optimize command. Then we might have 2 ways to do it

1. Add it as a core service under src/core/services - especially if this logic will be shared by multiple adapters (cmd+cli)
2. This logic is local to optimize command then it should go to adapters/cli/services

[derberg]

All commands + API share the same package.json, didn't complicate things for now.

one in the root?

[Amzani]

All commands + API share the same package.json, didn't complicate things for now.

one in the root?

Yes

[derberg]

@Amzani ok, than in theory release process should not be affected. Just keep in mind that package.json keeps the project name and version and it should eventually reflect what is published to npm. But yeah, I agree that can be done later, as in the end server-api doesn't have to go to npm, same even with CLI GitHub Action

[Shurtu-gal]

@Amzani I suppose we can try to merge this PR as conflicts will keep piling up.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
12 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[Amzani]

As this is a big change I'll merge the changes in different PRs, for now I'm delivering part 1) which includes:

• Split core/commands
• Extract flags

Having API as part of CLI is not yet clear as per my comment here - If the only studio is the API consumer, and api-server package is not used why increase the complexity of CLI. cc @smoya

[Amzani]

/rtm

[asyncapi-bot]

:tada: This PR is included in version 1.18.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket:

[AayushSaini101]

@Amzani @Souvikns Do we have plan to Migrate /generate API endpoint in the CLI ?

[Amzani]

What's your use case @AayushSaini101