The trick is that there is no actual definition of minimal, so you can always add it to your list of adjectives and sound more hip as a result. Another good one is "clean".
We try and help you keep it clean. Check out https://github.com/feathersjs/feathers-chat to see what our idea of an app should look like. Obviously, different strokes for different folks, but that's the kind of code we like.
Express claims to be a "Fast, unopinionated, minimalist web framework for Node.js" so we decided that minimal fits well because Feathers at it's core is just a very small extension to and in the spirit (or so we'd like to think ;) of Express.
The core product doesn't ship any of them, so you can choose the _one_ you need, or provide your own implementation by satisfying their well-designed service interface:
Out of the box is an appropriate way to describe it if it's a plugin that's been developed, tested, and guaranteed to work by the core team. Just because it's not installed/enabled by default is a good thing IMO.
We have used Feathers to build http://www.zeek.ai/ and have been really happy with it so far. The consistency between the client and server libraries makes developing with Feathers fast.
Despite reading that webpage I still have difficulty understanding what the actual product of zeek.ai is. Has it something to do with converting Twitter followers to customers?
How does the realtime work when there are multiple node processes or servers? If my client is connected to server A and an update occurs on server B, will my client get the event on the web socket? If so, how does server A know about the event that occurred on server B?
To handle the real-time event syncing we created https://github.com/feathersjs/feathers-sync. It uses a central Redis DB or a MongoDB tailable collection to to synchronize service events between different application instances.
Another option is to use your websocket libraries' clustering library, for Socket.io for example there is https://github.com/socketio/socket.io-redis.
This is a very good question. We're definitely planning on adding a section about performance and scaling to the documentation very soon.
I started playing with this recently and so far I'm loving it. Here's a Vue.js component example I wrote that interacts (CRUD operations) with a Feathers message service over websockets: https://gist.github.com/niallobrien/7eb51d17c977c46babb8
Just wondering, how are you using ES2015 imports in the browser? Does Feathers come with a built-in module loader parser, or is this a feature of using Vue, or are you doing some other magic?
Feathers doesn't assume much on the client. You can use a module loader or the bundled Feathers client which works right out of the box. To be able to use ES imports in the browser I personally use http://stealjs.com
From a glance what makes this appealing to me is the fact that there's less magic than with Meteor, which means I can use my own build process, and I can use any compile to js language.
+1. One of the main reasons why I'm considering this for future projects is how much easier it is to understand the magic components, support for many more databases out of the box, like MySQL, etc.
Pretty interesting. A little overwhelmed with amount of choices. Also not sure what to think, I will have to do example app and see for myself. It does look very promising. I really like that it builds on the work of others instead of reinventing the wheel.
It is cool that I can use 3 different engines to talk to sql db's, but maybe don't tell me that right away. I think it is more interesting that your architecture is so flexible and maybe show me how simple it is to get started.
The term "real-time" means that you can guarantee certain timing constraints. It can only work on a substrate (OS) that supports real-time processing. So I am sure that "real-time" is not what this package is offering.
Sorry to tell you this but the term now has a different meaning within the web development community.
If that bothers you then regain your composure by remembering that 'computer' once referred the operators of calculating machines - not the machines themselves:
The parallel to "computers" does not fit in this case, because that change came to the entire world at the same time, via the same mechanism: computer -> electronic computer -> computer (when human computers became obsolete).
In this case, the existing meaning of "real time" is not obsolete, so the analogy does not work.
---
Next, just because language inexorably changes over decades, generations, and centuries, does not mean that a subculture deciding to use an existing word in a different way is "The language changing."
It's just a subculture deciding to use a word in a different way. When they go forth and use that word outside of their niche, and there is confusion because they mean one thing and the rest of the world means another, the subculture does not get to shrug and say, "language changes."
When you use words, it is your responsibility to know your audience and use the words your audience understands, in the way that they understand it.
And so it is with technical terms that have established meanings in the computer science and programming community. By all means redefine what "class" or "type" or "realtime" means. Use your definitions within your subculture with abandon. But be aware that when straying outside of your community, it is your responsibility to use terms that your audience understands, not your audience's responsibility to presume that all bets are off, and any word might mean anything.
---
Finally, I question the tone of "sorry." Perhaps you didn't mean it that way, but it has an air of the arrogance of a pop culture programmer. "We're inventing new stuff here, no time for your old ideas, daddy."
It would be helpful if instead of snark, you responded with an actual explanation.
Especially since a quick search of "real time javascript framework" doesn't return one. The most relevant result suggests that a chat application or dashboard is "real time". When it's really just two-way communication (sockets et all).
In this context, it doesn't appear to mean anything at all AFAICT (aside from marketing) as any framework with some minimal helpers supporting sockets could use the label. Or not... since despite your response, it's possible I've misunderstood since it's not actually a "web development community" bit of language AFAICT. Having been a member over a decade.
It irks me too, but the term has been adopted in recent months, I think, by the javascript community. It is usually used to mean something akin to reactive.
My guess is that they are pulling that from Socket.IO's use of the same "real time" term. Which I suppose is to denote that it's not ajax polling (though I understand that Socket.IO does poll in some situations...)
What jumped out at me was that feathers can be added to an existing express.js application. That says a lot about feathers' modularity and design, definitely easing concerns about lock in or making the wrong choices at the beginning.
I think SSE has two limitations that might not make it too useful for some scenarios:
- Each SSE channel would require a separate TCP connection. And as the connections for a browser are limited, you can not support a lot of of different SSE channels. This is mainly a HTTP/1.1 problem, HTTP/2 fixes this. But as browser and server support for HTTP/2 is still limited you might not bet on it.
- SSE can only send chunks of text in each notification, where the possible payload is additionally limited by the SSE encoding (you can't send text with \n\n in it). So if you need binary or abritrary (JSON?) text objects you would need some additional encoding. Like object -> json string -> byte-array representation -> base64 string. This works, but the overhead for your application (must do the encoding) and the browser (must to all the decoding and look for the \n\n) is not ideal.
I'm currently experimenting with using HTTP/2 and fetch API with readable streams to stream arbitrary objects on a bigger number of parallel channels from server to client. This seems to work and looks quite promising for the future, but due to missing browser and partly also missing server support the solution is definitely in it's infancy.
So the current safe bet for enabling lots of notification channels or enabling realtime queries would still be websockets.
That sounds like something worth keeping track of. Do you want to create an issue at https://github.com/feathersjs/feathers/issues for it? The nice thing is that you most likely won't have to change your services when adding a new transport layer.
I love feathers. Simple and easy to use. The concept of services and hooks is an awesome abstraction that strips out more code than it adds.
I just wish the authentication was a little more robust. I like that they realize stateless auth is the way to go but how about we get rid of those passwords too!
Does Feathers support SAML authentication? I don't see it in the docs, but I figured I would ask. It says it's built on top of express, and express has SAML support... is it possible to leverage that?
We haven't tried it ourselves but Feathers just uses passport for auth underneath so any passport auth strategy will work. For SAML, to make it feel "Feathersy" might take a bit more work (ie. wrapping it up as a Service) but definitely open to creating an issue for it and for PRs. A quick and dirty way is to just use it Express style and call the official Feathers auth services from your own Express routes. Feathers really is just Express, so you can use any Express middleware like https://github.com/bergie/passport-saml.
Nope, no reason at all. It will work just fine. Feathers is pure JS and doesn't have any hard external dependencies. On the client, it just handles the data layer and communication with the server.
The title (which is not the title of the original article) makes it sound as if Meteor is not open source. Meteor is open source, and MIT-licensed at that.
Ok, we've replaced that with (a less baity approximation of) the original title. Submitted title was "Feathers 2.0 – An open-source alternative to Meteor".
I think a much more interesting title would be "An alternative to Meteor supporting 15+ databases and 4 ORMs."
I'd imagine a lot of people (myself included) have cooled somewhat on Meteor as SQL support has failed to materialize, so Feather's DB flexibility seems like a standout feature.
Only: there's no real-time db support like what Meteor with livequery does. The term 'real-time' is abused a lot here. Not only does neither Meteor, nor feathers offer real-time in the real meaning of the word. A better word is 'reactive'. But feathers just provides the very basic infrastructure (basically just websockets). Meteor also supports any type of DB, but only Mongo comes with reactivity... (Although their 'apollo' project is looking to change this).
You are right Feathers is MIT and so is Meteor. They both do real-time, albeit a bit differently, so we like to consider Meteor an alternative to Feathers and vice-versa.
We are trying to be as transparent as possible and because we don't currently have any formal support from anyone except for the contributor's time and energy, we rely heavily on the community and need to remain as open as possible.
Personally, I think Meteor has done some amazing stuff and some not so amazing things. I respect a lot of what they have achieved but we are making a different attempt at similar problems. Nothing more to it than that really. We've tried to put up objective comparisons between Feathers and many of the real-time solutions out there http://docs.feathersjs.com/why/vs/readme.html. There is no silver bullet for all situations and all people.
Except, claiming you guys are "Real Time" just because you offer a basic websockets implementation and positioning your offering as anything that compares to Meteor is a sham. You don't have real time. You have web sockets that anyone can trivially hook up with NPM. You're undermining Meteor's exhaustive real time functionality when you say that. You are also tricking would-be users who don't know any better. They will show up using your framework, have extremely limited (basically non-existent) real-time functionality, and never know what they would have missed had they looked more into Meteor.
Meteor offers a slew of real time features, propagating real time observation of the database up the stack through your webservers to your views, all functioning seamlessly with feature-packed APIs to query your data and make sure everything is kept up to date.
But I think you know this. Capitalizing on your juxtaposition next to Meteor only makes you look bad to someone that actually uses Meteor. You're trying to convince people who haven't used Meteor--and perhaps don't have much experience when it comes to real time--that Feathers is remotely close of an option if you have real time needs. It's not. And most likely a few months from now you will be using the open source--and decoupled from Meteor--Reactive GraphQL (Apollo) project they are developing as the basis for your real time functionality. Only at that point will you be able to claim your real time--but that's beside the point.
You've been around for years, and now your framework is just "a few hundred lines of code"?? That's because you're likely taking the marketing value of having been in the game for a few years (though minimal value compared to claiming you come remotely close to competing with Meteor), and using the name "Feathers" to back your latest reincarnation where your mix-n-match a hodgepodge of NPM libraries that anyone can easily do. Sorry you had to throw away a bunch of code--I know how that goes--but call it what it is instead of all this dishonesty: your latest NPM boilerplate. The newer and humbler Meatier boilerplate offers more realtime than you do!: https://github.com/mattkrick/meatier . And its author doesn't attempt to presume it's anything more than a highly useful boilerplate.
THESE GUYS (FEATHERS) HAVE NO REAL-TIME OFFERING, EVERYONE. DON'T BE FOOLED. If Real Time is what you want, these guys are not it. I find The dishonesty of their marketing unappealing and I hope anyone reading this does too. They are capitalizing on the "Meteor" name and its deep association with "real time" functionality, when in fact they are nothing like it.
Ouch. Meteor's data syncing is great, but it's not a mandatory part of real time.
That said, from their web site:
> Feathers is completely open source and is community supported, whereas Meteor, although open source, is venture backed and has raised $31.2 million to date.
A license is either Open Source (it meets the OSD) or is not. There is no 'completely open source'. I think Meteor's overvalued too, but you're not 'more' OSS than Meteor is.
All of the docs are from https://github.com/feathersjs/feathers-docs using the amazing Gitbook. We are totally open to PRs if there is something that is incorrect or could be worded better :-)
Sorry you feel that we are being dishonest. It's definitely not intended. I respectfully challenge the claim that Meteor is currently real-time and Feathers is not. Just because we're not (currently) doing oplog tailing on Mongo and data diffing does not mean Feathers isn't real-time, instead we sync up things at the service layer.
We do have plans to (optionally) support "real-time" all the way from the database as well and we are currently working on something similar to Apollo and Falcor. Can't do it all at once with no financial support.
If you feel things could be better and are interested in helping us achieve what you think is a more justified stance on being "real-time" then by all means PRs are more than welcome!
It's misleading and almost innacurrate. But yes I understand how time consuming and painstaking it is to build basically anything substantial. I'd just do more with realtime before u go comparing yourself to Meteor. Also the meteor features you listed are still only maybe 25% of all the realtime functionality Meteor has over Feathers. Fortunately things are changing thanks to GraphQL, so you will be able to offer thorough real time soon, but the rest of NPM will be able to access it just as easily. The NPM ecosystem has done a phenomenal job of killing the need for frameworks. I myself am basically a Meteor refugee. It's awesome, but you just don't need it or any framework anymore if you are a serious developer building professional apps.
As a counter-point, I have built "real time" web apps and Feathers was exactly what I'm looking for and matches my mental model for what that word means.
This is complete nonsense. You clearly haven't used Feathers. I can assure you that Feathers does indeed provide realtime functionality and have code examples to back up that statement.
My issue wasn't with the idea of Feathers being an alternative to Meteor... it was with the original title which made it sound as if Meteor wasn't open source. It wasn't even a defense of Meteor, just a clarification of the title.
Yes, Feathers relies on either Socket.io or Primus (your choice) for the websocket interface, both of which provide auto-reconnect with back off out-of-the-box.
I will also follow up with, although we mention it on the site, we realize there may an implied bias with the comparisons being on the Feathers site and if anything is incorrect or out of date we want to correct it. So issues and PRs are very welcome!
There are many valid criticisms of Meteor. As someone who has submitted patches & signed their contributor agreement, I agree - Meteor's licensing terms are not an issue.
> Feathers has adapters for 15+ data sources and 4 different ORMs out of the box. More than any other real-time framework!
Huh?