Why create SerialAlchemy?

The serialization problem for web apps has been solved many times over. I had been using marshmallow for several projects. It’s a great library, and has its own justification for existence.

While I liked working with marshmallow just fine, it is designed to be very broad and fit a lot of different situations. I mostly create small web applications, so my situation rarely changes.

If there is one reason for creating SerialAlchemy, it is the fact that I didn’t like the idea of defining my models, then having to define marshmallow schemas. It felt like redundancy to me. Keeping the marshmallow schema in sync with model changes was also a pain, but feeling like I was repeating myself was the bigger reason.

And yes, “alAl” in SerialAlchemy bothers me, but SeriAlchemy sounds too much like Siri-Alchemy, and I fear Apple’s legal team.

Why not use SerialAlchemy?

I thought I’d take a different approach to selling this. Truth is, I made this library for me, and don’t really care if anyone else uses it.

• SQLAlchemy is required. This library simply won’t work without it.

• While SerialAlchemy is not beholden to any particular web framework, it doesn’t make a lot of sense outside the web application area. SQLAlchemy has a built-in way to serialize expressions, and the result sets can be pickled.

• There is no data validation. SQLAlchemy has simple validation built-in, and I feel like something more extensive is outside the scope of this project.

• SerialAlchemy is Python 3 only. Get used to it ;)