Yancy: What We Leave Behind

When I started the Yancy Content Management System, my goal was to see how easy it would be to build a generic admin editor on top of a Mojolicious application database. Its design was, therefore, simple: A backend layer to talk to the database, a web application to view and edit the data, and an API controller to connect the two.

Now, 4 years later, Yancy is on its way to becoming the M in Mojolicious MVC. I added Yancy::Model as a place to keep data logic without the overhead of DBIx::Class, but having a layer between the database backend and the web API enables all sorts of fun things, including:

• Custom validation
• Packing and unpacking of complex data
• Automatic joining of related data
• Secondary, read-only backends and failover
• Transparent caching
• Data versioning

And these things can work across different backends: A caching module that uses Redis could be a frontend for a cache of a MySQL database or a Postgres database. The code only needs to be written once and made available on CPAN.

Unfortunately, the new APIs take the place of some existing APIs and features that will have to be removed. These features were added to serve the frontend, but are awkward and limited in power compared to customizing the model API. The main features that have been deprecated are: Filters, Views, and OpenAPI.

Filters were added to enable the frontend to do password hashing. By adding x-filter to the configuration, a field or a row could have one or more filters applied to it before being written to the database. With the addition of the model API, filters can be added more easily and explicitly by creating a custom Schema class.

Views were a way to present subsets of data to a user through the frontend application. Instead of seeing all the raw information an application needs for a user, the editor could be made to show just the important information for the administrator or content manager. This, much like filters, can be done more robustly through the model API, or even directly through your database.

Last, the OpenAPI spec was how the frontend app analyzed the data schema to determine what it could do. However, since every schema can only do the same four operations (create, read, update, and delete), reading the OpenAPI spec to handle operations is needless complexity. The generated API could be used by more than just the Yancy editor, so the code for generating OpenAPI specs from Yancy schemas has been moved to the Yancy::Plugin::OpenAPI module on CPAN.

Yancy v2 has been planned and in development for quite a while, but it is nearing completion. When v2 is released, these deprecated features will be removed. What will remain is a leaner, easier-to-use content management system for the best web framework out there.