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

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

Open
Kilo59 opened this issue Jul 25, 2024 · 4 comments
Open

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

Kilo59 opened this issue Jul 25, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@Kilo59
Copy link
Contributor

Kilo59 commented Jul 25, 2024

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.

@Kilo59 Kilo59 added the enhancement New feature or request label Jul 25, 2024
@zmievsa
Copy link
Owner

zmievsa commented Jul 25, 2024

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?

@zmievsa zmievsa self-assigned this Jul 25, 2024
@Kilo59
Copy link
Contributor Author

Kilo59 commented Sep 3, 2024

@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
Loading

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
Loading

@zmievsa
Copy link
Owner

zmievsa commented Sep 3, 2024

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
Copy link
Owner

zmievsa commented Sep 6, 2024

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

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

No branches or pull requests

2 participants