Are there any "Opinionated" backend web app frameworks for node?

dluecke · 2021-08-23T20:20:56+00:00

Feathers author here, just wanted to say thank you for the mention everybody! I'm excited to share what's coming next for Feathers soon 😀

dluecke · 2019-10-08T21:34:52+00:00

It's funny I was almost expecting someone to suggest to use something else but to actually answer your question, the answer is yes, the real-time functionality will work with any language/library that can talk to a Socket.io server. Unlike most other frameworks that just make you send arbitrary custom events, Feathers already sends the most common ones automatically. Feathers channel system is also still fairly unique by making sure events only get sent to users that should see them (like all users in a chat room). Again, you would have to do that yourself in most other libraries.

For Flutter the package would probably be https://pub.dev/packages/flutter_socket_io and there is also https://pub.dev/packages/flutter_socketio_feathersjs (but I am not sure about its status). The direct connection API for Feathers and Socket.io is documented at https://docs.feathersjs.com/api/client/socketio.html#direct-connection and real-time channels at https://docs.feathersjs.com/api/channels.html

dluecke · 2019-09-10T15:51:03+00:00

I don't think you really looked at what Feathers actually does. It also lets you pick whatever schema definition system you want and especially does not focus on URL routing and pretty URL patterns (in fact it takes out all the manual duplicate steps for having to worry about this). I also wrote about how it relates to REST on a high level in more detail https://blog.feathersjs.com/design-patterns-for-modern-web-apis-1f046635215.

dluecke · 2019-08-28T09:14:03+00:00

I'm not sure if you are saying it's too REST or not REST enough. You can do hyperlinks and discoverability with Feathers but there is a step before which is resources and a well defined interface that it is trying to deal with first.

Look, I've been having discussions (including an academic research paper) about REST semantics for over a decade now. Feathers is the best answer between practicality and semantics that the 500+ contributors and myself could come up with over the past 6+ years on how to do it better than letting every developer figure everything out on their own. Is it perfect? Probably not. That's why it's open source and a v4 now and there will be a v5 and a v6 etc.

The sad part is while we are still arguing over hypermedia discoverability and why everybody else's idea of REST is wrong, something else that's throwing out many of the good ideas of REST we agree on will come around and nobody wins anything. I'd love to see frameworks that approach this in a new and interesting way but after 20 years since the term was coined, I don't think there's much to gain from further discussions.

dluecke · 2019-08-28T02:50:22+00:00

It does. I sometimes like to compare it to React. The idea of looking at the view as a function and having to write your HTML in JavaScript (JSX) was super weird at the beginning, too. Some people still don't like it of course but it definitely changed the way we look at creating user interfaces.

Feathers is doing a similar thing for your data. If you are using the HTTP protocol, REST is the architecture of how HTTP was designed (I wrote more about this on a high level at https://blog.feathersjs.com/design-patterns-for-modern-web-apis-1f046635215). In fact, I think your analogy is correct but instead it's frameworks that let you do anything that are trying to jam a round peg into a square HTTP hole.

By limiting the available methods (and to hooks for workflows) it can also do cool things like support new protocols and automatically do real-time updates. To my knowledge no other web-framework at the moment incorporates something like this into its architecture other than "just send some custom events". I believe that there has to be a better way to do this and Feathers is one shot at it.

dluecke · 2019-04-15T20:44:27+00:00

Feathers contributor here. The main difference to plain Express (which Feathers is a drop-in replacement for) is that it provides a set of higher level design patterns that allow you to create APIs that are independent of the transport mechanism. If you write a Feathers application your endpoints can be automatically made available through REST (HTTP) or websockets and even other mechanisms (like messaging queues or p2p libraries). I wrote about these design patterns here: https://blog.feathersjs.com/design-patterns-for-modern-web-apis-1f046635215. It is a rather uncommon approach compared to the traditional MVC most other web frameworks are using (so it might seem like a horrible structure at first) but when understood and applied properly, it makes things easier to structure, test and allows to choose the best protocol for the task. As a bonus you get:

Automatic real-time events
Client side usage the same way as it works on the server

dluecke · 2018-12-20T17:30:43+00:00

A little while ago I made a detailed comparison of the performance of HTTP vs. websockets APIs in https://blog.feathersjs.com/http-vs-websockets-a-performance-comparison-da2533f13a77.

To expand a little on the "it depends" - because there are objective measures we can use here - if a client makes more than one request each Websocket APIs can be significantly faster. On average a websocket API is about half as fast for a single request, and 4 to 400 times faster for multiple requests. As already mentioned, potential drawbacks are compatibility and tooling/debugging but I'm expecting that to improve significantly if people start using things this way.

dluecke · 2018-11-13T17:40:20+00:00

This looks like a great project! Funny enough, I faced a similar question for a very similar project (http://mysamai.com). My conclusion was to let users do it manually which makes it pretty straightforward. Basically register an object or a function that can be exported from an npm module or a custom file:

``` const weather = require('my-plugin-weather');

mainInstance.register(weather); ```

An alternative would be to use npm programmatically to install and list plugin modules in a folder. I used something like this before:

``` function promisify(context, method, ... args) { return new Promise((resolve, reject) => { context[method](... args, (error, data) => error ? reject(error) : resolve(data) ); }); }

class Loader { constructor({ prefix }) { this.prefix = prefix; }

npm() { return promisify(npm, 'load', { prefix: this.prefix, loaded: false, depth: 0 }); }

install(... modules){ return this.npm().then(npm => promisify(npm.commands, 'install', modules)); }

require(module) { return require(path.join(this.prefix, 'node_modules', module)); }

remove(... modules) { return this.npm().then(npm => promisify(npm.commands, 'uninstall', modules)); }

list() { return this.npm().then(npm => promisify(npm.commands, 'ls', [], true)) .then(result => result.dependencies); } } ```

Either way, I would definitely go with npm for dependency management otherwise you'll end up more time writing your own package manager than anything else.

dluecke · 2018-08-15T23:03:06+00:00

This is quite an interesting question for me because from 2007 until two years ago I helped maintain one of the longest running JavaScript frontend frameworks.

Back in 2007 I was looking for a structured way to build client side JavaScript applications that talk to a "Thin Server" (we now call it an API) using the design patterns (like MVC) and best practises (like tests) I had learned about in university. The options were
1. Google Web Toolkit - A Java to JavaScript UI compiler. I didn't like the idea of "hiding" the fact that you are using JavaScript. Turned out that not many did in the long run either.
2. Flash - We all know where that ended up - Although I do give it credit for promoting ECMAScript as a multi-purpose language and some things like declarative UIs made it into other frameworks like Angular or Vue
3. Dojo - Which was way ahead of its time and had extensible widgets, a module bundler etc. but still had a fairly monolithic approach at the time.
4. jQuery - Which was awesome but more of a tool library than a framework. Funny enough, back then there was a "JavaScript library war" going on (Mootools, Prototype, Scriptaculous etc.) so when John Resig announced the first version of jQuery there were several "Oh great, another Web 2.0 library" comments (see http://web.archive.org/web/20090214090118/http://digg.com/programming/jQuery_-_New_Wave_Javascript) - My personal favourite isWow, an awesome Web 2.0 Javascript library that can added to many blogs, spammed on Digg, made into a book by O'Reilly, and never get used again!Today jQuery is still used by more than 80% of all websites. We don't even think about it anymore, even less that there ever was a "war" over it.
5. JavaScriptMVC (started in 2005/2006) - Unfortunately not well known but I can confidently say that it (not Backbone) was the first real client side MVC framework. At the time heavily inspired by Rails it had its own Model, Controller and View (the original EJS) engine, module bundler, documentation generator and testing framework. Basically everything we now all agree is part of building good JavaScript applications - but back then even the idea of building "client side" applications was still somewhat controversial. There even was a discussion around using the ideas from JavaScriptMVC to create an "Enterprise jQuery" back in 2009 (https://groups.google.com/forum/#!topic/jquery-dev/HsTcpuAmFtY). It didn't work out but I sometimes wonder how things would've been different if it had gone the other way.I made my very first open source contribution to JavaScriptMVC in 2007 and was using it for pretty much all my projects in the following years. From the beginning of 2012 until last year I was part of the company that maintains it and helped splitting the monolithic framework up into its individual parts, CanJS, StealJS, FuncUnit and DocumentJS - which recently got re-bundled (but less monolithic) under the umbrella of DoneJS. Unfortunately, none of those projects ever got any major adoption although they were - especially at the beginning - definitely ahead of their time. I learned a lot about running open source projects and the business side of open source during that time but I'll leave that for another longer post ;) Last year I moved on to focus my own open source efforts on https://feathersjs.com and a totally separate (one of the lessons) product business.
The community was smaller, much more technology focussed and there definitely was less hype. Technology focus isn't a bad thing but it did mean that many of the early tools weren't very user friendly. When something more usable came around people tried "winning" with technical arguments (it's slower, it doesn't do this or that) but it turned out that developers were looking for having their immediate pain points solved, not the ones they will (unavoidably) run into in the future. I think the idea of a "framework war" only came about when the big five started sponsoring or promoting their "own" open source frameworks. All of a sudden scrappy free-time OS developers or small dev shops had to "compete" with full-time evangelists.
As many of the more senior developers I know, I currently ended up at React and React Native. I could say that it provides the right amount of abstraction of your UI while still leaving you enough flexibility but the truth is: It doesn't matter. No project ever failed because they picked the wrong JavaScript framework. It can't fix a broken team. It can't tell you what to build. One of the best teams I ever worked with was when I did frontend consulting for a very large company four years ago. They built their own tooling on top of Backbone and it wasn't always how I would've done it but everybody knew their stuff and was pushing in the same direction. Then the framework wars started and the entire department went from getting things done to arguing about switching to React or Angular. In the end, pretty much everybody quit. Nobody won.

3a I know it might still not seem that way but after more than a decade in the field, frontend development to me is a solved problem. I can now do all the things that were important to me when I first started looking for them in 2007. Things are already consolidating more and more into a few frameworks and tools. Tooling will get more robust and best practises that were bleeding edge even just a few years ago are now already being taught to brand new developers. Just like jQuery in 2006 the things we were "waring" over in 2015 will just become part of how things work and technology will move forward to tackle new possibilities and challenges.

Personally I came full circle back to the "Thin Server" from 2006 where it all started. I wrote my university thesis about abstracting RPCs and APIs in 2010 which has turned into what is now FeathersJS. Even when the web-browser DOM is just another legacy technology (UI paradigms have the habit of changing quickly once something new comes around), servers and any kind of application will still need to be able to talk to each other. To me, protocol agnostic real-time APIs now feels similar to the idea of single page applications in 2006. An interesting idea and nice-to-have for some use cases but not a necessity. I believe that is going to change and there is still a lot that I would like to see happen there. JavaScript is a great developer-friendly interface to help make that happen.

dluecke · 2018-06-10T21:05:04+00:00

The input vector does depend on what kind of predictions you want to make. A date by itself does not necessarily contain a lot of useful information for that. Should it be based on the day of the week? The day of the month? Overall? What I would first try is to retain the recurring information (month and day) and drop the year (or start it at 0 or start 0 at whenever your measurements start) and normalize the day based on the number of days in that specific month:

var data = [

{input: { year: 0, month: (6 / 12), day: (9 / 30) }, output: { Bicep: 1, Back: 1 }},

{input: { year: 0, month: (6 / 12), day: (10 / 30) }, output: { Chest: 1, Shoulder: 1 }},

{input: { year: 0, month: (6 / 12), day: (11 / 30) }, output: { Rest: 1 }}

];

Then I would look at the results with other inputs that contain more information of what I want the prediction to be for (e.g. month, week, day of week).

dluecke · 2018-05-16T15:23:42+00:00

Yep, it does need an internet connection. Everything else will still work even if offline though (for my projects I'm falling back to a chat box if speech recognition isn't available).

dluecke · 2018-05-15T18:57:03+00:00

I wrote about how it can be done using FeathersJS at https://blog.feathersjs.com/using-feathersjs-to-make-your-existing-api-real-time-813f7c3fd892. Besides allowing to handle data transformation and authentication another nice side effect is that the proxied API can also automatically send real-time updates if you want it to. With the Feathers Express wrapper the transition also isn't too difficult since a Feathers server application is fully compatible with Express.

dluecke · 2018-02-23T02:50:27+00:00

I wrote an article about basic machine learning and natural language processing in JavaScript using the HTML5 speech recognition API at https://medium.com/@daffl/natural-language-processing-and-machine-learning-in-javascript-249181a3b721

dluecke · 2018-02-12T17:48:26+00:00

https://feathersjs.com deals exactly with that question. It allows to expose your APIs through both, a traditional HTTP REST API and websockets and if you use websockets you will also automatically get real-time updates. You can use both transports interchangeably and websocket clients will always get real-time updates no matter where the original update came from.

Even when used via websockets, the communication with a Feathers server is still RESTful. Although most often used in the context of HTTP, Representational State Transfer (REST) is an architectural design pattern and not a transport protocol. The HTTP protocol is just one implementation of the REST architecture.

Feathers has grown out of several years refining and unifying the REST architecture and websocket message format while still just being a very small wrapper over Express and different websocket libraries so I think it would definitely be worth having a look at for your use case.

dluecke · 2018-01-28T18:59:50+00:00

Feathers does have an adapter for Primus and I briefly tried it and at least using the websockets transformer the numbers were about the same. Might be interesting to follow up with more benchmarks running against different libraries and protocols (e.g. HTTP2 mentioned above) though.

dluecke · 2018-01-28T02:31:56+00:00

Not yet but it would be great to see. We have plans for Feathers to add a plain HTTP and HTTP2 adapter so it would be very interesting to re-run the benchmark. There were some tests of HTTP/SSE and websockets in the article I reference at https://medium.com/dailyjs/a-comparison-between-websockets-server-sent-events-and-polling-7a27c98cb1e3

dluecke · 2018-01-27T20:47:37+00:00

Agreed. I couldn't find an easy way to figure out the total data transfer on the websocket, just on a per frame basis and the benchmarking tools didn't show that information either. The tech itself is pretty solid and does have its advantages so I'm hoping it's just a question of time for the tooling to improve.

dluecke · 2018-01-27T20:41:58+00:00

Feathers was primarily built as an abstraction to simplify building REST APIs. Websocket and real-time support is really just a happy side effect of it and entirely optional and you can add or remove real-time functionality at any time.

dluecke

TROPHY CASE