Marshmallow serialization 🔥️

[stevelacey]

What's this PR do?

Support marshmallow-based serialization so we can define fields once, in snake case, and without any of the cruft.

Where should the reviewer start?

Here's an example, omit the read/write methods and supply a metaclass with fields to define both:

class ProjectSerializer(Serializer):
    title = fields.String(dump_only=True)
    logo_url = fields.Function(lambda obj: obj.get_logo_url())
    image_url = fields.Function(lambda obj: obj.get_image_url())
    experience = fields.Nested(ExperienceSerializer)
    skills = fields.Nested(SkillSerializer, many=True)

    class Meta:
        fields = [
            "id",
            "title",
            "content",
            "start_date",
            "end_date",
            "url",
            "experience",
            "roles",
            "skills",
            "order",
        ]

Marshmallow allows you to mark a field as read-only/write-only with dump_only/load_only kwargs to the field.

Anything not present in Meta.fields won't be serialized, worf assumes that id/created_at/updated_at/deleted_at are dump_only given they're typically read-only, also fyi fields.Function are assumed to be dump_only.

Why is this important, or what issue does this solve?

Separate read/write definitions is a recipe for inconsistency, and largely a relic of how everything worked pre-serialization, this builds out those same things but from a single definition that's more flexible.

What Worf gif best describes this PR or how it makes you feel?

Tasks

• This PR increases test coverage
• This PR includes README updates reflecting any new features/improvements to the framework

[wadewilliams]

I think your assumptions around created_at deleted_at etc are valid and make sense. The note around id, created_at, deleted_at, and updated_at being read-only by default ought to find its way into the docs because someone will lose their mind trying to figure out why it doesn't work to write. I'm not sure if Worf should set these fields to read-only or leave that to the users to implement, but I'm fine starting here.

I imagine all it takes to override this is to set it on the serializer that inherits, so no worries

[stevelacey]

I decided not to set these by default but instead add a mechanism for settings these via django settings, along with any other default serializer meta you might want to apply, saving clients from creating an abstract base serializer, or needing to extend metaclasses to do it, which also means I can leave the implicit id alone and let it coerce to String or Int.

[wadewilliams]

Looks great, +1 for checking the box "this pr includes documentation" b/c it's far easier to keep the docs up-to-date along the way than to wait and then overhaul them