Rework #85
Description
Rebirth & Rework
- rewrite from scratch
- ES6 / eslint standard config
- ES7 stuff, decorators, di (experimental)
- make / npm run scripts as default built tool
- popular build tools adapters (grunt, gulp, etc.)
- "progressive" / "immersive" cli
- vorpal: https://github.com/dthree/vorpal
- roar: Thor roar#3 (Thor's basically rails generator backend library)
- research nowadays solution to feo done in nbs / would map needs, issues I have currently in nodejs / frontend dev.
- wepagetest: https://github.com/mklabs/webpagetest-xvfb
- docker: https://github.com/nowol79/webpagetest
Tasks / Commands
inspiration from https://www.ottoproject.io/
exemple using @tjwebb Trails project.
01. Start your Trails project: Initialize a new Trails application with out-of-the-box defaults
$ yo trails
02. Run nbs compile
$ nbs compile
Otto's compile step automatically detects the type of application as Trails and prepares Otto to manage your app's lifecycle. (You can also customize nearly every aspect of Otto's behavior by writing an Appfile)
03. Run nbs compile
Otto builds and runs a local development environment, so you can easily test and make changes to your application.
Plus browserify / babel setup with livereactload, possibly browser-sync (or just tiny-lr ?)
Plus, make sure to implement deamon / background mode using pm2 or similar.
$ nbs dev
Question How do we handle the multitude of different fwks, libs ? Going from React, to Ember or yo-yo.
There's certainly common concept in all of thems, either MVC or flux based (including redux).
Test fwk: Should default to mocha / ava really. Two awesome test fwk. Like eslint and jscs, I feel like joining forces would give a really great project. Talked with @hemanth about that (nested stuff in mocha, better error feedback and suites org, parallel / really fast for ava, mocha has native html runner etc.)
Asset pipeline (more below)
04. Construct Infrastructure
Otto creates a base infrastructure according to industry best practices.
$ nbs infra
05. Build Your Application
Otto packages your application and prepares it for deployment onto your infrastructure.
$ nbs build
Would delegate the build script part to build tool we can detect from file tree.
- Makefile
- Bakefile
- Dockerfile
- Grunfile
- gulpfile
- *file
06. Deploy
Your Rails application is converted to running infrastructure. Your app is now available to the world!
For node, we would most likely use now.sh and / or dat
$ nbs deploy
Frontend
Asset pipeline most likely using https://github.com/mklabs/tilt-assets
Processors of choice: browserify / postcss (with cssnext)
Although, its highly configurable through package.json config. They're both their own modular, transform/plugin based pipelines in their own way.
Also, babel (with sensible presets, the scaffolding system should handle that anyway)
Could use any frontend fwk, postcss plugin/transforms, same for browerify.
Also, hyperx, transforms and web components (riot, polymer, ractive, etc.). See https://github.com/mklabs/hyperx-transforms
Note:
- https://github.com/assetgraph/assetgraph looks amazing
Backend
- now.sh for easy deployments.
- pm2 for run / monitoring.
- node-cluster lighter alternative (worked on something related recently, because we couldnt use pm2)
- a logrotate friendly logger, this means listening for SIG calls (SIGUSER ?), and reopening an append stream to the file, got it working with a rather hacky reassign on debug stream option)
- automate as much as possible code structure (like adding tap test case automatically when adding a new method in an ES6 class) => needs editor tooling / plugins that uses ternjs.net (possibly esprima but the ast is hard to work with)
- small dashboard replicating win 10 task manager, using top and websocketd. basically a nice looking interface to see the load on the local machine.
Monitoring
- both front/backend. getting metrics from all kind of sources, putthing this into a local prometheus (https://github.com/mklabs/prometheus-prebuilt)
- local webpagetest, get metrics, feed prometheus
- also integrates with https://speedcurve.com/
- research on devtool remote protocol and recipes. Examples and great starting point in BigRig.
- explore ffmpeg capture to compute a speed index, get a "speed index over time", feed prometheus.
- same for profiling etc. which is now possible and really awesome.
- har
- small dashboard talking to prometheus api (https://github.com/mklabs/prometheo wip), d3 react or yoyo graphs.
apm
One possible metric would be APM. A popular metric in sc2.
CLI / Web / Desktop apps
~