Over the last couple of months I've been spending a lot of time rethinking The Ferris Framework. If you are unfamiliar with Ferris, it is a traditional monolithic model-view-controller framework written in Python and designed specifically for Google App Engine. Its primary goal is to make it easier to build applications with the services and tools provided by App Engine and the Cloud Platform. At Cloud Sherpas we've used Ferris in nearly every project we've created over the past two or three years. Ferris has made a tremendous impact on the way we work with and think about applications. We also open-sourced it so anyone could take advantage of our tools and the community around Ferris has been fantastic.
Building for the Modern Web
However, times are changing. Monolithic web frameworks are being pushed aside in favor of the new paradigm of multi-device applications. Instead of an application playing the role of a single, unified application, the idea is to split it to use one backend for a multitude of frontends. For example, a photo-sharing service could have a web site, a native Android App, and a native iOS application. Instead of writing a monolithic web application and later exposing the API for your apps, you create the API that all of the frontends use. This methodology makes it much easier to develop applications in the modern world of multiple devices. We've taken a lot of inspiration from Google when thinking about how we want to build applications going foward.
Ferris 3 aims to carry on the spirit of Ferris 2 into this new methodology. It was tempting to give Ferris 3 an entirely new name, but it still serves the same purpose: to make it as easy as possible to develop applications on the Google Cloud Platform. We've removed much of the bloat in Ferris. It's no longer concerned with MVC, scaffolding, forms, templates, etc; that's the frontend's domain. Ferris 3 is a focused, modern toolkit for creating backend services on Google App Engine.
The most critical feature of Ferris 3 is the tooling around Google Cloud Endpoints. Ferris provides automatic discovery and wiring of endpoints services, tools that make it easier to define services, translations between datastore models and protorpc messages, and even generic CRUD methods.
The other huge difference between 2 and 3 is that Ferris is no longer a framework. It is now a toolkit and can be used alongside any other web framework (such as Flask). Ferris does, however, provide utilities to automatically discover webapp2 handlers and wire them up. This is a "best of both worlds solution" - if you want to use Ferris alongside another framework you can, but if you just need a one-off web request handler it's easy.
Ferris 3 also includes familiar and improved utilities from 2 such as model behaviors, search helpers, oauth2 service account utilities, Google API helpers, and cache decorators. These utilities can be used with any web framework you'd like.
These resources can help you get started with Ferris 3. Please note that a lot of these resources are very much a work-in-process at this early stage, but we are eager for feedback.
- Documentation for Ferris 3
- Ferris 3 on Github
- Ferris 3 Skeleton
- Complete Ferris 3 & Frontend Example
- Ferris & Flask Example
With this alpha release we're hoping to begin a conversation in code with the entire App Engine and Cloud Platform community. We would like Ferris to be a toolkit that everyone can use to make their lives easier, and we would love to hear your feedback on the mailing list as well as the Ferris 3 repository. We also graciously accept feature requests and pull requests. Our primary needs right now are improvements to the documentation, testing, and examples.