search

asyncapi / studio

Visually design your AsyncAPI files and event-driven architecture.
https://studio.asyncapi.com
Apache License 2.0
160 stars 98 forks source link

Proposal to remove NextJS #80

Closed magicmatatjahu closed 2 years ago

magicmatatjahu commented 2 years ago

The current studio is written using the NextJS framework. The application consists of several parts (because it's not the plain NextJS app):

The most important part for us is the third part, which is related to the editor and displaying the documentation in various way.

The first part currently exists, but for some reason we can't and don't even want to manage and store data about users, their organizations and the documents themselves. The only thing we would need from the server would be a few endpoints to generate the templates and save it to the user's disk. Just that.

Due to the requirements, the 1st and 2nd part "completely" falls out. That leaves only 3. Personally, I don't see the point of using NextJS where we wouldn't use any of its advantages, i.e. SSR (Server Side Rendering), or SSG (Static Site Generation). Studio should be a frontend application that performs all operations on the client side. Most of our libraries that we currently use (and will use, like diff etc.) in the client-side studio are isomorphic (you can use them client-side and server-side), so that's another reason to remove NextJS. Of course I still see the point of having a server, but for things like using our generator that we can't use on the client side. But under this case, a simple SPA application, which communicates to the simple server setup next to it, is enough for us, without any SSR.

I know that the current studio also has the ability to define plugins, but... they only work properly on the server side. So they only work for the first two parts of the Studio, the Server and the Static UI. You can't change or add new things to the editor itself, because initialization of these plugins is at the Node level, not at the browser level. You can read more about this problem here -> https://github.com/asyncapi/studio/pull/37#issuecomment-843366186

Treating the studio itself like a SPA will additionally allow us to publish this as a simple react component -> https://github.com/asyncapi/asyncapi-react/issues/146

Here I have to sorry all ofyou, because I made a mistake and didn't ask anyone in the community if removing NextJS makes sense. I saw so many problems that I thought I was doing the right thing, but AsyncAPI is a community-driven organization, so I apologize.

What do you think about this? Maybe I'm completely wrong and it makes sense to leave the NextJS.

Also, below is a video that shows what I did while rewriting the studio. It's a pure SPA application.

https://streamable.com/9m607y

github-actions[bot] commented 2 years ago

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.

Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

BOLT04 commented 2 years ago

@magicmatatjahu Seems like a good move 👍. I was wondering about the plugins topic, you mentioned currently it's only allowed plugins server-side. Is this new rewrite going to support plugins client-side? I had a look at Swagger's editor and they seem to have some hooks that other people can use to extend the editor. Is this something we'd want in the design of the new studio?

Also, from what I saw this project uses Redis and a database like you mentioned. Both of those would not be necessary anymore, right?

derberg commented 2 years ago

tl;dr I'm all with you to get rid of SSR

The first part currently exists, but for some reason we can't and don't even want to manage and store data about users, their organizations and the documents themselves

yeah, cause if we do it we basically create a user base and from that point, it is just one step away from running a business, and this is not our plan for the studio. We want to host studio as we do with playground, as AsyncAPI Initiative is part of Linux Foundation, and having a user base would cause legal issues.

anyway, even if we would like to have user base, it doesn't mean we need nextjs with ssr.

Of course I still see the point of having a server, but for things like using our generator that we can't use on the client side. But under this case, a simple SPA application, which communicates to the simple server setup next to it, is enough for us, without any SSR.

We need to support generator with all the templates, so I can, in the UI download generated nodejs template for example. As you wrote though, no need to have SSR for it. We just need a small server (some people call it microservice 😄 ) responsible for that, with single API endpoint and this way, by default, put API as key thing here. Others will be able to use this API without really using the UI.

I know that the current studio also has the ability to define plugins

We need microfrontends here really, as for example in case of generator, somebody might not need it, and don't want to deal with deployment of the API, so they would like to start studio without generator-related component in the UI.

One last thing - Markdown. It is generated with generator in the Playground, next to the HTML. I think we need to agree that Studio should focus in core only on editor + HTML, and Markdown as any other template (even HTML one) should be only available for download, not preview

fmvilas commented 2 years ago

@derberg You now gave the idea of having a Studio REST API. A public API you can use to convert files, download code and docs, etc. 🤔

jonaslagoni commented 2 years ago

@derberg You now gave the idea of having a Studio REST API. A public API you can use to convert files, download code and docs, etc. 🤔

I LIKE THAT! 🤯 Question is, should we build the AsyncAPI API instead of just Studio? Convert files, generate docs, code, relationships, chatbot, optimize documents, differences, etc.

The public CLI for rest or even better for EDA 😆

magicmatatjahu commented 2 years ago

Thanks for all answers (and also hearts 😏 )

@BOLT04

I was wondering about the plugins topic, you mentioned currently it's only allowed plugins server-side. Is this new rewrite going to support plugins client-side? I had a look at Swagger's editor and they seem to have some hooks that other people can use to extend the editor. Is this something we'd want in the design of the new studio?

Yes, we wanna add plugins functionality like in Swagger. Swagger UI and Swagger Editor has something called system which is actually simple DI system for component and redux state/selectors, but it has some limitations. I want to write a proposal today/tomorrow (hopefully) on how such plugins would work for us, so please wait. The plugins should works not only for studio but also for component (https://github.com/asyncapi/asyncapi-react) itself.

Also, from what I saw this project uses Redis and a database like you mentioned. Both of those would not be necessary anymore, right?

Yes, they will be removed, because they collects users data.

@derberg @fmvilas

We need to support generator with all the templates, so I can, in the UI download generated nodejs template for example. As you wrote though, no need to have SSR for it. We just need a small server (some people call it microservice 😄 ) responsible for that, with single API endpoint and this way, by default, put API as key thing here. Others will be able to use this API without really using the UI.

You now gave the idea of having a Studio REST API. A public API you can use to convert files, download code and docs, etc. 🤔

Super idea! Then studio will use this API as the plugin :) We can use the DigitalOcean to host it :)

We need microfrontends here really, as for example in case of generator, somebody might not need it, and don't want to deal with deployment of the API, so they would like to start studio without generator-related component in the UI.

Thanks God that it's Single-SPA, not Luigi 😂 Good idea, but again how would such a microfrontend work and where would it work. We would need to be very specific about where the microntend loads (in the browser DOM meaning). Also microfrontend is good approach when you use on your tech stack several frameworks, but we probably go only with React, so plugins system maybe enough, but we should discuss it in another thread, only related to microfrontends.

One last thing - Markdown. It is generated with generator in the Playground, next to the HTML. I think we need to agree that Studio should focus in core only on editor + HTML, and Markdown as any other template (even HTML one) should be only available for download, not preview

Yes this is limitation (or maybe it's better?). However I made little test and we can render the Markdown template inside browser due to fact that it is rewritten to the JSX tags, but... then template must be pure browser compatible, without any NodeJS libs. Is it worth the effort? 🤷🏼

Also with Fran we had small talk about the Studio and how it can works in the local environment for user. You can image that we can have in our CLI command such a:

asyncapi studio start

and then CLI will start local server with Studio on board which will would read local files with asyncapi specification :) Of course if someone changed the content in the editor the file would be updated, and if someone wanted to use for example Visual Studio Code (another editor, not in the Studio), they could, but they would immediately see the rendered specification and other stuff :)

fmvilas commented 2 years ago

Question is, should we build the AsyncAPI API instead of just Studio?

@jonaslagoni Absolutely! We can include Modelina too. Lots of possibilities.

derberg commented 2 years ago

asyncapi studio start

rather asyncapi start studio to have verb first + long term we can start more things, like chatbot

I LIKE THAT! 🤯 Question is, should we build the AsyncAPI API instead of just Studio? Convert files, generate docs, code, relationships, chatbot, optimize documents, differences, etc.

Super idea! Then studio will use this API as the plugin :) We can use the DigitalOcean to host it :)

Studio + API for stuff that need server and are kinda extra features. We could definitely extend it with more endpoints if through monitoring we actually see people using API directly, cause if not, then let's just keep it for the generator for better architecture, and stuff like conversion or optimization can be done directly in the Studio as most libraries are isomorphic (but they should also be "plugins" so I can gets studio without optimizer if I want)

magicmatatjahu commented 2 years ago

@BOLT04 Hi! There is a mentioned proposal https://github.com/asyncapi/asyncapi-react/issues/433 :)

magicmatatjahu commented 2 years ago

What we agreed on:

AceTheCreator commented 2 years ago

@magicmatatjahu @derberg How do you think the chatbot will benefit from this proposed API perspective?

magicmatatjahu commented 2 years ago

@AceTheCreator It depends. From what he remembers, the chatbot needs a token for this AI service (I don't remember name, sorry). If there is a library that can communicate in the browser, then the chatbot could be implemented just for the browser. As for the server API, you could use a websocket that reads the answers and asks the next question based on it :)

derberg commented 2 years ago

for the chatbot, there is no change really, as chatbot needs its own server with its own API (it already has server anyway), and communication needs to be dynamic between UI and the API. Next.js or not, no change for you.