Reusable CRUD

[revmischa]

I would like to build a reusable CRUD view class on top of flask-rest-api. I built one previously fairly close to flask-restful's design, and was wondering if anything currently exists or you have tips or suggestions of how to proceed.

The problem I am trying to solve is building the same list/get/update/delete endpoints over and over for various DB models. I want to declare things like access controls, default schema for serialization, what fields are permitted to update, DB model class, relationships to prefetch (i.e. joinedload) for list view, and auto-registration of endpoints via __init_subclass__.

Anything you'd suggest or like to see? Anything like this exist already on top of flask-rest-api?

[lafrech]

Nothing like this exists to my knowledge.

In the applications in which we use flask-rest-api, we do have a large amount of duplication in the views. They look quite like the examples in https://github.com/Nobatek/flask-rest-api/blob/master/tests/test_examples.py.

There seems to be room for factorization, but we never tried that because the duplication is not such an issue, and because there are often subtle differences that make the views not exactly CRUD, so trying to build a meta class could end up being a nigthmare, with patches everywhere to handle specific cases.

This said, if I wanted to address that, I'd probably do it bottom-up: take start from a MethodView in my code and make a function that builds it given (as paramters) all the things that differ from one view to another (path, schema and such). Those parameters may differ from one application to another, so this could be application-specific, or at least easier to do in an application, more complicated to achieve in a generic way.

[revmischa]

I get what you mean about needing to override details. I've worked with these libraries before in both perl and python, and it's mostly a matter of creating a base class and defining the parameters you mention in class vars, and then having default implementations of the methods list, get, create, update, delete.

[lafrech]

Sounds good.

If you come up with something, it is definitely interesting to post it here in a comment.

In fact, now that you raise this, I may be tempted to do something similar in an app of ours.

[revmischa]

I'll start working on it and post a link soon.
One thing that would be really helpful: a way to define a "dynamic" arguments/response model by string, that can be evaluated later.

Something like is in Flask-RESTful Ref - see https://flask-apispec.readthedocs.io/en/latest/usage.html#inheritance

To allow subclasses to flexibly override parent settings, flask-apispec also provides the Ref helper. Using Ref looks up variables by name on the associated class at runtime. In this example, all methods in the PetResource view class serialize their outputs with PetSchema.

from flask_apispec import Ref

@marshal_with(Ref('schema'))
class BaseResource(MethodResource):

    schema = None

class PetResource(BaseResource):

    schema = PetSchema

    def get(self, pet_id):
        return Pet.query.filter_by(id=pet_id).one()

I'll need this to be able to declare schemas in class vars

[revmischa]

@lafrech - i sketched out a rough idea of one idea of what it might look something like. want to take a look? if you have ideas, just make a PR
https://github.com/jetbridge/flask-crud

[lafrech]

I had a very quick look. You're onto something.

The code is specific, tied to your database.

Looks like you don't need the Ref you're talking about above, do you? I didn't check flask-restful and flask-apispec, so I don't know why they need this, but I see nothing we can't do without it. In fact, I don't see right now what we could add to flask-rest-api to help doing this. AFAIU, the place for this is the application code (or a lib above flask-rest-api if it needs to be shared). Nevertheless, I like the idea.

[revmischa]

Can you elaborate on "The code is specific, tied to your database."? The only assumption it makes is that you're using flask-sqlalchemy. It should pick it up automatically

[revmischa]

if i could use Ref, i could eliminate the need to have the boilerplate super() calls. Those calls just apply the decorators in the default case. I would like to apply those decorators without knowing the schema ahead of time.

[lafrech]

The only assumption it makes is that you're using flask-sqlalchemy.

Yes, that's what I meant. It is tied to sql-alchemy (not MongoDB, for instance).

[revmischa]

put another way, the app would look more like:

@blp.route("")
class PetCollection(CollectionView):
    model = Pet
    schema = PetSchemaLite
    can_create = True
    can_list = True


@blp.route("/<int:pk>")
class PetResource(ResourceView):
    model = Pet
    schema = PetSchema
    can_update = True
    can_delete = True

which i think is a big win.

[revmischa]

@lafrech - jetbridge/flask-crud#1
more improvements
trying to figure out how to do access control checks now

[revmischa]

jetbridge/flask-crud#2 thoughts?

[lafrech]

OK, I understand the use for Ref. I don't know how to apply the same mechanism here because it would need to access the Blueprint object (where the model and schemas are provided as attributes) rather than the view function that is being decorated.

Here's an example of how I would naively tackle this: https://github.com/lafrech/flask-smorest-sqlalchemy-example/tree/factor_crud.

It uses Blueprint methods to create base resource classes bounded to the blueprint. Visually not as nice as the classes in your example above, but it works.

However, as you can see, each modification in a view function requires the whole function to be overridden. This could be fixed by adding other customization arguments to the method creating the resource.

I think this customization is tied to user code, so ultimately this belongs to user code.

There's a tradeoff, here, and in my app, I'm leaning towards keeping the duplication rather than relying on awkward customization and/or overriding a great part of the view functions.

Is there anything you think flask-smorest could provide to help achieving such a feature?

[lafrech]

Closing this for now, as it has gone stale. Feel free to re-open if further discussion is needed.