feat: add Dockerfile, Cypress, code generation, CodeMirror

[aeworxet]

This PR finishes the migration of Studio to the React framework Next.js.

• Added Dockerfile
• Added Cypress testing tool:
    - GUI testing is invoked with npm run cy:open
    - Headless end-to-end testing for different browsers is invoked with npm run cy:e2e:* (refer to the cy:e2e:* part of package.json for a list of available browsers (edge is reserved for Windows machines))
• Fixed code generation
• Replaced Monaco code editor with CodeMirror

This PR is built on top of #1062, so it must be merged only AFTER.
Comparison with PR #1062

Resolves #661

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8cc5df0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[netlify]

❌ Deploy Preview for modest-rosalind-098b67 failed.

Name	Link
🔨 Latest commit	8cc5df0
🔍 Latest deploy log	https://app.netlify.com/sites/modest-rosalind-098b67/deploys/6665e4cdd415a70008569f3b

[netlify]

❌ Deploy Preview for asyncapi-studio-design-system failed.

Name	Link
🔨 Latest commit	8cc5df0
🔍 Latest deploy log	https://app.netlify.com/sites/asyncapi-studio-design-system/deploys/6665e4cd592528000803492f

[netlify]

❌ Deploy Preview for studio-next failed.

Name	Link
🔨 Latest commit	8cc5df0
🔍 Latest deploy log	https://app.netlify.com/sites/studio-next/deploys/6665e4cdead02800088d0646

[aeworxet]

@Amzani @KhudaDad414
@asyncapi/bounty_team

[aeworxet]

I started with the addition of Cypress so I could spot regressions during migration to CodeMirror.
Comparison with PR #1062

@Amzani
A couple of questions:

• Is there a design file (Figma maybe?) where I can take unique names for all HTML elements from, so testing frameworks could find them in the webpage (same as I gave the name data-testid="button-settings" to the Settings button?)
• What names should I give to HTML elements' data-* attributes: data-testid, data-test, or data-cy?
• Should there be a separate spec file for components' testing, or, in the case of Studio, only full flow (e2e) makes sense?

[Amzani]

@aeworxet

Is there a design file (Figma maybe?) where I can take unique names for all HTML elements from, so testing frameworks could find them in the webpage (same as I gave the name data-testid="button-settings" to the Settings button?)

Not for the existing studio, we only have one for the new improvements that will be integrated once we finish the NextJS migration: https://www.figma.com/proto/bPMB3lkMTOOMuKk0oGLuNm/Studio?type=design&node-id=96-2392&scaling=contain&page-id=0%3A1&starting-point-node-id=2%3A2

What names should I give to HTML elements' data-* attributes: data-testid, data-test, or data-cy?

I vote for data-test for simplicity and in case we want to switch to an other testing tool in the future.

Should there be a separate spec file for components' testing, or, in the case of Studio, only full flow (e2e) makes sense?

The goal is regression test, so I would suggest full flow (e2e), we can encourage components testing for new feature we add to the project.

@KhudaDad414 WDY?

[Amzani]

I would remove CodeMirror Integration from the scope of this issue for now, until we merge everything.

[aeworxet]

I'm working on code generation for Studio, and after POST request to https://api.asyncapi.com/v1/generate I get

Version 3.0.0 is not supported.
Please use latest version of the specification.

Code, responsible for this is
https://github.com/asyncapi/parser-js/blob/master/src/ruleset/functions/isAsyncAPIDocument.ts#L25
https://github.com/asyncapi/parser-js/blob/master/src/constants.ts#L22
and the file which is searched for for 3.0.0 HAS it in master:
https://github.com/asyncapi/spec-json-schemas/blob/master/index.d.ts#L12

It needs to be checked on the server what version of ./node_modules/@asyncapi/specs/index.d.ts it contains.
@smoya

[Amzani]

@aeworxet we should remove the dependency with https://github.com/asyncapi/server-api in the NextJS version of studio as this repository might be deprecated soon.

So the idea is to directly use the generator library.

Not all of them supports V3, AFAIK the following supports V3

• https://github.com/asyncapi/nodejs-template/
• https://github.com/asyncapi/html-template
• https://github.com/asyncapi/markdown-template

If < V3 all the generators should work as expected.

[smoya]

So the idea is to directly use the generator library.

@Amzani would you mind linking to where that decission has been made? Just to be in sync with asyncapi/server-api#576 where the idea, afaik, was to keep a server but the code living in CLI repo.

[Amzani]

@smoya I was assuming that if only Studio uses this API there is no need to maintain it anymore thus deprecating the server-api repo and not migrate it to CLI to reduce complexity.

[aeworxet]

So the idea is to directly use the generator library.

@Amzani

@KhudaDad414 suggests the opposite, to stick with server-api.
So which one should it be?

Should I invest time into rewriting the logic for SSR, or should I just bugfix the current approach?

(#1094 (comment) is still relevant then)

[KhudaDad414]

@aeworxet IMHO it makes sense to bug fix the current code base. By that I mean sticking to the server-api approach.

As Fran said in the original issue, migration is already hard enough, trying to implement new features at the same time would quadruple the complexity.

[aeworxet]

@KhudaDad414
'Code Generation' functionality still requires checking of the ./node_modules/@asyncapi/specs/index.d.ts version on api.asyncapi.com as per #1094 (comment) since it is the server that is returning the error.

[KhudaDad414]

@aeworxet Since you get the error on the current Studio as well, I would consider resolving it to be out of scope for this Bounty Issue.

We can have another issue and discuss it over there.

[aeworxet]

I'm investigating options for deployment of Studio to a Docker container, and the possibility that the server part might become completely independent, up to being hosted fully in a CLI with invocation through asyncapi server start, led me to a question if deployment of Studio to a Docker container as a full Next.js app (with API Routes, SSR, and others) is needed at all.

The most runtime-dynamic part of Studio currently is the generation of templates, and it can be done through a POST request to an API from a static website (it is made this way currently, in fact.)

I'm not sure OG preview generation is a mandatory functionality for a containerized Studio, it can be left reserved for https://studio.asyncapi.com

I have deployed to https://asyncapi-studio-studio-next.vercel.app a build of Studio with output: 'export' (explanation what 'export' build is, features that are NOT supported.)

The whole 'export' build is nine (9) Mb, it has First Contentful Paint 0.4 s (+ better overall performance score in Lighthouse,) and it doesn't seem to lack any functionality.

Should this version of Studio's build be used for a Docker container?

[Amzani]

The most runtime-dynamic part of Studio currently is the generation of templates, and it can be done through a POST request to an API from a static website (it is made this way currently, in fact.)

We want to enable long term features like authentication for instance. generation of templates using API to POST should be something we could migrate IMO as we don't want to maintain an entire repository just for 1 single POST /generate method instead of using directly the generator library.

Should this version of Studio's build be used for a Docker container?

How complex is having everything in Docker image?

[aeworxet]

@Amzani

How complex is having everything in Docker image?

It is supposed to be straightforward but I ran into an error on a command that executes fine on desktop, so I'm investigating it.

[aeworxet]

I hoped to have for ouput: 'export' a 20 MB Docker image (5 MB alpine linux + 9 MB static Studio + several MB for nginx,) but for output: 'standalone' Node.js v18 alone takes 125 MB, and overall Docker image size is 282 MB (compiled Studio is 20 MB, though.) The previous Docker image was 91 MB.

A request to the API works as a POC.

I attempted to delete something unneeded, but it seems that everything in this Docker image is used for one process or another:

Try image:

cd ./apps/studio-next
docker build .
docker images # the freshly built Docker image is most probably the topmost one
docker run -p 3001:3001 [image_name]

http://localhost:3001

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarCloud