search

zmievsa / cadwyn

Production-ready community-driven modern Stripe-like API versioning in FastAPI
https://docs.cadwyn.dev/
MIT License
199 stars 27 forks source link

Make Cadwyn useable purely for schema versioning (sans FastAPI) #203

Open Kilo59 opened 1 month ago

Kilo59 commented 1 month ago

Is your feature request related to a problem? Please describe.

I would like to be able to use cadwyn without FastAPI.

Describe the solution you'd like

I can define schema versions and migrations for my Pydantic models, without requiring me to use FastAPI.

zmievsa commented 1 month ago

Hi! I have exposed the internal interface for schema generation in 4.1.0 and added a small code snipped about it to the docs:

https://docs.cadwyn.dev/concepts/schema_generation/#generating-schemas-without-fastapi

FastAPI will still be in your requirements but it's quite small compared to pydantic 2. Would this solve your problem?

Kilo59 commented 4 days ago

@zmievsa Sorry for the late response. This will be useful on its own but ideally, we wouldn't need FastAPI as a dependency at all.

I have separate client + server packages, each hosted in a different repo with different dependencies.

The server package has 2 versions of an API one of which IS fastapi but the other is flask. This change should allow me to use cadwyn between a Flask and FastAPI version of my API but it doesn't help my client-side package.

graph TD
    Flask:api-v0<-->client-v0
    FastAPI:api-v1<-->client-v1

The client library is an opensource application that only needs to integrate with the server when users are using our paid SaaS product, otherwise everything happens locally (against local configuration files or in-memory).

Ideally, I'd like to use cadywn to translate between versions of the non-SaaS mode of the client library without relying on server-side translations.

graph TD
    Flask:SaaS-v0<-->client-v0
    FastAPI:SaaS-v1<-->client-v1
    local:<-->client-v0
    local:<-->client-v1
zmievsa commented 4 days ago

It's probably a ton of work but honestly: your use case is inspiring.

Let me dig into this and see what approach we could use. One thing I worry about is making Cadwyn harder to evolve or breaking compatibility for old clients.

zmievsa commented 2 days ago

I tried a few ways but all of them have either made Cadwyn harder to start with (+ added breaking changes) or made Cadwyn significantly harder to support.

However, I have looked at how big each dependency is and how much FastAPI adds. FastAPI and all of its dependencies take about 13% of all external dependencies in a clean venv. So even though fastapi adds extra dependencies, it adds very little size to your venv and will not slow down your code.

The statistics: 14M pip 5.2M pydantic_core 4.0M setuptools 3.2M pydantic 2.8M tzdata 1.2M fastapi 996K jinja2 836K anyio 704K idna 624K starlette 440K cadwyn 104K exceptiongroup 96K markupsafe 52K sniffio