ekryski

I think a lot of people still haven't seen https://feathersjs.com/. Has been around for a while and offers all of this and more AND is drop in replacement for Express.

Sure, but it's about balance and setting expectations with the users of your open source framework. Being transparent and delegating responsibility. Your project can only scale as well as you can and that is limited by the number of hours in the day. It's called "open source" for a reason and typically the nature of open source is not money but shared knowledge and contributions. If you're looking for money it probably should just be closed source.

I 100% agree but it's only "a problem in open source if you don't recognize the situation". I've been writing about this a bit on Medium. https://medium.com/@ekryski/your-open-source-is-a-product-st...

Exactly. Even at 20 hours a week you're looking $20k/month. As a freelancer that is a great rate with little overhead. There is no doubt that being the author of Hapi is a major reason why he can charge that rate. I get being burned out and/or wanting support but not recognizing the correlation just comes across as entitled.

Definitely an intentionally click-baity headline :). I am in no way affiliated with either company in the at article. Just happen to know the guy that did the VERY thorough detective work.

However if you are spending money on some of the higher end Digital Ocean servers you are getting screwed, as they are massively underperforming even compared to just a couple $5-$10 instances.

I'll also note that I am a big fan of Digital Ocean and have been a customer for quite a while now.

That's pretty smart. Effectively versioning your issued tokens. Way easier than maintaining a blacklist.

You have to be careful that you are not leaking sensitive info though, as the JWT payload is meant to be visible on the client as well.

I agree that's how we treat them with Feathers. You may know this already but JWT's are intended to be decrypted on the client so you shouldn't be be saying "if" it is cracked, more "when". The signature is only good for ensuring that the content hasn't been manipulated. Not that you are, but for others, never store anything inside a JWT that is sensitive, and if it is make sure you encrypt it first before you put it in the JWT payload.

Glad you are liking it. Yes auth needs a bit more love. I'm working on it right now actually. It's getting close to a 1.0.

As far as passwords go, I assume you are referring to passwordless auth? We are working on that right now :). https://github.com/feathersjs/feathers-authentication/issues...

Sounds good. Really appreciate that feedback. Seriously. I have felt a bit like we are throwing a lot at people at the beginning of the docs.

Nope. Not intentional. Looks like we had the old URL. Thanks for pointing that out. I've updated the website and the docs.

I'll quickly add to what daffl said. That there is one more manual method outline here (https://github.com/feathersjs/feathers/issues/265#issuecomme...) that doesn't require running another non-feathers server.

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.

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.

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!

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 :-)

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.

Feathers also supports Primus (https://github.com/primus/primus) so you can a bunch of other socket transports.

RethinkDB support is in the works for sure! https://github.com/feathersjs/feathers-rethinkdb/issues/9

Thanks for that feedback! What are you finding overwhelming? We're always looking to improve.

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!

Let us know how you fair and if you run into any issues. The best way is in slack.feathersjs.com.

Yup and I use Webpack. The beauty is you get to take your pick. The downer is it's not set up for you. Tradeoffs for now...

Glad to hear you are liking it!

Disclosure, I'm one of the creators of Feathers.

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.

Nice work! I've been using base (http://www.basscss.com/) for a couple years now. Any idea how it compares to this other than being ~1kb bigger?

Good writeup. I'm curious as to why you guys didn't move to Redshift from Postgres instead. Seems like a more natural switch.

Full disclosure - also another Feathers maintainer here.

To add to @daffl's comment...

Inevitably there is always some "lock-in" when you choose a technology and honestly we're trolling Meteor a tiny bit, but I our aim with Feathers is to mitigate lock-in as much as possible by few design choices:

1) What daffl already said about small composable/reusable modules

2) npm module support. You get to leverage all the awesome work others have done (without any additional overhead like porting modules or shimming them).

3) existing Express/Connect middleware just works.

4) a very small codebase over top of another small modular codebase (express, socket.io). The theory being less code, means less to go wrong, which saves devs time writing code and debugging.

Ultimately, you do need to decide whether you want the Meteor sort of approach where it's more of a kitchen sink that gives you all the tools you need but makes it hard to step outside the secure sandbox, or whether you want something that is a bit more flexible. Since, in my experience, all the projects I have worked on inevitably end up with something custom that the framework du jour doesn't handle I prefer more flexibility and small composable modules.

We've tried hard to see if we can strike the balance between offering just enough without getting too much in the way. If you think we're on the right track or not we'd love to hear your feedback.

@pan_w I'm also another Feathers maintainer. I'm curious which part(s) or all of fFeathers you are finding unfriendly or hard to understand. We're always looking to improve our site, docs, examples so I'd love to hear your feedback. If you haven't given it a spin, can I ask what the barrier is?

We are planning on putting out a more comprehensive walkthrough of building a full typical app (more than just a toy Todo example) so hopefully that will help!

Nice writeup! 2 knit-picky points:

- I would amend point 3 to also include helper methods/modules. I like to keep my render functions pretty small so I'll usually call helper methods or have an external module if the calculations are pretty hairy.

- cx is soon to be deprecated and now you can use the module "classnames".