I have:
- a library that does [Stuff]
- a swagger API definition, which is roughly #1 with minor differences to map cleanly to a REST service
- a flask app generated #2 using Swagger-Codegen - eg results in python controller functions roughly one-to-one with #1.
My intent is that the flask app (all generated code) should only handle mapping that actual REST api and parameter parsing to match the API spec coded in swagger. After any parameter parsing (again, generated code) it should call directly over to my (non-generated) backend.
My question is, how best to hook these up withOUT hand-editing the generated python/flask code? (Feedback on my design, or details of a formal design pattern that accomplishes this would be great too; I'm new to this space).
Fresh from the generator, I end up with python functions like:
def create_task(myTaskDefinition):
"""
comment as specified in swagger.json
:param myTaskDefinition: json blah blah blah
:type myTaskDefinition: dict | bytes
:rtype: ApiResponse
"""
if connexion.request.is_json:
myTaskDefinition = MyTaskTypeFromSwagger.from_dict(connexion.request.get_json())
return 'do some magic!' # swagger codegen inserts this string :)
On the backend I have my actual logic:
def create_task_backend(myTaskDefinition):
# hand-coded, checked into git: do all the things
return APIResponse(...)
What is the right way to get create_task()
to call create_task_backend()
?
Of course if I make breaking changes to my swagger spec I will have to hand-update the non-generated code regardless; however there are many reasons I may want to re-generate my API (say, add/refine the MyTaskTypeFromSwagger
class, or skip checking into git the generated code at all) and if I have to hand-edit the generated API code, then all those edits are blown away with each re-generation.
Of course I could script this with a ~simple grammar in eg. pyparsing; but while this is my first time with this issue, it seems likely it's been widely solved already!
I was tempted to use
swagger-codegen
before and ran into the same conundrum. Everything is fine until you update the spec. Although you can use custom templates, this just seemed like a lot of overhead and maintenance, when all I want is a design first API.I ended up using connexion instead, which uses the swagger specification to automatically handle routing, marshaling, validation, etc. Connexion is built on flask, so you would not need to worry about switching frameworks or anything, you will just get the benefit of portions of your application being automatically handled from swagger instead of having to maintain auto-generated code.
The workflow I came to.
The idea is to generate the code, then extract
swagger_server
package to the project directory. But separately, keep controllers your are coding in the separate directory or (as I do) in the project root and merge them with generated ones after each generations usinggit merge-files
. Then you need to inject your fresh controllers code intoswagger_server/controllers
, i.e. before starting server.So the workflow is the following:
swagger_server
to your project directory, completely overwrite existingcontroller.py
andcontroller.py.common
from project rootgit merge-file controller.py controller.py.common swagger_server/controllers/controller.py
swagger_server/controllers/controller.py
new common ancestor so copy it tocontroller.py.common
, overwrite existingFeel free to automate all of this with shell script, i.e.
For now I am working around this by doing the build in these steps
'do some magic'
(thats the string all the generated controller endpoints return) they simply call a corresponding function in my 'backend'git format-patch
to make a patch of the preceeding changes, so that when i re-generated code the build can automatically apply the changes.Thus, i can add new endpoints and I only have to hand-code the calls to my backend ~once. Instead of using patch files, i could do this directly by writing a py-parsing grammar for the generated code and using the parsed generated code to create the calls to my backend ... that would take longer so I did this all as a quick hack.
This is far from optimal, i'm not going to mark this as accepted as I'm hoping someone will offer a real solution.
Use connexion as @MrName suggested.
I first started using this together with codegen.
openapi-generator generate -i ../myapi.yaml -g python-flask -o .
This generates a directory with the openapi server.
If you add tags to your paths in the api spec, then a separate tagname-controller.py is created for each tag. For each operationId a function is generated.
However, once this is set up, connexion can handle updates to the api spec. If I add a new path to openapi/my-api.yaml, with an operationId=new_func, then I can add new_func() to the existing controller. I don't lose the existing server logic (but I would still back it up before just in case). I haven't tried radical changes to existing paths yet.
The following approach worked for me:
created three directories:
src
- for my code,src-gen
for the swagger generated code,codegen
in which I have put a script that generate the server along with a few tricks.I copied all the templates (available in the swagger build) to
codegen/templates
and edited thecontroller.mustache
to refer tosrc/server_impl
, so it can use my own code. The editing uses the template language so it is generic. Still it is not perfect (I would change a few naming conventions) but it does the job. So, first add tocontroller.mustache
:then add instead of
return 'do some magic!'
the following:src
has aserver_impl
directory.server_impl
can be imported as a python module