Live data from Hacker News

Types for Python HTTP APIs

instagram-engineering.com

41–50 of 55 posts

Re: Types for Python HTTP APIs

#41
Rather than reimplementing this stuff, and assuming you are using Django, you could just use Django Rest Framework to get OpenAPI, typed serializers, etc.

In that framework your serializers are by default auto-generated from your model classes; this is convenient to get started, just like Django itself.

Re: Types for Python HTTP APIs

#42
post #11

Earlier quoted context omitted.

Yeah I feel FastAPI will become the new Flask in a few years. The growth this year has been amazing. I wish I had started my project with it, but I am still using Flask. I found this nice extension though called Flask-Rebar that does a similar task with Marshmallow.

Yeah I feel FastAPI will become the new Flask in a few years. What else does it offers besides performance (switching to async is no free lunch)?

Depends on where you are coming from and what you need. Developer productivity is really high (real world experience). It has better defaults / builtins compared to flask (much faster to get to production quality). Faster to learn than Django / Django rest framework. My team has been using it for a couple of months now and it’s been really easy and fast to get an API up and running with api docs, data validation, middleware for auth and metrics, persistence, mix of async and sync functions and background jobs.

Re: Types for Python HTTP APIs

#43

Earlier quoted context omitted.

Yeah I feel FastAPI will become the new Flask in a few years. What else does it offers besides performance (switching to async is no free lunch)?

I ran across FastAPI earlier this year and did a tiny prototype to play with it. Selling points for me: - Integrates nicely with some existing libraries (Starlette, Pydantic) - Well documented - Auto-validation of endpoints from data models - Auto-generation of OpenAPI schemas from those models - Auto-serves live API docs from that schema - Easy definition of sync and async endpoints Again, it was just a tiny proof-o…

But I found one drawback of using FastAPI - defining all inputs in handler function signature is looks bit complicated and verbose. I prefer one input with type that are structure of another types. Something like this:

  class CreatePostInput(InputClass):
       text: str
       user_id: str
       ...
  
  @handler.post('/post')
  def create_post(input: CreatePostInput):
      ...

Re: Types for Python HTTP APIs

#44
No one is mentioning that Instagram app which doesn’t have that many features, and is quite poorly designed, somehow requires over 2000 API calls to function.

I would dare anyone come up with even 100 for the Instagram app.

Re: Types for Python HTTP APIs

#45
post #21

Earlier quoted context omitted.

Can you elaborate on this? I’d love to actually use types in Python.

Python 3 has optional static typing: https://docs.python.org/3/library/typing.html https://realpython.com/python-type-checking/

Static typing is exactly what python doesn't have. It will remain dynamically typed. It has type hints which can be used with external tools to enforce type correctness to some degree, but python code will run even if you assign:

    def f(x: int):
        x = "str"
    f(42)

Re: Types for Python HTTP APIs

#46
post #40

Earlier quoted context omitted.

I ran across FastAPI earlier this year and did a tiny prototype to play with it. Selling points for me: - Integrates nicely with some existing libraries (Starlette, Pydantic) - Well documented - Auto-validation of endpoints from data models - Auto-generation of OpenAPI schemas from those models - Auto-serves live API docs from that schema - Easy definition of sync and async endpoints Again, it was just a tiny proof-o…

> - Auto-generation of OpenAPI schemas from those models Is there a package that can do a reverse? Can I give it an OpenAPI spec and get a code stump going?

https://github.com/zalando/connexion/

Solves most of the problems for that.

Re: Types for Python HTTP APIs

#47

Been doing this before the typing module was released, using hug: http://www.hug.rest/ FastAPI has a lot of advantages at this point for someone looking to do the same: https://github.com/tiangolo/fastapi hug has some catching up to do, some of it just because it got in so early (It needs to be updated to be compatible with mypy and the types defined typing.py!) in any case using typing on API endpoints - independent…

Thanks for the mention @timothycrosley! I feel honored :)

Re: Types for Python HTTP APIs

#48
post #40

Earlier quoted context omitted.

I ran across FastAPI earlier this year and did a tiny prototype to play with it. Selling points for me: - Integrates nicely with some existing libraries (Starlette, Pydantic) - Well documented - Auto-validation of endpoints from data models - Auto-generation of OpenAPI schemas from those models - Auto-serves live API docs from that schema - Easy definition of sync and async endpoints Again, it was just a tiny proof-o…

> - Auto-generation of OpenAPI schemas from those models Is there a package that can do a reverse? Can I give it an OpenAPI spec and get a code stump going?

OpenAPI-generator [0], written in Java, can produce Python stumps, but I never liked that approach.

Connexion [1] is built on top on Flask and does routing and validation based on an OpenAPI spec.

I've recently started developing Pyotr [2], which does the same only based on ASGI and Starlette. It also includes a client module.

[0] https://openapi-generator.tech/

[1] https://connexion.readthedocs.io/

[2] https://github.com/berislavlopac/pyotr

Re: Types for Python HTTP APIs

#49
I'm always amazed that, in majority of cases, we use formal specifications -- like OpenAPI -- for documentation instead to guide our implementations. The common pattern is to build an API first, and then extract routing and validation information into an OpenAPI spec, which is then used to set up a test server for clients to develop on top on.

But if you have a relatively clear idea of what your API should look like, there are great benefits to be gained by providing the specification first. This way, you don't need for the API to be implemented to start developing the clients, even by completely unrelated teams. Second, your spec will already include your routing and validation rules, and there is no need to manually specify e.g. Pydantic models.

I recently wrote a PoC of a framework [0] that uses the OpenAPI spec to easily implement a REST(ful) API; in a nutshell, you need to implement endpoint functions that correspond to the spec's `operationId` names, and it will automatically route a request to the right endpoint. It is fully ASGI compliant and as has a bonus client module, which allows you to do the requests.

[0] https://github.com/berislavlopac/pyotr

Re: Types for Python HTTP APIs

#50
I love types and I’m stoked about them coming back into style. For awhile, it was a major trend to avoid static types. I think most people’s problem ended up not being with types themselves- but poor type systems. For myself, I am particularly impressed with what TypeScript has done with its types, really amazing how expressive/flexible/and inspective it is. Anyways, just happy with the trend of embracing types and hopes it continues.
Post reply on HN