You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have only recently starting learning about Connexion and so far I love it, but there are two things that I'm missing:
some way to automatically check/test/verify that my functions that implement the API operations actually accept and return what they're supposed to,
some way to help my IDE figure out what the functions should accept and return, so the IDE can help me write correct code. (I currently use PyCharm and like it.)
I was thinking, even though I like the one-step build process and generally try to avoid introducing the need for generated code, in this case perhaps generating a module with data classes corresponding to the types defined in the schema would solve both?
The text was updated successfully, but these errors were encountered:
make a script that takes my OpenAPI spec and generates the data model expressed using dataclasses and Enums
make a decorator for my API functions that inspects the type annotations and then uses dacite.from_dict to convert the body from dict to the correct dataclass and the enum strings into actual Enums, calls the API function, and then uses dataclasses.asdict to convert the returned dataclass to dict
So then my API implementation never has to deal with the raw dicts: it accepts and returns dataclasses, mypy and pylint checks my types and does static analysis and an IDE can give me hints.
Now that I think about it, I think I basically achieved what FastAPI is doing, just using dacite instead of pydantic, the difference being that FastAPI generates a spec from code while I generate code from spec.
I suspect it might be too specific to the way I write my API spec (and also not very clean code TBH) but if there's interest, I suppose I could offer it up to the community.
I have only recently starting learning about Connexion and so far I love it, but there are two things that I'm missing:
I was thinking, even though I like the one-step build process and generally try to avoid introducing the need for generated code, in this case perhaps generating a module with data classes corresponding to the types defined in the schema would solve both?
The text was updated successfully, but these errors were encountered: