-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
openapi-editor aka enhanced swagger-editor ? #204
Comments
I like the fact that you start a discussion in an open area to share your idea. For me this is something very important. If I can give you one advise (lesson learned from this project): do not underestimate the energy that is requested when you start a fork: rebranding, code cleanup, build and release engineering. I personally was surprised by everything that was requested to shape OpenAPI Generator and I was glad to see a team contributing to this effort. One the other side, I know that if a project is slowed down this can be really frustrating. This was the case for me working on swagger-codegen v3. I think that the most important factor is the team that you can build around your project. This was a key in the success of OpenAPI Generator. There was a lot of people contributing, testing, giving feedback. This was not a single man thing. Of course the "OpenAPITools" in github could be a new home for your project. I can also mention the "swagger-parser" project where we were able to push our fixes requested by some use cases for OpenAPI-Generator users. We also managed to get a release in time for our release of OpenAPI-Generator. We will see how the relation evolves overtime but for the moment it is good enough to continue without having to fork the project. PS: this is my very personal opinion. I do not know the "swagger-editor" code base and I am pretty new in the Swagger eco-system |
I personally think an editor would ideal. I have plans to begin exposing more details about generators (an effort to improve my Intellij plugin and add "feature" search to CLI). This will begin at the generator level, then would become exposed via CLI and then the online API project. This metadata would be extremely useful from the editor perspective. I think it would be relatively simple to "rebrand" the editor and expose it as a Docker image that includes the online API as a backend. Here, rather than a hosted solution you would have full control and insight into the graphical interface. I also plan, far down the road, to work on a standalone GUI editor and generator. My idea is to investigate how to migrate to native compilation via GraalVM. |
Swagger Editor is a good WebUI (see live in action here) to build and edit a swagger/oas API spec.
It's an important starting point for a new user who approach swagger/oas syntax and concepts. For example, it highlight errors and let you generate and download a client/server in one click without using any CLI.
Unfortunately, as similar happened for swagger-codgen, community improvements and in general development was in some manner slowed down.
For example swagger-api/swagger-editor#713 and swagger-api/swagger-editor#1480
I think we have enough energy, as we are having success in doing openapi-generator, to fork it and improve without the frictions we could have proposing PRs to original project.
For me, this can be a valid idea if we find at least 5 improvements to do.
What do you think?
The text was updated successfully, but these errors were encountered: