Fae CMS + Ruby on Rails: An Interview with James Kurczodyna
Reading time: ~ 5 minutes
James Kurczodyna is one of the creators of Fae CMS, a CMS engine that is built on Ruby on Rails. Fae was created by the team at FINE, a digital brand agency with offices in San Francisco and right here in Portland, Oregon. We had a chance to talk to James about what inspired FINE to build Fae, how open sourcing has changed the tool, how his team continues to evolve Fae, and much more.
What’s your role on the Fae team?
I am one of the creators of Fae, current tech lead, and part of the ownership group. The ownership group steers the general direction of the project and includes a producer, technical writer, designer, and frontend developer. We then bring in other developers when we do release sprints.
Why did you decide to build Fae?
Fae came about quite organically. We have been working with various CMSs for over a decade, including a few of the popular Rails CMS engines.
We invest time to understand our client's data model and content management strategy. We found that utilizing Rails' scaffolding and a collection of libraries and assets allowed us to easily set up a custom CMS. Building custom allows us to easily customize content paths and access levels. We also have the freedom to build a data model specifically around their organization, instead of fitting their data model into an existing system. This makes the experience for the content management team as efficient as possible.
We had limited success customizing existing systems, but always got hit by the 90/90 rule: 90% of the code takes 90% of the time, the remaining 10% takes the other 90%.
It was only logical to package the libraries, assets, and custom scaffolding generators into a gem. From there it grew. We kept adding features and once it was stable, we open sourced it.
How has open sourcing your application changed it? How do you balance community suggestions with your features?
Open sourcing Fae was a great decision. Knowing the codebase is open forces us to maintain our security-first mentality while keeping a clear scope of what the project should be.
Our roadmap is dictated by our clients needs. We add features to the project when we have real use cases to build for and test against. We tend to avoid working on community requested features if we won’t use them in our active projects as we aren’t in a position to maintain them as the project grows.
However, we have had a few great features added by the community directly. It’s amazing seeing other developers take the time to contribute their own ideas to the project.
What lessons/tips/advice would you give to someone considering releasing a product to the open source community?
If your project gets a lot of activity, it can be overwhelming trying to keep up with all the issues, requests and PRs. Don’t burn yourself out, come up with a community response plan that’s sustainable and stick to it. Don’t be afraid to say no or make reporters and PR authors take any extra steps to make your life as a maintainer easier.
Why was Rails the framework of choice for building Fae?
Before creating Fae, we had been building applications with Rails for a couple of years. After living in the PHP world using WordPress and CakePHP, our team started dabbling in Rails. We were immediately hooked.
I could list a bunch of reasons that are covered in other "Why We Love Rails" posts: the elegance of the Ruby language, convention over configuration, the baked-in, opinionated solutions to problems we'd spin our wheels on otherwise. But one of my favorite "features" of Rails is the community.
In my career, I've never gained so much knowledge or found so much inspiration in a single community. As I connected with people via conferences, forums and Github issues/PRs, I really appreciate the focus on the human side of programming too.
What were the advantages over other language and framework options?
We're spoiled for choice in the web development world, and I'm a big believer that there's no objectively “best” framework or language. If you have solid tooling and process around your technology, and your team is happy, you're off to a great start.
Have there been any shortcomings you’ve encountered from choosing to work with Rails?
There has been some turbulence recently with our frontend stack. After exploring our options, we decided to start decoupling our frontend and backends.
For the backend, we've added a GraphQL layer on top of Fae to communicate with the frontend stack. In our latest release, we officially documented our GraphQL support and added automatic GraphQL type creation to our generators.
This is a pretty common trend right now in Rails. What framework did you use to replace your frontend, and why did you choose it? Do you think there's a place for Rails going forward?
We started using Nuxt as the frontend of our larger projects. Our frontend team really liked Vue after auditing JS frameworks that paired well with Rails. Nuxt is built on Vue and provides all the features we required in a full framework, so it was an easy transition.
We still love using Rails as our backend. Along with Fae as our CMS, we use the Rails app to apply business logic to the data before packaging it up and sending it over via GraphQL. This creates a good separation of concerns where the backend is responsible for data management and business logic, and the frontend focuses on presentation and interaction.
How do you decide when/where to use DSL or regular Rails methods?
In order to make Fae more customizable, the generated object's models, views, and controllers all live in the parent app. This makes it simple for any developer familiar with Rails to jump right in.
However, maintaining the generated code becomes very difficult if you have to adjust it with every Fae upgrade. We'd never be able to release a backwards compatible minor version.
To solve for this, the generated code has hooks into Fae's core via DSLs and other methods. A few good examples are helper methods for form elements, controllers inheriting from Fae::BaseController, and models including a Fae::BaseModelConcern.
These DSL, classes, and concerns keep Fae's core logic centralized, easy to maintain and still very customizable.
How does the team at FINE prioritize work on Fae? Is there a dedicated team, or does the work fit in around client work?
At the patch level, we submit fixes as they come up in our daily client and internal work. These can be made by any developer on the team working with a Fae project.
We then forecast upcoming feature needs based on specific use-cases from our clients. We'll dedicate a couple of weeks for a team to release a minor version with those features ahead of the project kick-offs.
Major versions are planned by the ownership group as we analyze the shifts in the CMS market and determine the overall direction we want the project to go in.
Compared to other open-source Rails CMSs, what makes Fae different?
Fae was built to get you off the ground fast. You'll have a functional, full-featured CMS after running a couple of generator commands. What makes Fae different is the ability to customize and scale once you're already off the ground.
You can utilize options in our helper methods, inject code into Fae native classes via concerns, overwrite classes altogether, or build a 100% custom section in your admin.
These kinds of customizations don't feel like hacks because we document and support these methods as a feature.
We’re always excited to learn more about the wide realm of tools that are supported with Ruby on Rails. Have you used Fae CMS on a project? What was your experience with the tool? Leave a comment below to let us know.