in Code, Education Reform, Tech Trends

Why I Choose FeathersJS as my API Framework of Choice when Working with College Students

In my last post I discussed frontend frameworks, and why I choose VueJS when working with my students. In that post, I answered some more abstract questions about whether or not this choice is even important (probably not all that much), and whether or not, as professors, we should even be using frameworks (absolutely, yes). This post moves from the frontend to the backend, and why I like FeathersJS.

As with frontend frameworks, there are many choices one could make for the backend. Again, my choice of backend was driven largely by a desire to reduce the amount of time my students would have to spend learning a language as opposed to working to actually implement solutions. While I’m really enamored of the capabilities of Laravel (PHP), or Flask (Python), or Rails (Ruby, duh), I restricted myself here to JavaScript to spare students from having to learn another language.

I actually started out this process several years ago using Loopback/Strongloop. At first, I really liked their browser-based admin tools, and integration with Swagger. Starting out your API by implementing the schema with JSON schema, and automatically generating most of the CRUD operations as well as API documentation seemed like an ideal way to get students involved in the API development process. Unfortunately, however, IBM really screwed up when they acquired Loopback by trying to create a separately-branded, non-free, enterprise product alongside the open source project. When you went to start a Loopback project, somehow you ended up having to create an account on something called Bluemix which would send you $0.00 invoices. I eventually gave up in confusion.

Amidst my confusion, I discovered that a project called FeathersJS offered a CLI generator that could ingest JSON Schema (which I had already generated with Swagger) and automatically scaffold a Node-based API. Importantly, FeathersJS did a smart thing, which was to make themselves a kind of lightweight wrapper around Node Express. I already had some experience with Express, knew how easy it was to set up and configure, but also knew that without some kind of tooling, Express-based sites could end up requiring one to write a lot of tedious boilerplate. Even from the beginning, Feathers seemed to figure out how best to leverage and augment Express with a framework that had all of the speed and ease-of-configuration of Express, without the annoying boilerplate. Also, they incorporated SocketIO which made it easy to provide realtime services in addition to the REST-based ones I was more familiar with.

Also, Feathers really shines in terms of its common API for interacting with data, almost entirely abstracting away the vagaries of working with any particular database technology. Feathers figured out a way to sidestep the morass of creating a collection of ORM tools, opting instead to use pre-existing 3rd party packages, and wrapping them with thin adapters to deliver a datasource-agnostic way to build out an API. As an example, here’s the code you would write to query the API to get all “to do list” items with a due date in the future:

The beauty of this is that at no point do you have to worry about what kind of database the data is stored in. It could be a SQL database like MySQL or Postgres, or a NoSQL database like MongoDB or Redis, or an in-memory data store, or a CSV file, or basically anything. Feathers has a wide variety of adapters for most any kind of data store. You can even change the data store without having to worry about whether or not your client code will still be able to access it.

Feathers supports robust data modeling with standards like JSON schema and since your data models are part of your code base, they can be versioned in Git along with the rest of your code as your schema evolves over the life of your app. This is easier than working with migrations used by ActiveRecord, and solves the bottleneck of having to wait for your DB admins to fully work out the schema before your developers begin working with it. Everyone can work in parallel. It’s easy to create simple mock responses to these queries so that you can test your code in advance and even put off implementing the full database until the end.

Particularly important, the Feathers team is actively working on “offline first” strategies for data management. In an era where increasingly people want to access their data from phones, tablets, and other devices that may or may not have an internet connection at any given time, it is important to consider strategies for replicating slices of the database on the device and figuring out how to sync up with the remote database when network connections become available. While other frameworks, like Meteor, have made some attempts to handle these situations, I don’t know of anyone who has quite pulled it off yet. I wouldn’t be surprised if the Feathers community gets there first with a really robust solution.


For new apps being built today, it makes the most sense to separate the backend data API from the frontend user interface. For people coming from traditional MV* frameworks like Ruby on Rails, Django, or Laravel, this takes some getting used to (as I’ll talk about in my next post). It also makes sense to use JavaScript on the server side (i.e. for the API) as well as the frontend client since it allows you to have a team of developers who specialize in one language (JavaScript) that can work on both sides of the app. I’m really impressed with FeathersJS and expect to continue using it for at least the next couple of years.

Write a Comment



  • Authorizing Feathers API Requests for Vue/React/Angular Apps Using Auth0 – Morphatic

    […] my last two posts, I explained why I choose to work with VueJS, and why I choose to work with FeathersJS. I haven’t yet discussed […]