Using class views?

[wu-clan]

Hi, @downdawn

I've looked at the class view implementation of fastapi_utils in general, but I'm not very interested

# End Setup
app = FastAPI()
router = InferringRouter()  # Step 1: Create a router


@cbv(router)  # Step 2: Create and decorate a class to hold the endpoints
class ItemCBV:
    # Step 3: Add dependencies as class attributes
    session: Session = Depends(get_db)
    user_id: UserID = Depends(get_jwt_user)

    @router.post("/item")
    def create_item(self, item: ItemCreate) -> ItemInDB:
        # Step 4: Use `self.<dependency_name>` to access shared dependencies
        item_orm = ItemORM(name=item.name, owner=self.user_id)
        self.session.add(item_orm)
        self.session.commit()
        return ItemInDB.from_orm(item_orm)

For session, since we're using SQLAlchemy-2.0, we'll use async_db_session.begin() directly, this seems to make more sense

from functools import wraps

def session_decorator(func):
    @wraps(func)
    async def wrapper(*args, **kwargs):
        async with async_db_session.begin() as db:
            return await func(db, *args, **kwargs)
    return wrapper


class ApiService:

    @staticmethod
    @session_decorator
    async def get_api_list(db):
        return await paginate(db, ApiDao.get_all_apis())

For Depends(get_jwt_user), we need to make FastAPI >= 0.95.0, then use the Annotated feature, and call it globally, E.g:

CurrentUser = Annotated[User, Depends(get_current_user)]

Like in the fastapi documentation: Share Annotated dependencies

[downdawn]

Sorry for just seeing this now.

The cvb of fastapi-utils is designed to solve the problem of duplicate dependencies, but using Annotated and dependencies in APIRouter can also solve similar problems, such as verify_rbac and CurrentUser.

Of course, using classes still has its advantages, especially for those who are accustomed to using classes, as it can be more intuitive.

FastAPI design philosophy leans towards using functions, it would be a good choice to follow this mainstream approach.

[wu-clan]

I renamed the previous verify_rbac to rbac_verify, which seems to make more sense

[downdawn]

Haha, the difference between Chinese and English styles.

[wu-clan]

Agreed.

Class wrapping makes people look more comfortable and is easy to extend, but fastapi_utils doesn't look bright enough in the latest versions of FastAPI and SQLAlchemy

Maybe we can think of a better way to implement class wrapping, if not, will continue to use functions

[downdawn]

In fact, fastapi_utils has not had substantial updates for a long time, perhaps because of the new features of FastAPI.

[wu-clan]

I will look at its internal implementation in my spare time.

[wu-clan]

Look here fastapi-class

I think I will combine fastapi-utils and fastapi-class to do something, a new library?

Uncertain time, use the function temporarily.

The library is compatible with function, and there is no need to modify any interface parameters.

[downdawn]

looks good

I personally like the method_decorators and decorators design of flask_restful, which is more flexible.

Pseudocode like this:

from flask_restful import Resource


class UserResource(Resource):
    method_decorators = {
        "get": [cache],
        "post": [limit],
    }

    decorators = [auth, permission]

    def get(self):
        pass

    def post(self):
        pass

The custom endpoint of fastapi-class is also great, or this is enough, the idea is similar.

[wu-clan]

Hi, @downdawn

I have fixed and added some features in fatapi-class, I will add it in its next release (3.4.0), do you have any other ideas?

[downdawn]

After a simple test, it seems that some features are lost, such as 'summary' and inaccurate exception positioning.

Personally, I don't like the settings: RESPONSE_MODEL, RESPONSE_CLASS, exceptions.

I prefer to do some more meaningful things in the class, such as permissions and current limiting.

What do you think?

[wu-clan]

Loss of functionality is expected, and unless the class functions also use decorators, as in fastapi_utils, there will be a huge amount of work.

For permissions, individual settings must be supported. If you want to set them globally directly, you can set them directly in APIRouter.

Interface flow limiting is currently implemented by third-party libraries, as to whether to add it to fastapi-class, I think it needs to be discussed in fastapi-class

[downdawn]

Agree

[downdawn]

Can look forward to yezz123/fastapi-class#104

[wu-clan]

I'll do some work here, but the class view shouldn't be coming anytime soon

[wu-clan]

Interesting： https://github.com/goraje/fastapi-controllers

and here： https://github.com/litestar-org/litestar/blob/main/litestar/controller.py

[downdawn]

looks good