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

Support for OpenApi Generator's graceful generator? #61

Open
anlcnydn opened this issue Jan 20, 2019 · 1 comment
Open

Support for OpenApi Generator's graceful generator? #61

anlcnydn opened this issue Jan 20, 2019 · 1 comment

Comments

@anlcnydn
Copy link
Contributor

anlcnydn commented Jan 20, 2019

While, I have been searching around contract-first development approach, I encountered OpenApi Generator. Basically, it can create client and server boilerplate codes for a given api spec. After generation process, only thing that needs to be done is implement the controller methods themselves.

Do we think of contributing to OpenApi Generator project for a new generator of graceful?

I did not analyze it deeply, but what I understand after a quick look is that, it can be pretty straightforward to generate serializers and controllers, as their structure will already be defined in the contract.

This may move the developer experience of graceful to an another level?

What do you guys think about it? Is it worth to give a shot?

Cheers.

@swistakm
Copy link
Owner

I really don't know. I'm not convinced to code generators of that type so probably won't dedicate any time for this. But if someone has energy and time to do this kind of contribution I'm willing to help with suggestions like typical application layout or accept contributions to the codebase of graceful if something like that is required.

To be honest I was already thinking about something completely opposite. I wanted to replace internal documentation format returned on OPTIONS handler with OpenAPI compliant documentation generator.

During last year I didn't use graceful that much and instead experimented with different tools (pact, redoc), libraries (marshmallow), frameworks (aiohttp) and standards (OpenAPI, API Blueprint, JSON API) to better understand how this project should further evolve and whether there's a place for it in Python web services ecosystem. Now I'm pretty sure that Open API is a must.

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

No branches or pull requests

2 participants