Hacker News Reader

Hacker News

Comment by rattray | Hacker News Reader

Parent Full thread

rattray

This is a Python framework claiming Node/Go-comparable perf.

Here's what it looks like:

from typing import Optional

from fastapi import FastAPI from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel): name: str price: float is_offer: Optional[bool] = None

@app.get("/") def read_root(): return {"Hello": "World"}

@app.get("/items/{item_id}") def read_item(item_id: int, q: Optional[str] = None): return {"item_id": item_id, "q": q}

@app.put("/items/{item_id}") def update_item(item_id: int, item: Item): return {"item_name": item.name, "item_id": item_id}

That can get you an autogenerated openapi spec and docs, which IMO is pretty awesome.

Can anyone comment on how it compares to Django Rest Framework? (Other than presumably being faster)

View on HN

We have been migrating a project from DRF to FastAPI, and its a massive performance improvement. Which was what we were needing. Unfortunately our data was just not well handled by DRF, and serialization from PG > Python > JSON was absolute horrendous. So we love the speed we are getting with FastAPI.

Now you do lose a lot of things. There is no more Django ORM, so we are back to using SQLAlchemy. I don't think this is bad, but definitely different.

You also have to write a lot more specs, and such. Which can be annoying, but not too bad.

It also encouraged us to go over to type hints on the whole code base and has save from a few bugs as well.

Overall we really like it, not sure I will go back to DRF on any future big projects. Still handy for something quick, but not what I want to be using moving forward.

OP has a pretty interesting writeup about why DRF model serialization is slow. https://hakibenita.com/django-rest-framework-slow

Thank you for sharing! Very useful.

Can you share what kind of perf gains you got? latency? concurrency?

> You also have to write a lot more specs, and such

Sorry, by "specs" do you mean type definitions?

Oh, and congrats on a successful port!

Our performance gains have primarily been in serialization, so response times are way better. It used to take multiple seconds for some things to serialize in DRF, and down to sub seconds. Its like 4x faster in that regard.

Yeah, meant Pydantic Models, SQL Alchemy models, and the actual endpoints. Its a lot of repetition in places. But the finer grained controls have been good for us so far. You just have to write the models, and don't need to worry as much about input validation in your own code. Which has been great.

That makes a ton of sense - thank you!

Yeah part of the magic of DRF is all the implicit stuff and the DRYness, but of course that can bite you anyway.

Need to indent that to be readable.

Oops, did this on my phone and meant to edit on laptop immediately. Too late now. Here it is:

    from typing import Optional
    
    from fastapi import FastAPI from pydantic import BaseModel
    
    app = FastAPI()
    
    class Item(BaseModel): 
      name: str 
      price: float 
      is_offer: Optional[bool] = None
    
    @app.get("/") 
    def read_root(): 
      return {"Hello": "World"}
    
    @app.get("/items/{item_id}") 
    def read_item(item_id: int, q: Optional[str] = None): 
      return {"item_id": item_id, "q": q}
    
    @app.put("/items/{item_id}") 
    def update_item(item_id: int, item: Item): 
      return {"item_name": item.name, "item_id": item_id}

fastapi is very similar to what you’d get from flask with an API spec tool like flast-restx or flask-marshmallow + incubation time to build your own components & patterns around it + fastapi is faster.

So if you are committed to the component tools you already built with flask add ons, stick to flask unless you need the speedup. Otherwise if the project is new or you’re otherwise uncommitted to your existing component tools, switch to fastapi.

Reply on news.ycombinator.com