Shell section should probably reference using shelljs module with node scripts directly. If you're already using node, this normalizes very well across platforms.
Other than that, pretty much every gotcha I've come across is there.
Does this support use of the Cluster module? IIRC, when I looked at gRPC in node a couple years ago that was a major limitation in practical use for me.
Meh... while I do think that using array methods map/reduce/filter etc are generally a better idea from being able to understand code over for loops... there are many cases where the for loop options are better. Serializing requests or other queue handling in async functions as an example. Async generators (ES6 Streams with for-async) being another.
I do like the interface overall... I do think the isStale resolver should be passed the key and datetime for when the item was placed in cache.
https://github.com/DominicTobias/keshi/issues/1
This is cool AF... combined with Context, you could pretty much replace redux and react-redux... although there's a huge third party ecosystem around the two now. It's nice to see these options in the box, and especially working with functional components.
I would also suggest posting this in /r/javascript since it's likely to be seen by more people.
- I would suggest updating the codebase to use ES6 module conventions and use rollup for your build process over gulp+browserify
- Add a youtube-link that generates an appropriate embed option
- Add wrapper components for Angular, Vue and React
Aside: I'm not sure how much draw you will see for a "pro" version, but good luck to you.
I really wanted to like ngrx, it just felt like too much for the common use case... similar to redux-saga and similar combined effects. The simpler angular redux adapters are a lot easier to use imho. That said, I also generally feel vitriolic hate towards Angular, so avoid it as much as possible. Love react, like vue.
In general, my suggestion is via webpack+babel to do two build configurations. One for "modern" browsers (async/await support an higher) and one for "legacy" browsers (everywhere else). Modern ones are fairly easy to detect server-side and inject the correct entry point(s) into your html delivery.
In the top of my "modern" entry, I do a test for async/await, and if it fails, will set a cookie and `location.reload()`. This forces legacy should it not have detected properly. In the end, without most of the polyfills or the corejs bits there's a huge savings in overall size, and load.
My current work is mostly internal applications, where I don't have to work around supporting legacy browsers fortunately. Even keeping firefox + chrome happy is enough work in some cases.