Connexion-like functionality

[rgreinho]

First check

• I added a very descriptive title to this issue.
• I used the GitHub search to find a similar issue and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.
• After submitting this, I commit to one of:
  • Read open issues with questions until I find 2 issues where I can help someone and add a comment to help there.
  • I already hit the "watch" button in this repository to receive notifications and I commit to help at least 2 people that ask questions in the future.
  • Implement a Pull Request for a confirmed bug.

Question

We are developing all our APIs by starting from the OpenAPI specification (instead of just using it as documentation) as described by the Zalando guidelines.

Therefore we are using their connexion framework, which validates the OpenAPI specification, generates the routes and performs the data validation automatically for us. Unfortunately they stopped maintaining it, so we are looking for alternatives.

After researching, we haven't found anything like that in the FastAPI ecosystem, but we were wondering whether we just missed something and this feature is available somehow? Or is there a generator that we could use to create our API servers from the specification?

[Halkcyon]

There isn't really anything like that for FastAPI yet. FastAPI works in the opposite direction, creating your OpenAPI document from your implementation instead so they're never out of sync.

I personally use unit tests to retrieve the spec for documentation purposes; you can find it at the /openapi.json route.

[Kludex]

This https://pypi.org/project/fastapi-code-generator/ ?

[rgreinho]

@Halkcyon I see. Well, as described in the document I linked, we believe in the design first approach, that why we chose Connexion, so that the API always reflects the specification we defined.

@Kludex yes, that one way. We found a couple like this one, but the fact that it says "This project is an experimental phase." does not bring us enough confidence to use it in production.

[chbndrhnns]

we believe in the design first approach, that why we chose Connexion,

It's seems obvious to me that, based on beliefs, FastAPI would be a bad choice because you would have to change your worflow in order to use it.

Given the prototyping speed that FastAPI makes possible, it might still be worth a try to design the API in plain Python with FastAPI, instead.

[koxudaxi]

@rgreinho
I'm the author of the fastapi-code-generator. Thank you for checking the project.
Yes, It's the experimental phase. It may not cover all use-case.
But, I use the code-generator for few productions. And I will develop the code-generator continue.

Also,the code-generator uses datamodel-code-generator to generate pydantic model. It support complex OpenAPI models.

Given the prototyping speed that FastAPI makes possible, it might still be worth a try to design the API in plain Python with FastAPI, instead.

I agree.
I develop some production projects by two workflows that are started from OpenAPI or FastAPI implementation.
If a project needs a lot of complex models and the client-side team and server-side team develop at the same time then, I feel good to write OpenAPI first.
I recommend to choose the workflows depends on the project.

[rgreinho]

@koxudaxi Very cool! Thanks for sharing the details! We'll have a deeper look at your tools 👍

We are currently using a combination OpenAlchemy, SqlAlchemy and Alembic to manage our models and database migrations directly from the specification. We hope to be able to keep this workflow, or at least a very similar one.

[koxudaxi]

@rgreinho
I welcome your feedback and PRs on the project.
I want to improve the project. 😄

[TiemenSch]

I'm currently investigating alternatives after Connexion, too. Having a reference document really helps when cooperating with other departments/codebases.

Could we devise some method to compare the FastAPI (generated) OpenAPI spec with a reference file?

That way you can still check whether the FastAPI conforms to the reference spec (or to what extent you've implemented it in Python).

[nicop311]

Hi guys 👋, this might not help this discussion, but I add my story here.
I was brought to zalando/connexion and the API First approach thanks to the swagger-codegenerator feature. I found the API First idea very interesting.

But I was disappointed with the fact that the python flask + connexion server stub from the swagger-codegenerator was not using SQLAlchemy/ORM (I still don't understand their models).

Then I stopped using swagger-codegenerator and use a combination of flask + connexion + SQLAlchemy instead. But I do have issues with ORM and DB and Flask Factory. (I did not know openapi-sqlalchemy at the time).

Then I understood that connexion is trying to find new maintainers/contributors, because the project is less active than before ; see 1365 and this comment.

Then I heard about FastAPI which seems to be trendy, but my nice openapi.yaml file becomes (almost) useless unless I use a codegen tool.

Anyway my conclusion: it seems that the API first approach is not the current trend or not the current focus of people, at least for python. And I should not seek this goal of API first as it is not reliable in the long term (at least for python).

Related issues on swagger-codegenerator

• How to properly initialize Connexion and SQLAlchemy in Flask generated main.py #7307
• [python] Adding support for python FastAPI as server stub and SQLAlchemy ORM #11160

[zupo]

For what it's worth, I subscribe to the specs first approach too, and it's the main reason why I wrote https://github.com/pylons/pyramid_openapi3.

I keep checking out FastAPI every few months, every time hoping to find that the spec first approach is now possible. If no one else beats me to it, I might write it one day, as I love everything else about FastAPI.

[sherifnada]

seems related to #5557

[sherifnada]

Added an implementation suggestion in this issue OpenAPITools/openapi-generator#13863 would love any feedback or opinions

[tiangolo]

Thanks for the discussion everyone!

Yep, FastAPI is a different thing and different "philosophy".

One of the main ideas in FastAPI is to have great developer experience, with autocompletion and inline errors for everything, to have much more confidence in the correctness of the code. It's also designed so that you can do the minimum effort and get everything by default from the same simple standard type annotations.

Having a schema-first approach would mean that the code would have to be very dynamic, without type annotations, that means you wouldn't get autocompletion nor inline errors.

FastAPI is designed around OpenAPI, and the intended workflow is that you would start in your code, with standard type annotations, and from that generate the OpenAPI that would be used by others.

And if you need to prototype quickly before implementing the actual backend code but have the data types in place early, I still find it faster to write those prototypes in Python with editor support, even if you don't implement the internals. Just that the same prototype code ends up being the same production code down the line 😅

The closets to that approach in FastAPI would be code generation, as with @koxudaxi.

But if you don't want to have generated Python code and you still want to start from the schema, FastAPI might not be the right tool for you. I mean, you can certainly use it for that, but it was not designed to solve that use case.

If there was something based on the schema that did all the work dynamically in code (without type annotations involved) it would probably be based on Starlette directly and not FastAPI.

Anyway, just my two cents.

[github-actions[bot]]

Assuming the original need was handled, this will be automatically closed now. But feel free to add more comments or create new issues or PRs.