boilerplate -> neomonolith framework

[ahdinosaur]

• at the moment, this repo is boilerplate for someone starting a new project, but also means we have to separately maintain all our projects that use this stack (upgrading dependencies, etc). i'm keen to move this repo to become a "framework", as in a grabag module that provides all the necessary sub-modules and opinions to build consistent apps and reduce boilerplate.
• long-term we want decoupled decentralized micro-services 0 1 2 3, short-term compromise is neomonolith
• composable, re-usable modules
  • feathers services
  • tcomb types
  • redux { actions, reducers }
  • react components
• assembled monolith apps
  • modules
    • automatically wire up { services, reducers }
  • routes
  • pages
  • style variables
  • config (environment variables)
  • database
• open questions
  • (how) do we export the dev / prod npm scripts?

strawman:

// api.js
var Api = require('business-stack/api')

var api = Api({
  config: require('./config'),
  modules: [
    require('business-authentication/api'),
    require('./trees/api'),
  }
})

// app.js
var App = require('business-stack/app')

App({
  config: require('./config'),
  reducer: [
    require('business-authentication/reducer'),
    require('./reducer')
  ],
  router: require('./router')
})

/cc @iainkirkpatrick

[ahdinosaur]

we want fractal apps.

so maybe we want to follow the semantics of Redux reducers, where each fractal app exports an object describing the functionality of that app, which we can combine (reducers, routers, services) using something like combineReducers into a larger app, eventually passing into our top-level runner like createStore.

[iainkirkpatrick]

adding my current thoughts partly as a personal marker (something i can come back to later when i no doubt know better :D ):

i can see a couple of wins that struck me with staltz's article on fractal apps. each 'app' would have similar enter and exit interfaces, which gives a level of familiarity to the dev (whether that's Observables as with Staltz's Dialogues, or an Object of 'functionality', etc). feels like it should cut down on wastage of modules / result in less fiddling around the edges of modules to get compatibility with several apps.

(so i wonder, would a 'common' abstraction over Dialogues, functionality objects etc be a cool idea?)

another win that struck me was ideally the ability to create standalone 'apps', that are runnable, testable, everything-able in their own right, and can also be plugged in to higher-level apps (and are composed of lower-level apps?). in that way, as a dev I can clone an app, spin it up, poke around, see how it works (and what it 'looks' like), and then use it in a larger app if i want.
chatting with @ahdinosaur i think i was over-thinking how this might work in practice with redux-like architectures... i.e. doesn't a redux app need a store created to reduce to? how will i test an app without including code in the app that creates a store, but when it comes time to 'plug it in' to higher-level apps I don't want it to have it's own store? but actually, i guess the repo for an app just has it's object of functionality that it exposes, and a separate file that creates a store, wires up etc if the app is RUN rather than COMPOSED. i think :)

any other fractal wins?

other questions:

• is there already research on fractal apps? seems like a cool idea that many must have thought of...
• the whole 'apps all the way down' idea where each app could have it's own contained functionality and views seems real similar to @ahdinosaur's thinking on tcomb-types and associated views... so maybe we actually just talking about composing nested layers of types and their views? (which are then somehow styleable?) this is still a bit fuzzy for me but an idea that is intriguing!

[justingreenberg]

i just stumbled across this project, awesome work! i'm also loving this idea. my recent attempt at a simple fractal architecture, similar to what you guys currently have: dvdzkwsk/react-redux-starter-kit#684

i would just suggest something more general than "reducers" for client app in your strawman example... such as a bundle of actions, reducers, and anything else that requires store... ie

// api.js
const Api = require('business-stack/api')

module.exports = Api({
  config: require('./config'),
  modules: [
    require('business-authentication/api'),
    require('./trees/api'),
  }
})

// app.js
const App = require('business-stack/app')

module.exports = App({
  config: require('./config'), // middleware / store enhancers (ie redux-saga)
  providers: [
    require('business-authentication'),
    require('./app')
  ],
  router: require('./router')
})

// app.js / business-authentication/index.js
module.exports = {
  actions: require('./actions'),
  reducers: require('./reducers'),
  sagas: require('./sagas')  // based on user config 
}

// sagas.js / business-authentication/sagas.js
module.exports = (store) => {
  store.sagaMiddleware.run(saga)
}

// reducers.js / business-authentication/reducers.js
module.exports = (store) => {
  store.injectReducer(reducer)
}

have you seen https://github.com/loggur/react-redux-provide? (interesting but a little heavy imo)

another concern with the current setup (which would be solved by this solution) is the lack of webpack for bundling/code-splitting, is there a reason you guys aren't using it? have you considered moving away from browserify?

[ahdinosaur]

hey @justingreenberg, your fractal app RFC looks awesome, thanks for sharing. 😄

as soon as possible i'll try and write up a more complete RFC here, my initial strawman was just thrown together as a placeholder.

have you seen https://github.com/loggur/react-redux-provide?

nah, but indeed interesting.

lack of webpack for bundling/code-splitting, is there a reason you guys aren't using it? have you considered moving away from browserify?

i much prefer browserify over webpack, for these reasons. i'll make an issue to support code splitting via factor-bundle.

[ahdinosaur]

ooh, i stumbled on rill, which applies a pattern i've been meaning to try. could be a simple way to do fully isomorphic code across server and browser.

[ahdinosaur]

okay okay, new direction! 🎱

cat-stack becomes a grab bag module of grab bag modules:

• inu: simple composable unidirectional user interfaces using pull streams
• TODO uify: an opinionated set of tools for front-end user interfaces using browserify.
• chur: simple composable data-driven micro-services using pull streams
• TODO: apies: an opinionated set of tools for back-end micro-services using docker.

[ahdinosaur]

so... this happened.