Open fmvilas opened 1 year ago
https://www.swyx.io/how-to-add-monaco-editor-to-a-next-js-app-ha3
For NextJS with reference to MonacoEditor
IMO nextjs will be the best fit for this.
@kaushik-rishi, any opinions regarding this?
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. |
Any suggestions would be welcome @fmvilas @sambhavgupta0705 @KhudaDad414 @kaushik-rishi
I love it! I have a few questions:
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
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
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.
@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)
Sure @Amzani, I will do it.
This issue has been automatically marked as stale because it has not had recent activity :sleeping:
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 :heart:
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
See this example
Option 2
related to #ISSUE_BET_NUMBER
See this example
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
Progress
Remaining Tasks
Dockerfile:
studio
and modifying this line:Test Script:
studio-next
.Code Generation:
studio-next
.studio
to studio-next
.CodeMirror Integration:
I suggest we use these four remaining tasks as the new scope of the bounty issue.
cc: @Amzani @aeworxet
@KhudaDad414 regarding code mirror integration this PR https://github.com/asyncapi/studio/pull/997 can be taken as a point of reference.
@Shurtu-gal updated the comment. 👍
I would like to work on this Bounty Issue.
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 |
For tests what about using Cypress https://github.com/asyncapi/studio/issues/1091
Submitted the Draft PR https://github.com/asyncapi/studio/pull/1094 branched from https://github.com/asyncapi/studio/pull/1062 (Cypress included)
I would remove CodeMirror Integration from the scope of this issue for now, until we merge everything.
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
@smoya We document this kind of decision in the ADR folder: https://github.com/asyncapi/studio/tree/master/doc/adr
@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!
@smoya it's all thanks to @Amzani ❤️
As I understand, there are plans to implement User Registration / Access Control in the future:
https://github.com/asyncapi/studio/pull/1094#issuecomment-2144702536
Should the application's state management be rethought because of this in favor of one of the standard solutions?
@aeworxet yep. currently, we use Zustand and manage the entire state in the browser. at some point, it needs some work.
Implementation of the new scope of the Bounty Issue came down to:
Dockerfile
with stubs for the future.Cypress
with stubs for the future.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 https://github.com/asyncapi/studio/pull/1094 and consider this Bounty Issue completed.
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.
@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 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.)
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
Studio
is now a Next.js app.
https://github.com/asyncapi/studio/pull/1141
Problem
CRA (create-react-app) is dead. They're gonna replace it with a launcher where you can select a framework.
Solution
That said, we should evaluate a framework and bet on it (no pun intended 😄). Things we need to take into account at first sight:
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:
Learn more here: https://react.dev/learn/start-a-new-react-project#production-grade-react-frameworks.
Rabbit holes
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
Out of bounds
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