Replies: 17 comments
-
I'm for it too, as stated in #71 In the meantime, check this out. It might be what you looking for. https://github.com/szczepanmasny/vue-crud Simple CRUD demo pd: this is mostly frontend. it is needed anyways. |
Beta Was this translation helpful? Give feedback.
-
Maybe you're talking about |
Beta Was this translation helpful? Give feedback.
-
No, I'm not talking about requests LOL :) I'm talking about something like bravado, but with support for:
|
Beta Was this translation helpful? Give feedback.
-
That's a very interesting idea. In fact, I think is a good idea for a new package. Bravado seems cool, although as it has to infer and create new methods live from a schema, it doesn't have code generation, so, it can't have completion or type checking. I think something very interesting to build would be a package that can read an OpenAPI, generate Pydantic classes for the JSON Schemas and generate requests code for the path operations. That would be great. There are already some code generation tools, but I think they are wrote in Java or something, and the resulting Python code is too verbose. It would be nice to have something that generates these things automatically, and that the generated code is as clean and maintainable as if it was written by hand. Let's see if someone else finds a tool like that (or gets inspiration from this issue to build one 😁 ). |
Beta Was this translation helpful? Give feedback.
-
Would you commit autogenerated code to git? Or just generate it in dev / docker build in such place that code can import it? From your experience with Pydantic, do you think implementing JSON Schemas to Pydantic classes conversion will be a straight-forward task? I guess Path->Python code can be borrowed/inspired by what Bravado does. P.S. Indeed it will be a new package :) |
Beta Was this translation helpful? Give feedback.
-
If the code is as simple enough or comparable to what a developer would write, yes. For example, I wouldn't add compiled/minified JS code to git. If it was a client that has type declarations, functions, etc, that the whole team can re-use, I would probably commit it. And when the API changes, the client could change, but the changes would be minimal, only in the sections that reflect those changes. But if the client was a binary, or minified JS, the whole thing would change, I wouldn't commit that. But here we're talking about Python, so, probably yes.
I think most of the JSON Schema cases (the simplest cases) should be more or less straightforward, the most complex/esoteric cases could be difficult or problematic, but I wouldn't expect a lot of those.
Yep, most probably yes. The only/main part missing would be actually generating the code. |
Beta Was this translation helpful? Give feedback.
-
Any particular code-generation tools that you can think of here? |
Beta Was this translation helpful? Give feedback.
-
Related: Yelp/bravado#306 (comment) |
Beta Was this translation helpful? Give feedback.
-
Related!! pydantic/pydantic#643 |
Beta Was this translation helpful? Give feedback.
-
@tiangolo @haizaar While openapi-generator is written in Java, the vast majority of the code generation work is handled by the mustache templates; given the number of existing openapi-generator python client generators, I would expect a pydantic-models/fastapi-friendly generator could be created with minimal effort -- in particular, I suspect it would require zero changes to the java code if all you wanted was to generate pydantic models from an openapi spec. And given that you can specify templates to use at generation time, this would mean it would be usable against the existing release of openapi-generator. (It also wouldn't surprise me if an existing generator could be fully adapted into a full-fledged pydantic+requests client with only changes to the template files.) While I agree that many of the existing openapi-generator client libraries are currently rather verbose (I haven't looked specifically at the python ones, but the description fits the ones I have seen), I think that is more a reflection of the implementation than of openapi-generator's capabilities. I am currently using a heavily streamlined client with my FastAPI server (in a non-python language) which was produced only by changing the templates of one of the existing clients. In general, I would expect an approach leveraging openapi-generator to require substantially less initial effort and on-going maintenance. Would this be of interest? I would be happy to put some effort into it, but I would rather not if there is a separate serious effort to build this feature directly into pydantic/fastapi (pydantic/pydantic#643) |
Beta Was this translation helpful? Give feedback.
-
@tiangolo @haizaar @dmontagu However, I think it's essential to decide what do we create FastAPI controller template before implement. If we want a simple server template(like a tutorial), then we can create a code generator right now :) @dmontagu |
Beta Was this translation helpful? Give feedback.
-
Very interesting insights @dmontagu and @koxudaxi ! Also, let me copy some my comment in that PR here: I started a local experiment to generate Pydantic models from JSON Schema, using Jinja2 templates, and used in a recent project. I'm still not generating models that reference other models. But I realized that probably a better approach would be to have two separated features (or packages if not suitable for Pydantic?):
from pydantic import BaseModel, Schema
class SomeDynamicModel(BaseModel):
some_str_field: str
some_int_field: int = Schema(..., title="Some title")
The two features combined would result in being able to generate Pydantic models from JSON Schema. But the separated components could be extended to, e.g.:
I'm just brainstorming here, but some of these ideas might be useful in case someone ( 😉 @koxudaxi ) implements it before me... |
Beta Was this translation helpful? Give feedback.
-
I created a client generator mostly leveraging openapi-generator here. All models are pydantic You can use it to generate a client for your own API by just pointing it at your I haven't been able to test it much yet (but hopefully will be stress testing it in the next few days..), and so it probably has plenty of bugs still, but it's a start! Let me know if you have any thoughts. |
Beta Was this translation helpful? Give feedback.
-
@dmontagu I want to create code-generator for a client. but, I have not started to develop it yet :( I'm developing datamodel-code-generator which create pydantic models source code from openapi file. Next, I will create server/client code-generator for fastapi :) |
Beta Was this translation helpful? Give feedback.
-
I think @dmontagu 's fastapi_client and @koxudaxi 's datamodel-code-generator probably solve this use case, right @haizaar ? May we close this issue? |
Beta Was this translation helpful? Give feedback.
-
@tiangolo yeap, although I'm not involved with FastAPI anymore (changed hats) but briefly looking at both fastapi_client and datamodel-code-generator I like them both. |
Beta Was this translation helpful? Give feedback.
-
Hi All New to FastApi, while working with the lib I was wondering if there is a way to create python client API nicely, e.g. in such a way that would not require either the generation of code or the generation of a new client. I came across fastapi_client and I was not satisfied. It requires a "SYNC" and dose not have context sensitive help (AFAIK). I want my users to just "install a package" and get the full functionality plus the advantage of context sensitive help (even if the package contains the original python api code). So I came up with the below code pattern that may work and uses the current signature of the decorators. I also created a dummy PR #11342 that shows how this may be implemented (dummy since it has no testing or anything just the basic idea). In short, I created a "catch" within the I also added a discussion #11343 here before I saw this thread. I note that in this use case, the api should be separated into versions, e.g. api/v1, api/v2.. etc to allow the signature of the api to change over time. But since this is a good practice anyways... Usage example: from fastapi import FastAPI, FastAPIClient
from fastapi.routing import APIRoute
class MyApiClient(FastAPIClient):
# Client paramters to be added here.
# But this dose nothing, We could implement a default api client.
def __init__(self, host: str = "localhost:8080") -> None:
super().__init__()
def send(self, route: APIRoute, args: list, kwargs: dict):
# Send the request given the route.
# Dummy just returns the route and input values
return route, args, kwargs
async def send_async(self, route: APIRoute, args: list, kwargs: dict):
# Send the aysnc request given the route.
# Dummy just returns the route and input values
return route, args, kwargs
api = FastAPI()
@api.get("/my_func")
def my_func(a, b):
return a + b
client = MyApiClient()
# a call will be made to my_func.
print(my_func(2, 3))
with client:
# A call will be made to the server, returning
# the proper response.
print(my_func(2, 3))
# a call will be made to my_func.
print(my_func(2, 3)) |
Beta Was this translation helpful? Give feedback.
-
Description
Does anyone know a library that can consume a swagger file and provide nice interface for interacting with the API (something similar what suds did for SOAP) ? I'm particularly after auto-generated Pydantic definitions of swagger request/response objects.
I know this is not directly FastAPI related, but since all people here use FastAPI to create awesome APIs I think there is good chance you use similarly-awesome tools to consume those APIs.
Thanks in advance,
Zaar
Beta Was this translation helpful? Give feedback.
All reactions