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

openapi-editor aka enhanced swagger-editor ? #204

Open
emilianobonassi opened this issue Jun 2, 2018 · 2 comments
Open

openapi-editor aka enhanced swagger-editor ? #204

emilianobonassi opened this issue Jun 2, 2018 · 2 comments

Comments

@emilianobonassi
Copy link
Contributor

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?

@jmini
Copy link
Member

jmini commented Jun 2, 2018

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.
Personally I prefer when people work together on an open-source project regardless of the company or of the interests. Sadly it is not always possible.

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

@jimschubert
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants