Start using a React framework

[fmvilas]

Problem

What's the story exposing the problem the users are facing

CRA (create-react-app) is dead. They're gonna replace it with a launcher where you can select a framework.

Solution

Proposed solution with mockups, views...

That said, we should evaluate a framework and bet on it (no pun intended 😄). Things we need to take into account at first sight:

1. The framework needs to be well maintained and have an active community behind it. We don't to repeat this in a few months 😅
2. It needs to be possible to be deployed to Netlify. We have an open-source plan with them and that means we won't have to pay for the hosting. Please take into account that Netlify doesn't let you run server-side code (unless it's in a Netlify Function) but they do have support for certain frameworks like Next.js where they make this possible.
3. It needs to be secure.
4. It has to be as performant as possible. Studio is gonna grow into a big product that's gonna span multiple pages.
5. It would be great if it has a built-in way to create APIs. We're gonna need an API to power Studio and that will probably be exposed for anyone to use.
6. It should have good TypeScript support.
7. The monaco-editor package is gonna give us headaches, that's for sure. Make sure you can integrate it with the framework.

Lots of things to take into account when evaluating. An initial list of frameworks that come to my mind are:

1. Next.js
2. Vite
3. Remix
4. Gatsby

Learn more here: https://react.dev/learn/start-a-new-react-project#production-grade-react-frameworks.

Rabbit holes

Potential technical, design ... challenges

Well, we're gonna change the foundations of the project so there will be rabbit holes for sure. My advice is to try to keep it as simple as possible. This issue is just about migrating to a framework, not improving the codebase. Keep it simple. We can improve the codebase in other pull requests.

Scope

Describe a list of tasks or issues that needs to be done ( you don't need to have an exhaustive list of all the tasks in the beginning)

• Evaluate Next.js
• Evaluate Vite
• Evaluate Remix
• Evaluate Gatsby
• Minimal studio App with a working editor and AsyncAPI documentation #684
• Add an ADR for using Next.js #1063
• Add new tests with Cypress
• Add new DockerFile
• Implement code generation
• Document how to add new features and leverage React Server components
• Deployment in production (studio.asyncapi.com)

Out of bounds

What won't be part of the scope

Do not improve the codebase in any way. Do not try to simplify stuff or improve anything. Migrations are complex enough on their own. Keep it simple.

Success criteria

How do we know we made a good bet

• https://github.com/orgs/asyncapi/projects/16/views/5?pane=issue&itemId=24118469

[Shurtu-gal]

https://www.swyx.io/how-to-add-monaco-editor-to-a-next-js-app-ha3

For NextJS with reference to MonacoEditor

[sambhavgupta0705]

IMO nextjs will be the best fit for this.

[Shurtu-gal]

@kaushik-rishi, any opinions regarding this?

[Shurtu-gal]

Below is a summary which I have made:-

Criteria	Next.js	Vite	Remix	Gatsby
Maintenance	Well-maintained	Active community	Growing community	Large and active community
Community	Strong and active	Active contributors	Growing steadily	Large and thriving
Deployment	Compatible with Netlify	Compatible with Netlify	Compatible with Netlify	Compatible with Netlify
Security	Follows best practices	Development-focused	Emphasizes security	Follows best practices
Performance	Optimization features and multiple forms of rendering	Fast development server	Performance-focused	Static site generation
	Automatic code splitting	Lightning-fast module hot-swapping	Server rendering and caching strategies	Highly optimized static sites
API Creation	Built-in API routes	No built-in support	Built-in server routes	Plugin-based integration
TypeScript	Excellent support	Excellent support	Good support	Good support
Monaco Editor	Integration may require additional configuration and setup, but it can be achieved by leveraging Next.js's extensibility.	Integration may require additional configuration and setup, but it can be achieved by leveraging Vite's extensibility.	Remix doesn't have built-in support for Monaco Editor. Integration would require additional configuration and setup.	Gatsby doesn't have built-in support for Monaco Editor. Integration would require additional configuration and setup.

• Next.JS would be the best option as it has server-side rendering, API routes and good support for Monaco Editor.
• Remix also supports API routes, but I found no resources for integrating Monaco Editor.
• Meanwhile, Vite requires a separate backend, and Gatsby requires plugins for API.

Any suggestions would be welcome @fmvilas @sambhavgupta0705 @KhudaDad414 @kaushik-rishi

[fmvilas]

I love it! I have a few questions:

• What's the difference between "Well-maintained" and "Active community"?
• What's the difference between "Strong and active", "Active contributors", "Growing steadily", and "Large and thriving"?

Would it be worth ranking these things clearly? Maybe you can give each of them a 0-5 rank to make it clearer? I also have the feeling that Next.js is the best choice but want to make sure we take a thoughtful decision.

cc @Amzani @magicmatatjahu @peter-rr @Souvikns

[Shurtu-gal]

Criteria	Next.js	Vite	Remix	Gatsby
Maintenance	5	4	4	5
Community	5	4	3	5
Security	5	3	4	5
TypeScript	5	5	4	4
Performance	Optimization features and multiple forms of rendering	Fast development server	Performance-focused	Static site generation
	Automatic code splitting	Lightning-fast module hot-swapping	Server rendering and caching strategies	Highly optimized static sites
API Creation	Built-in API routes	No built-in support	Built-in server routes	Plugin-based integration
Monaco Editor	Integration may require additional configuration and setup, but it can be achieved by leveraging Next.js's extensibility.	Integration may require additional configuration and setup, but it can be achieved by leveraging Vite's extensibility.	Remix doesn't have built-in support for Monaco Editor. Integration would require additional configuration and setup.	Gatsby doesn't have built-in support for Monaco Editor. Integration would require additional configuration and setup.

This is the updated one. I have removed deployment as Netlify has respective plugins for each.

cc: @fmvilas @KhudaDad414 @sambhavgupta0705 @kaushik-rishi @Amzani

[fmvilas]

Awesome! Looks better now. Thanks! Definitely, Next.js sounds like the best option to me too. Once @Amzani has something related to #663, adding an ADR explaining why we chose Next.js and linking to this issue would be awesome.

[Amzani]

@Shurtu-gal now that we have ADR system in place don't hesitate to move this decision to an ADR.
https://github.com/asyncapi/studio#architecture-decision-records
(Some examples here: https://github.com/asyncapi/studio/tree/master/doc/adr)

[Shurtu-gal]

Sure @Amzani, I will do it.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[shapeit-bot]

Thanks for creating a new pitch 🥳. You can now create or link existing scopes.
You can create new scopes in two different ways:

Option 1

1. Edit the Pitch or Bet issue
2. Add your scope under the scope section

See this example

Option 2

1. Create a new issue
2. Add this keywork in the description related to #ISSUE_BET_NUMBER

See this example

[aeworxet]

Bounty Issue's service comment

Text labels: bounty/2024-Q2, bounty/advanced, bounty/coding, bounty/misperformed, bounty/eol
First assignment to third-party contributors: 2024-03-22 00:00:00 UTC+12:00
End Of Life: 2024-08-31 23:59:59 UTC-12:00

@asyncapi/bounty_team

[KhudaDad414]

Progress

• Migration largely complete, core functionality working (excluding known issues - see PR feat: Use Next.js in studio-next #1062).

Remaining Tasks

1. Dockerfile:

   • investigate copying the Dockerfile file from studio and modifying this line:
     

     studio/apps/studio/Dockerfile

     Line 34 in cfbf207

     RUN PUBLIC_URL=${BASE_URL_PLACEHOLDER} npm run build:studio

2. Test Script:

   • Add test script to studio-next.
   • Use Jest instead of Craco test runner.

3. Code Generation:

   • Implement code generation in studio-next.
   • Begin by moving template-parameters.ts from studio to studio-next.

4. CodeMirror Integration:

   • Replace Monaco editor with CodeMirror.
   • PR feat: add editor in next.js #997 can be taken as a point of reference.
   • Complexity uncertain (I have limited experience with both).

I suggest we use these four remaining tasks as the new scope of the bounty issue.

cc: @Amzani @aeworxet

[Shurtu-gal]

@KhudaDad414 regarding code mirror integration this PR #997 can be taken as a point of reference.

[KhudaDad414]

@Shurtu-gal updated the comment. 👍

[aeworxet]

I would like to work on this Bounty Issue.

[aeworxet]

Bounty Issue's Timeline

Complexity Level	Assignment date (by GitHub)	Start date (by BP rules)	End date (by BP rules)	Draft PR submission	Final PR submission	Final PR merge
Advanced	2024-04-26	2024-04-29	2024-06-21	2024-05-17	2024-06-07	2024-06-21

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.

Keep in mind the responsibility for violations of the Timeline.

[Amzani]

For tests what about using Cypress #1091

[aeworxet]

Submitted the Draft PR #1094 branched from #1062 (Cypress included)

[Amzani]

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

[smoya]

I know I'm so late into this party, but I think it will be a good idea if any of the maintainers or involved people clarify the movement to NextJS, considering we moved away from it few years ago. I'm not against it, I just believe it is worth clarifying. Specially about the features we will use from NextJS, e.g. Dynamic rendering?

Thanks! 🙏

cc @Amzani @fmvilas @KhudaDad414

[KhudaDad414]

@smoya We document this kind of decision in the ADR folder: https://github.com/asyncapi/studio/tree/master/doc/adr

[smoya]

@smoya We document this kind of decision in the ADR folder: https://github.com/asyncapi/studio/tree/master/doc/adr

Can't think on a better answer 👏 so nice and well documented. Thanks!

[KhudaDad414]

@smoya it's all thanks to @Amzani ❤️

[aeworxet]

As I understand, there are plans to implement User Registration / Access Control in the future:

https://github.com/asyncapi/studio/blob/master/apps/design-system/src/components/AppCard.stories.tsx#L20

#1094 (comment)

Should the application's state management be rethought because of this in favor of one of the standard solutions?

[KhudaDad414]

@aeworxet yep. currently, we use Zustand and manage the entire state in the browser. at some point, it needs some work.

[aeworxet]

Implementation of the new scope of the Bounty Issue came down to:

• Dockerfile with stubs for the future.
• Cypress with stubs for the future.
• Investigaton that showed that the server's part will at some point MAYBE migrate to CLI. Maybe not.
• Investigaton that showed that the application's state management will be rethought and rewritten in the future, which makes the integration of CodeMirror useless currently.

Thus, this Bounty Issue slowly migrated to an R&D task with half-impelementations as stubs for the future, and there is, in fact, nothing to do on it anymore.

So I propose to reclassify this Bounty Issue to Medium (downgrade), merge PR #1094 and consider this Bounty Issue completed.

[aeworxet]

To be clear, I propose to close only Bounty Issue, leaving the GitHub issue itself open to continue tracking migration.
Just not submit this particular GitHub issue as a Bounty Issue anymore because even with loosened scope it still went beyond Advanced, but create atomic issues and submit as Bounty Issues them.

As an observation, though, I would discourage from submitting as Bounty Issues in the future:

• Backend integration with a third-party service which will increase the duration of each iteration by 24 hours at least due to the necessity of keeping strict control over secret tokens and being in sync with the third-party provider's working schedule, as it has already happened in the case of AsyncAPI Slack/Terraform integration. Backend integration within the internal ecosystem, where all access is controlled internally by AsyncAPI, should be fine.

• Integration of CodeMirror because it requires extensive knowledge of the application's state management, which will unlikely be obtained in one-two weeks by a bystanding developer.

[aeworxet]

@Amzani, still waiting for a decision on this.

I propose to reclassify this Bounty Issue to Medium (downgrade), merge PR #1094 and consider this Bounty Issue completed.

[aeworxet]

Bounty Issue's service comment

@aeworxet receives the First Suspension for misperformance on the Bounty Issue.
With the utmost respect for the contributions made, but also having the best interests of the Bounty Program in mind, @aeworxet will be kept from participation in the Bounty Program from 2024-10-01 00:00:00 UTC+12:00 to 2024-11-30 23:59:59 UTC-12:00 (inclusive.)
AsyncAPI hopes that this pause will provide an opportunity for reflection and perhaps a chance to address any challenges that may have led to this situation.
Reward for this Bounty Issue is not paid to @aeworxet even in the case of its voluntary completion.
Probation period after the First Suspension's expiration will be from 2025-01-01 00:00:00 UTC+12:00 to 2025-05-31 23:59:59 UTC-12:00 (inclusive.)

[jerensl]

What does it mean by Implement code generation, did it already exist as HTML Preview? or does it mean on different feature like Modelina does? or maybe I got it wrong