What’s next for Feathers in 2022?
Hello everybody! First of all, I wish you all a safe and healthy new year. 🎉🥳 It has been well over a year since the last post on this blog. In former times this would be where I tell you how great the last year has been for Feathers and show you growth charts of vanity metrics. 📈🐦
However, I believe we are all very much tired of looking at growth charts and vanity is hard to come by after spending another year in sweatpants trying to do something resembling meaningful work while my chosen home was in one or another emergency state of lockdown, on fire, flooded or frozen. I’ve never been particularly good at creating a buzz in the first place and this really doesn’t feel like the time to try and do so.
Yet, from universities to non-profits and from startups to fortune 100s all over the world, developers continue to build incredible things with Feathers. The past year has also seen an influx of new contributions, ideas and initiatives which I’d like to talk about in this post.
Feathers v5 🕊️
v5 (Dove) is the next version of Feathers and it has slowly grown into one of the most ambitious releases since v2 almost six years ago. It is an interesting challenge for any long-running project to weather the ups-and-downs and balance longevity and innovation past the initial excitement. What was nice to see is that the core concepts are still holding up and can even be applied to brand new technologies. Aside from some features that were long in the making, it will also be the first version introducing a new core concept.
Schemas
To me, the most powerful new feature is the schema definition and data resolution system. I have seen dozens of applications, no matter which framework, where the data model was duplicated across all kinds of different formats (first JSON schema, custom validations and SQL tables, then TypeScript types, then GraphQL schemas and so on). Changing or adding even just a property could be an arduous and error-prone task.
Feathers schema is Feathers approach to address the ever expanding list of data schema definition and validation formats. Similar to how Feathers services are a transport agnostic interface to your API, you define a data schema once directly in code (not in a custom domain specific language or external file) using the JSON schema syntax. You automatically get validations and, most importantly, the correct and always up-to date TypeScript type. There is no additional tooling required which has only recently become possible due to improvements in TypeScript’s static type system.
While schema definitions define property types and some basic validations, Resolvers complement a schema by allowing to populate properties based on the context, similar to GraphQL resolvers but protocol independent. Resolvers can be used outside Feathers but specifically address use cases that have proven to be challenging with just Feathers hooks such as:
- Securely populating associations
- Returning computed properties
- Securing queries and e.g. limiting requests for a user
- Setting context (e.g. user) specific default values
- Removing protected properties from data
- Add read- and write permissions on the property level
- Hashing passwords and validating dynamic password policies
With schema definitions and resolvers in place, any tool or plugin that understands JSON schema can then use them to do its job, from creating database tables to generating API docs. A schema driven approach that, in good Feathers fashion, isn’t taylored to a specific protocol allows us to continue building APIs that stay ready for whatever new formats and protocols the future might bring.
Hooks ⚓
I already wrote a while ago about the release of a standalone @feathersjs/hooks which brings middleware to any JavaScript or TypeScript class or function. It allows to create composable and reusable workflows without having to change the original code. Based on the middleware system of KoaJS, it runs faster and provides better error stack traces than Feathers original hook system.
v5 uses @feathersjs/hooks as the service method hook system, providing a backwards compatible wrapper that lets you continue using existing hooks as well as the new more advanced hook format where you have control over the before, after and error flow in the same hook function. With a new registration format it can also bring hooks closer to the services they are used with, for example with decorators (if you don’t like those, there are other ways as well):
Custom methods
The Feathers service methods are a great standardized interface for implementing almost all use cases needed for a web API. Since the methods are standardized, you also automatically get real time updates allowing to build reactive frontends, for example using Figbird for React or feathers-pinia for VueJS.
However, there are cases when you might want to expose more specific functionality, like re-sending a welcome email or making a complex query through your API. Thanks to the new hooks, which can be used with any method, this is now possible through the custom service method feature. Custom methods have a fixed signature of (data, params) and can be used through any transport. They also work with most existing Feathers hooks like authentication, validation etc.
New transports and platforms 🦕
One of the biggest advantages of Feathers is that you can focus on writing your application logic without having to worry about how it is being accessed. This already allows us to switch transparently between an HTTP interface and a websocket API (which can be significantly faster).
While Feathers works great by itself, the main web framework integration on the server has always been using Express. v5 now also comes with a new integration for KoaJS as the underlying server side framework. It has a faster router (built into Feathers), a more modern middleware system, native HTTP2 support and more. Even better, instead of having to rewrite your app in a new framework, most Feathers apps can be updated to use this new integration without having to change any of your existing services or hooks.
Feathers core already runs on several different platforms like NodeJS, the browser and React Native but why stop there? Deno is a newer runtime for JavaScript and TypeScript that brings some interesting approaches to security, performance and package management. It also turned out to be quite developer friendly with much of the modern tooling like a comprehensive standard library, a linter and a testing framework already built in. This is why we recently successfully moved the development of @feathersjs/hooks from Node to Deno, publishing the Node package in a build step. We are now working on doing the same for Feathers core modules. The jury is still out on the overall adoption of Deno but so far it has worked pretty well for developing a platform independent framework codebase. With a Deno server side transport also in the works, Feathers may even become the first web framework that runs natively on both platforms.
A new CLI
Developers love generators and CLI tools and for good reason. The Feathers CLI can get a working API up and running with a few commands in less than five minutes.
However, generators are a notoriously ungrateful open source project to maintain. Templates are often complex, obtuse and difficult to customize being buried in a third party module. Injecting code to wire things up automatically is brittle and even a minor change in your application code can make it fail. Generators are hard to test comprehensively and every new prompt adds an exponential growth in test complexity. Since the CLI is the first thing everybody encounters, you also see many requests for customizations and issues not related to the tooling but to someone’s system configuration.
These challenges have lead to researching other approaches to generators that are easier to extend and customize. One promising tool is Hygen, which puts generator templates and its metainformation, like the target filename or where to inject a code snippet, into the same template right next to your application. If you want to change it, edit the template to what you need and all future generator calls will reflect it. We also wanted to make it possible for each Feathers module and plugin to ship with its own generator templates. You can either just run it or eject the templates into your own application to customize them.
The discussion for the new CLI can be found in this issue and there is also a Hygen based prototype pull request. What we learned is that while it turned out more concise than the existing (Yeoman) generator, it is still fairly difficult to extend and customize. One of the biggest challenges is that templates continue to be hard to understand and change because most templating languages used for generators (usually EJS) don’t have good editor support, type information (you don’t really know what variables are available in a template) or particularly useful error messages. This is why we are now iterating on the concept of a generator that uses TypeScript for templating. It was kicked off with this pull request and potentially might become a standalone project called Pinion.
A new look
I always enjoyed Feathers bird theme and last year I had the opportunity to work with the wonderful Jasmine King on illustrations to make Feathers come to life with actual characters and giving it a new look with an updated website and colours which will launch with the final release.
Ok great, but when?
The good news is that you can use many of the things mentioned already by upgrading to the pre-release following the continuously updated v5 migration guide. This is a community effort and the more people try it and report any issues and give feedback on the new features, the sooner and more stable the final release will be. The CLI is still a big open project but after being stuck for a while it is finally also making some progress again.
Flying onwards
It has been more than a decade since I published the initial research and more than 8 years of developing and growing FeathersJS on the side into a project used by thousands of organizations and downloaded millions of times. We accomplished a lot in that time with very limited and varying resources, even “competing” (or so they seem to think) with venture funded “open source” startups.
Yet, a project that is an important part of businesses facilitating millions of dollars every day shouldn’t have to rely on a few people’s evenings and weekends indefinitely. While sponsorships have helped, especially since many supporters are also actively contributing in other ways, it about covers the rent for my two bedroom apartment. To be clear, this is better than many other open source projects but still a ways from a reliable living for even one person let alone for enlisting help to realize some of the potential that I believe is there.
This is why I started working on offerings for premium content and consulting with the goal to ensure the long term sustainability and growth of the Feathers project. This will include integrations for paid third party services (like e.g. AWS or Stripe) and guidance and more in-depth resources on more advanced use cases like scalability, security etc. You will hear more on this throughout the year.
As you can see 2022 might be an interesting year at least for this little framework in what has been and probably will continue to be a challenging decade. I’d like to thank all contributors and sponsors for being a part of this journey and am looking forward to hearing everybody's thoughts!
