Feathers vs X
The following sections compare Feathers to other software choices that seem similar or may overlap with the use cases of Feathers.
Due to the bias of these comparisons being on the Feathers website, we attempt to only use facts. Below you can find a feature comparison table and in each section you can get more detailed comparisons.
Due to the fact that ease of implementation is subjective and primarily related to a developer's skill-set and experience we only consider a feature supported if it is officially supported by the framework or platform, regardless of how easy it is to implement (aka. are there official plugins, guides or SDKs?).
: Officially supported with a guide or core module
: Not supported
: Community supported or left to developer
|Real Time From Server|
|Real Time From Client||(DDP)|
|React Native Support|
|Databases||10+ databases. Multiple ORMs||MongoDB||10+ databases. 1 ORM||Unknown|
|Hot Code Push|
Feathers vs Firebase
Firebase is a hosted platform for mobile or web applications. Just like Feathers, Firebase provides REST and real-time APIs but also includes CDN support. Feathers on the other hand leaves setting up a CDN and hosting your Feathers app up to the developer.
Firebase is a closed-source, paid hosted service starting at 5$/month with the next plan level starting at 49$/month. Feathers is open source and can run on any hosting platform like Heroku, Modulus or on your own servers like Amazon AWS, Microsoft Azure, Digital Ocean and your local machine. Because Firebase can't be run locally you typically need to pay for both a shared development environment on top of any production and testing environment.
Firebase currently supports offline mode whereas that is currently left up to the developer with Feathers. We do however have a proposal for this feature.
Both Firebase and Feathers support email/password, token, and OAuth authentication. Firebase has not publicly disclosed the database technology they use to store your data behind their API but it seems to be an SQL variant. Feathers supports multiple databases, NoSQL and SQL alike.
For more technical details on the difference and how to potentially migrate an application you can read how to use Feathers as an open source alternative to Firebase.
Feathers vs Meteor
Feathers is community supported, whereas Meteor is venture backed and has raised 31.2 million dollars to date.
Meteor only has official support for MongoDB but there are some community modules of various levels of quality that support other databases. Meteor has it's own package manager and package ecosystem. They have their own template engine called Blaze which is based off of Mustache along with their own build system, but also have guides for Angular and React.
Meteor has optimistic UI rendering and oplog tailing whereas currently Feathers leaves that up to the developer. However, we've found that being universal and utilizing websockets for both sending and receiving data alleviates the need for optimistic UI rendering and complex data diffing in most cases.
Both Meteor and Feathers provide support for email/password and OAuth authentication. Once authenticated Meteor uses sessions to maintain a logged in state, whereas Feathers keeps things stateless and uses JSON Web Tokens (JWT) to assess authentication state.
One big distinction is how Feathers and Meteor provide real-time across a cluster of apps. Feathers does it at the service layer or using another pub-sub service like Redis whereas Meteor relies on having access to and monitoring MongoDB operation logs as the central hub for real-time communication.
Feathers vs Sails
From a feature standpoint, Feathers and Sails are probably the most similar of the comparisons offered here. Both provide real-time REST API's, multiple DB support, and are client-agnostic. Sails is bound to the server whereas Feathers can also be used in the browser and in React Native apps. Both frameworks use Express, with Feathers supporting the latest Express 4, while Sails supports Express 3.
Sails follows the MVC pattern while Feathers provides lightweight services to define your resources. Feathers uses hooks to define your business logic including validations, security policies, and serialization in reusable, chainable modules, whereas with Sails, these reside in more of a configuration file format.
Feathers supports multiple ORMs while Sails only supports its own Waterline ORM.
Sails allows you to receive messages via websockets on the client, but, unlike Feathers, does not directly support data being sent from the client to the server over websockets. Additionally, Sails uses Socket.io for its websocket transport. Feathers also supports Socket.io but also many other socket implementations via Primus.
Even though the features are very similar, Feathers achieves this with much less code. Feathers also doesn't assume how you want to manage your assets or that you even have any (because you might be making a JSON API). Instead of coming bundled with Grunt, Feathers lets you use your build tool of choice.
Sails doesn't come with any built-in authentication support. Instead, it offers guides on how to configure Passport. By contrast, Feathers supports an official authentication plugin that is a drop-in, minimal configuration, module that provides email/password, token, and OAuth authentication much more like Meteor. Using this you can authenticate using those providers over REST and/or sockets interchangeably.
Scaling a Sails app is as simple as deploying your large app multiple times behind a load balancer with some pub-sub mechanism like Redis. With Feathers you can do the same but you also have the option to mount sub-apps more like Express, spin up additional services in the same app, or split your services into small standalone microservice applications.