Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add Cypress #1094

Merged
Show file tree
Hide file tree
Changes from 17 commits
Commits
Show all changes
29 commits
Select commit Hold shift + click to select a range
8287ca2
feat: add Dockerfile, Cypress, code generation
aeworxet May 21, 2024
902c44a
feat: add Dockerfile, Cypress, code generation
aeworxet May 13, 2024
f98436d
feat: add Dockerfile, Cypress, code generation
aeworxet May 13, 2024
385f0d6
feat: add Dockerfile, Cypress, code generation
aeworxet May 13, 2024
8f1f7b0
feat: add Dockerfile, Cypress
aeworxet May 31, 2024
e24606e
feat: add Dockerfile
aeworxet May 31, 2024
ad1d99a
feat: add Dockerfile
aeworxet May 31, 2024
3f72d69
feat: add Dockerfile
aeworxet May 31, 2024
dda3030
feat: add Dockerfile
aeworxet May 31, 2024
8c53284
feat: add Dockerfile
aeworxet Jun 6, 2024
c3baa62
feat: add Dockerfile
aeworxet Jun 6, 2024
961799a
feat: add Dockerfile
aeworxet Jun 6, 2024
53c6915
feat: add Dockerfile
aeworxet Jun 6, 2024
3553e8d
feat: add Cypress
aeworxet Jun 6, 2024
c505fcd
feat: add Cypress
aeworxet Jun 6, 2024
17c7a22
add pnpm-lock.yaml
aeworxet Jun 6, 2024
a07f335
modify package.json
aeworxet May 31, 2024
c0f4083
modify Docker config
aeworxet Jun 21, 2024
2048b44
add .eslintrc
aeworxet Jun 21, 2024
70264db
add ignoring of ESLint's old warnings and error
aeworxet Jun 21, 2024
8583bb0
remove Docker-related code
aeworxet Jun 21, 2024
21e1755
update pnpm-lock.yaml
aeworxet Sep 11, 2024
1db3a5b
update pnpm-lock.yaml
aeworxet Sep 11, 2024
e66f922
Update @asyncapi/converter version
aeworxet Sep 11, 2024
bc3486b
update pnpm-lock.yaml
aeworxet Sep 11, 2024
5051992
renamed `ConvertVersion` -> `AsyncAPIConvertVersion`
aeworxet Sep 11, 2024
0994c77
Merge branch 'master' into feat-add-dockerfile-cypress-code-generatio…
aeworxet Sep 11, 2024
1fc8590
update pnpm-lock.yaml
aeworxet Sep 11, 2024
97fc975
Merge branch 'master' into feat-add-dockerfile-cypress-code-generatio…
KhudaDad414 Sep 17, 2024
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .sonarcloud.properties
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Disable specific file since it would introduce more complexity to reduce it - mainly code complexity and complex template literals
sonar.exclusions=apps/studio/public/js/monaco/**,apps/studio/src/tailwind.css,apps/studio/src/components/SplitPane/**
sonar.exclusions=apps/studio/public/js/monaco/**,apps/studio/src/tailwind.css,apps/studio/src/components/SplitPane/**,apps/studio-next/cypress/**,apps/studio-next/Dockerfile
# Disable duplicate code in tests since it would introduce more complexity to reduce it.
sonar.cpd.exclusions=apps/studio/**,apps/studio-next/src/components/Navigationv3.tsx,apps/studio-next/src/components/Navigation.tsx
sonar.cpd.exclusions=apps/studio/**,apps/studio-next/src/components/Navigationv3.tsx,apps/studio-next/src/components/Navigation.tsx,apps/studio-next/cypress/**
7 changes: 7 additions & 0 deletions apps/studio-next/.dockerignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
Dockerfile
.dockerignore
node_modules
npm-debug.log
README.md
.next
.git
58 changes: 58 additions & 0 deletions apps/studio-next/Dockerfile
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO it is better to follow https://turbo.build/repo/docs/guides/tools/docker and create a docker image that way. it takes forever to install the dependencies (more than 30 minutes). I think it's because we are not leveraging turbo prune to get rid of the unwanted packages.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another point: It takes forever to run post-install scripts of Cypress (I think it installs all of the browsers with each install, like Puppeteer). there should be a way to disable that when building a container. something like --ignore-scripts in npm. 🤔

Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
FROM node:18-alpine AS base

# Install dependencies only when needed
FROM base AS deps
# Check https://github.com/nodejs/docker-node/tree/b4117f9333da4138b03a546ec926ef50a31506c3#nodealpine to understand why libc6-compat might be needed.
RUN apk add --no-cache libc6-compat
WORKDIR /app

# Install dependencies based on the preferred package manager
COPY package.json ./
RUN npm install [email protected] --global
# yarn.lock* package-lock.json* pnpm-lock.yaml* ./
RUN corepack enable pnpm && pnpm i

# Rebuild the source code only when needed
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

# Next.js collects completely anonymous telemetry data about general usage.
# Learn more here: https://nextjs.org/telemetry
# Uncomment the following line in case you want to disable telemetry during the build.
ENV NEXT_TELEMETRY_DISABLED 1

RUN corepack enable pnpm && pnpm run build

# Production image, copy all the files and run next
FROM base AS runner
WORKDIR /app

ENV NODE_ENV production
# Uncomment the following line in case you want to disable telemetry during runtime.
# ENV NEXT_TELEMETRY_DISABLED 1

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public

# Set the correct permission for prerender cache
RUN mkdir .next
RUN chown nextjs:nodejs .next

# Automatically leverage output traces to reduce image size
# https://nextjs.org/docs/advanced-features/output-file-tracing
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3001

ENV PORT 3001

# server.js is created by next build from the standalone output
# https://nextjs.org/docs/pages/api-reference/next-config-js/output
CMD HOSTNAME="0.0.0.0" node server.js
11 changes: 11 additions & 0 deletions apps/studio-next/cypress.config.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
import { defineConfig } from 'cypress';

export default defineConfig({
e2e: {
baseUrl: 'http://localhost:3001',
retries: {
runMode: 1,
openMode: 1,
},
},
});
136 changes: 136 additions & 0 deletions apps/studio-next/cypress/e2e/studio-ui.spec.cy.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,136 @@
// import { isV3 } from "../../src/components/Sidebar";
const isV3Test = true;

/* Testing commented hovers is impossible even with `cypress-real-events` so
testing of these hovers is postponed until either Cypress has better support for
`mouseover`/`mouseenter` events or the architecture of `Studio` is changed to
allow testing those. */

describe('Studio UI spec', () => {
beforeEach(() => {
cy.visit('/');
});

it('Logo should be visible in the UI', () => {
cy.get('[data-test="logo"]').should('be.visible');
});

// it('Logo should display tooltip "AsyncAPI Logo" on hover', () => {
// cy.get('[data-test="logo"]').trigger('mouseenter');
// cy.contains('AsyncAPI Logo').should('be.visible');
// });

it('Button "AsyncAPI Website" should be visible in the UI', () => {
cy.get('[data-test="button-website"]').should('be.visible');
});

// it('Button "AsyncAPI Website" should display tooltip "AsyncAPI Website" on hover', () => {
// cy.get('[data-test="button-website"]').trigger('mouseenter');
// cy.contains('AsyncAPI Website').should('be.visible');
// });

it('Button "AsyncAPI Github Organization" should be visible in the UI', () => {
cy.get('[data-test="button-github"]').should('be.visible');
});

// it('Button "AsyncAPI Github Organization" should display tooltip "AsyncAPI Github Organization" on hover', () => {
// cy.get('[data-test="button-github"]').trigger('mouseenter');
// cy.contains('AsyncAPI Github Organization').should('be.visible');
// });

it('Button "AsyncAPI Slack Workspace" should be visible in the UI', () => {
cy.get('[data-test="button-slack"]').should('be.visible');
});

// it('Button "AsyncAPI Slack Workspace" should display tooltip "AsyncAPI Slack Workspace" on hover', () => {
// cy.get('[data-test="button-slack"]').trigger('mouseenter');
// cy.contains('AsyncAPI Slack Workspace').should('be.visible');
// });

it('Button "Navigation" should be visible in the UI', () => {
cy.get('[data-test="button-navigation"]').should('be.visible');
});

it('Button "Navigation" should display tooltip "Navigation" on hover', () => {
cy.get('[data-test="button-navigation"]').trigger('mouseenter');
cy.contains('Navigation').should('be.visible');
});

it('Button "Editor" should be visible in the UI', () => {
cy.get('[data-test="button-editor"]').should('be.visible');
});

it('Button "Editor" should display tooltip "Editor" on hover', () => {
cy.get('[data-test="button-editor"]').trigger('mouseenter');
cy.contains('Editor').should('be.visible');
});

it('Button "Template preview" should be visible in the UI', () => {
cy.get('[data-test="button-template-preview"]').should('be.visible');
});

it('Button "Template preview" should display tooltip "Template preview" on hover', () => {
cy.get('[data-test="button-template-preview"]').trigger('mouseenter');
cy.contains('Template preview').should('be.visible');
});

if (!isV3Test) { // review the need of v2 testing in general
it('Button "Blocks visualiser" should be visible in the UI', () => {
cy.get('[data-test="button-blocks-visualiser"]').should('be.visible');
});

it('Button "Blocks visualiser" should display tooltip "Blocks visualiser" on hover', () => {
cy.get('[data-test="button-blocks-visualiser"]').trigger('mouseenter');
cy.contains('Blocks visualiser').should('be.visible');
});
}

it('Button "New file" should be visible in the UI', () => {
cy.get('[data-test="button-new-file"]').should('be.visible');
});

it('Button "New file" should display tooltip "New file" on hover', () => {
cy.get('[data-test="button-new-file"]').trigger('mouseenter');
cy.contains('New file').should('be.visible');
});

it('Button "Settings" should be visible in the UI', () => {
cy.get('[data-test="button-settings"]').should('be.visible');
});

it('Button "Settings" should display tooltip "Studio settings" on hover', () => {
cy.get('[data-test="button-settings"]').trigger('mouseenter');
cy.contains('Studio settings').should('be.visible');
});

it('Button "Share" should be visible in the UI', () => {
cy.get('[data-test="button-share"]').should('be.visible');
});

it('Button "Share" should display tooltip "Share link" on hover', () => {
cy.get('[data-test="button-share"]').trigger('mouseenter');
cy.contains('Share link').should('be.visible');
});

it('Button "Dropdown" should be visible in the UI', () => {
cy.get('[data-test="button-dropdown"]').should('be.visible');
});

it('Dropdown menu should contain 8 elements with predefined text', () => {
cy.get('[data-test="button-dropdown"]').click();
cy.contains('Import from URL');
cy.contains('Import File');
cy.contains('Import from Base64');
cy.contains('Generate code/docs');
cy.contains('Save as YAML');
cy.contains('Convert and save as JSON');
cy.contains('Convert to JSON');
cy.contains('Convert document');
});

it('Click on Dropdown menu\'s element "Generate code/docs" should open Modal window "Generate code/docs based on your AsyncAPI Document"', () => {
cy.get('[data-test="button-dropdown"]').click();
cy.contains('Generate code/docs').click();
cy.contains('Generate code/docs based on your AsyncAPI Document');
});
});
5 changes: 5 additions & 0 deletions apps/studio-next/cypress/fixtures/example.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
{
"name": "Using fixtures to represent data",
"email": "[email protected]",
"body": "Fixtures are a great way to mock data for responses to routes"
}
37 changes: 37 additions & 0 deletions apps/studio-next/cypress/support/commands.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
/// <reference types="cypress" />
// ***********************************************
// This example commands.ts shows you how to
// create various custom commands and overwrite
// existing commands.
//
// For more comprehensive examples of custom
// commands please read more here:
// https://on.cypress.io/custom-commands
// ***********************************************
//
//
// -- This is a parent command --
// Cypress.Commands.add('login', (email, password) => { ... })
//
//
// -- This is a child command --
// Cypress.Commands.add('drag', { prevSubject: 'element'}, (subject, options) => { ... })
//
//
// -- This is a dual command --
// Cypress.Commands.add('dismiss', { prevSubject: 'optional'}, (subject, options) => { ... })
//
//
// -- This will overwrite an existing command --
// Cypress.Commands.overwrite('visit', (originalFn, url, options) => { ... })
//
// declare global {
// namespace Cypress {
// interface Chainable {
// login(email: string, password: string): Chainable<void>
// drag(subject: string, options?: Partial<TypeOptions>): Chainable<Element>
// dismiss(subject: string, options?: Partial<TypeOptions>): Chainable<Element>
// visit(originalFn: CommandOriginalFn, url: string, options: Partial<VisitOptions>): Chainable<Element>
// }
// }
// }
20 changes: 20 additions & 0 deletions apps/studio-next/cypress/support/e2e.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
// ***********************************************************
// This example support/e2e.ts is processed and
// loaded automatically before your test files.
//
// This is a great place to put global configuration and
// behavior that modifies Cypress.
//
// You can change the location of this file or turn off
// automatically serving support files with the
// 'supportFile' configuration option.
//
// You can read more here:
// https://on.cypress.io/configuration
// ***********************************************************

// Import commands.js using ES2015 syntax:
import './commands'

// Alternatively you can use CommonJS syntax:
// require('./commands')
13 changes: 7 additions & 6 deletions apps/studio-next/next.config.js
Original file line number Diff line number Diff line change
Expand Up @@ -7,9 +7,9 @@ const nextConfig = {
config.module.rules.push({
test: /\.yml$/i,
type: 'asset/source',
})
});

if (isServer) return config
if (isServer) return config;
// Important: return the modified config
config.resolve.fallback = {
...config.resolve.fallback,
Expand All @@ -25,7 +25,7 @@ const nextConfig = {
debug: false,
canvas: false,
fs: false,
}
};

config.plugins.push(
new webpack.ProvidePlugin({
Expand All @@ -34,8 +34,9 @@ const nextConfig = {
})
);

return config
return config;
},
}
output: 'standalone'
};

module.exports = nextConfig
module.exports = nextConfig;
15 changes: 11 additions & 4 deletions apps/studio-next/package.json
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,14 @@
"dev": "next dev -p 3001",
"build": "next build",
"start": "next start",
"lint": "echo 'No linting configured'"
"lint": "next lint",
"docker:build": "docker build -t asyncapi/studio:latest .",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docker build should be done at the root of the project (so turborepo is able to prune the unwanted packages). maybe something like: "build:next-studio:docker": "docker build -t asyncapi/studio:latest -f StudioNextDockerfile ." at the root.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simply making sure that Turborepo will not start to be turned into a monolith again after this change.

Might it be better, just in case, to keep possibility to dockerize each app separately with Docker Compose, like it's done in https://github.com/dhaaana/turborepo-with-docker:

?
(meaning Dockerfile will stay where it is now, but Docker Compose setup will be added)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's possible to publish the separate docker image after this, I have no issue with it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

turbo prune studio-next --docker copies to ./out's node_modules containing pnpm's symlinks, which, after being copied, immediately become invalid (because they point to previous relative destinations,) but doing pnpm install each time there's a need to build a Docker image is not an option either. So I'm trying different configurations to achieve local caching in at least some form, and each build takes time. Thus delay.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed approach in favor of pushing into the Docker image the already compiled Studio.
I took advantage of turbo build cache, and now if there is a fresh turbo's build cache, then the generation of the Docker image takes not even seconds but milliseconds.

image

Please try running

turbo build
turbo run build:studio-next:docker

in the root of the repo and check.

The generated Docker image (became 294MB) is run with

docker run -p 3001:3001 asyncapi/studio

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon some reflection I think my tone might have come across as too critical and for that I apologize.

My intentions were to provide technical feedback not to criticize you or your efforts personally.

I know you have worked hard on the issue and I don't think it was just for you to be suspended in the bounty program or not getting the reward for this bounty issue.

If you think it's best to remove the docker and merge the remaining code, let's do that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe you should clone this branch from scratch and do in the repo's root

pnpm install
docker builder prune -a    # <-- remove Docker's build cache
turbo build:studio-next:docker

?

Just built again with these steps

image

I cleaned the project reinstalled the packages and built the image with turbo build:studio-next:docker

The size now shows up correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about reusing the same compiled code for two simultaneous deployments now?

release process can have two simultaneous deployments:

  • Build and deploy to the studio.asyncapi.com.
  • Reuse already built binaries (with turbo cache) to generate (push them into) a Docker image and deploy it to the Docker hub.

This process will guarantee that there is one same Studio, built from one same commit, with the same hashes, in both places.
(I already have a situation right now when the same bug gets reproduced in one place, doesn't in another, and gives a third error in the local dev)

Copy link
Member

@KhudaDad414 KhudaDad414 Jul 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aeworxet

What do you think about reusing the same compiled code for two simultaneous deployments now?

Just wanted to clarify all my concerns. If they are invalid we can definitely go ahead with this approach.

Building in One Environment and Running in Another Is Generally a Bad Idea

As you know, we are using linux to run random workflows. However, when it comes to publishing or testing, we are using a matrix of (Linux, Windows, and Mac) to build, publish or test our code.

Why? Because we want to make sure that it is built within the environment that it is going to run on. How can you be sure that if you build something on Linux, it will run on Windows? You might argue that they are different since docker has it's own Engine on top of the OS and it will work. You might be right, but we need to test that theory. Is it worth it to go though the trouble, I don't think so.
All I know is that some packages are platform-dependent. By installing in the Docker image itself, we make sure that all our packages are installed, built, and run in the same environment.

That's why building in the Docker image itself is always better.

Transparency

When I look at the Dockerfile, I should be able to see that yes, I am actually downloading the source code and building it myself on my machine. This gives me peace of mind that nobody is pushing some fishy code into my environment. Most of the ecosystem now doesn't trust pre-built packages because of incidents like the XZ fiasco.

Docker Cache

As I mentioned previously, Docker is really smart when it comes to building and running your image. If you follow best practices, it can help your package be as slim as possible.

For example, if you haven't changed your package.json or lock file, why would you want to install your packages from scratch? Well, you don't want that. You want to get the source code, which is probably a few MB, use the cached version of the package installation layer, and build on top of that, right? Well, Docker is going to do exactly that. But if you are pushing an already built 290MB of code in a single layer, Docker won't be able to do anything. Even if the next version only changes by one byte, it has to invalidate that layer and install the entire 290MB of code again.

So in a Dockerfile, it is always better to break down your build, installation, and run layers as much as you can. More layers mean Docker is able to cache more efficiently when building and when running.

Harder to Maintain

It is hard to maintain a separate and custom workflow to do things. People expect simplicity. If I want to build an image, I would naturally expect the docker build command to work. why does it have to be dependent on other processes like installation and building?

If you build one more layer of abstraction on top and use a script, it is suspicious to say the least. Contributors/Users will have to check what exactly you are doing in that script and why they can't just build it with a simple docker build command.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for investing time in explaining all that.
I now understand that I should have taken specific end users' needs into account also, not only aim at easing the release process for the 'vendor.' 
The Docker build should definitely be developed by someone who understands Docker better.
Removed Docker-related code and changed the PR's description accordingly.

"cy:e2e:chrome": "cypress run --e2e --browser chrome",
"cy:e2e:chromium": "cypress run --e2e --browser chromium",
"cy:e2e:edge": "cypress run --e2e --browser edge",
"cy:e2e:electron": "cypress run --e2e --browser electron",
"cy:e2e:firefox": "cypress run --e2e --browser firefox",
"cy:open": "cypress open"
},
"dependencies": {
"@asyncapi/avro-schema-parser": "^3.0.19",
Expand All @@ -30,12 +37,10 @@
"react-icons": "^4.6.0",
"reactflow": "^11.2.0",
"@stoplight/yaml": "^4.3.0",
"@codemirror/view": "^6.26.3",
"@types/node": "20.4.6",
"@types/react": "18.2.18",
"@types/react-dom": "18.2.7",
"autoprefixer": "10.4.14",
"codemirror": "^6.0.1",
"eslint-config-next": "13.4.12",
"next": "14.2.3",
"postcss": "8.4.31",
Expand Down Expand Up @@ -72,6 +77,7 @@
"autoprefixer": "^10.4.13",
"browserify-zlib": "^0.2.0",
"buffer": "^6.0.3",
"cypress": "^13.10.0",
"eslint-config-next": "14.1.4",
"eslint-plugin-security": "^1.5.0",
"eslint-plugin-sonarjs": "^0.16.0",
Expand All @@ -88,5 +94,6 @@
"util": "^0.12.5",
"web-vitals": "^3.1.0",
"webpack": "^5.75.0"
}
},
"packageManager": "[email protected]"
}
8 changes: 5 additions & 3 deletions apps/studio-next/scripts/template-parameters.ts
Original file line number Diff line number Diff line change
Expand Up @@ -6,17 +6,19 @@ import { JSONSchema7 } from 'json-schema';

const DESTINATION_JSON = path.join(__dirname, '../src/components/Modals/Generator/template-parameters.json');
const TEMPLATES: Record<string, string> = {
'@asyncapi/dotnet-nats-template': '.NET Nats Project',
'@asyncapi/dotnet-nats-template': '.NET NATS Project',
'@asyncapi/dotnet-rabbitmq-template': '.NET C# RabbitMQ Project',
'@asyncapi/go-watermill-template': 'GO Lang Watermill Project',
'@asyncapi/html-template': 'HTML website',
'@asyncapi/java-spring-cloud-stream-template': 'Java Spring Cloud Stream Project',
'@asyncapi/java-spring-template': 'Java Spring Project',
'@asyncapi/java-template': 'Java Project',
'@asyncapi/markdown-template': 'Markdown Documentation',
'@asyncapi/nodejs-template': 'NodeJS Project',
'@asyncapi/nodejs-ws-template': 'NodeJS WebSocket Project',
'@asyncapi/nodejs-ws-template': 'NodeJS WebSocket Projects',
'@asyncapi/php-template': 'PHP RabbitMQ Project',
'@asyncapi/python-paho-template': 'Python Paho Project',
'@asyncapi/ts-nats-template': 'Typescript Nats Project',
'@asyncapi/ts-nats-template': 'Typescript NATS Project',
};
const SUPPORTED_TEMPLATES = Object.keys(TEMPLATES);

Expand Down
6 changes: 6 additions & 0 deletions apps/studio-next/src/app/api/v1/generate/route.tsx
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
import { NextResponse } from 'next/server';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we can use Server Actions instead 🤔 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jerensl

I searched the Internet back and forth and couldn't find answers to several simple questions.
You seem to be very knowledgeable in Next.js Server's matters, so I would like to consult with you on this topic.

Server Actions are meant for performing data fetching and mutations on the Next.js Server.
To my understanding, this implies that Server ALREADY exists as an independent entity, in order for a Server Action to have an environment to be executed in.
In this particular case, right now, full Server consists of one API route.
Thus, if this one and only API route is replaced by a Server Action, the Server will simply vanish, and Server Action will have no place to be executed in.
Besides, this API route is responsible for Server Response, which requires exactly the next/server package, and not for data fetching from a third-party resource or a mutation.

Taking this into account, does Server Action even make sense in this case, or should the structure with one API route remain (for now, the final architecture of the Studio's Server-Side is not defined yet, and this route is added only as a Proof Of Concept and a stub in place where the future Server will be?)

Please correct me if I'm getting something wrong in the new for me concept of Server Actions.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aeworxet

I searched the Internet back and forth and couldn't find answers to several simple questions. You seem to be very knowledgeable in Next.js Server's matters, so I would like to consult with you on this topic.

I still new to this Reace Server Components (RSC), so I will answers as much as I know

Server Actions are meant for performing data fetching and mutations on the Next.js Server. To my understanding, this implies that Server ALREADY exists as an independent entity, in order for a Server Action to have an environment to be executed in. In this particular case, right now, full Server consists of one API route. Thus, if this one and only API route is replaced by a Server Action, the Server will simply vanish, and Server Action will have no place to be executed in. Besides, this API route is responsible for Server Response, which requires exactly the next/server package, and not for data fetching from a third-party resource or a mutation.

Taking this into account, does Server Action even make sense in this case, or should the structure with one API route remain (for now, the final architecture of the Studio's Server-Side is not defined yet, and this route is added only as a Proof Of Concept and a stub in place where the future Server will be?)

The thing about Api Route which their rebranding as Route Handler is not supposed to be replaced by Server Actions but different type options in the Architecture which would be considered during the design

https://www.youtube.com/watch?v=PtX5PF17tlQ

Please correct me if I'm getting something wrong in the new for me concept of Server Actions.

Server Actions are supposed to work on top of the React Server Component(RSC) but the majority of the applications inside StudioWrapper do not leverage RSC even for NextJS features like SSR/SSG do not work there

Static Side Generator -> render JSX to HTML during built time
Server Side Rendering -> render JSX to HTML at server when requested by a Client (give what u need only)

This one of the good resources Dan Abramov explains what are the responsibilities of SSR(What NextJS did) and RSC, and how they work together interchangeably
reactwg/server-components#5

Copy link
Contributor Author

@aeworxet aeworxet Jun 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jerensl
Thanks.

@KhudaDad414
Would it be safe to assume that Server Actions should not be used currently?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aeworxet you are right, we first need to decide how we are going to architecture the component for the app directory.


export async function POST(request: Request) {
const response = await request.json();
return new NextResponse(`route POST -> ${JSON.stringify(response)}`, {status: 201});
}
Loading
Loading