There are some really big changes that are starting to unfold across the web ecosystem in the next few months, and we have a rare opportunity to affect a major change to the way that we perceive and build software.
This route captures all of the influences on this system
There has been a trend in the node.js community towards api's that are built around the concepts of data as streams, and in the last 2 years this has accelerated giving rise to some very expressive and powerful tools.
At the same time, war stories from the architects of distributed systems have started to filter into the collective psyche of developers everywhere, and only recently managed to settle on the name 'microservices', as a way of disseminating what is basically tribal knowledge.
The browser environment was untouched by these advancements, because when it came down to brass tacks, the DOM is the most complex form of shared state that most developers will have to interact with in their lives.
MicroServices and Streams are basically functional in nature, and there was an impidence mismatch because of the functional avoidance of state.
The reason famo.us is revolutionary has almost nothing to do with it's rendering speed on mobile devices. It's definitely a good feature, but it's not even remotely what famo.us is about.
Famo.us has taken the position that any layout or positioning should not be happening in the html/css anymore, and should instead be controlled by javascript.
-
Famous wraps a Surface object around each element/div it controls.
-
These Surfaces are used to build out a Scene Graph (ie: tree of surfaces )
-
By putting the layout into JS, it has flattened out the DOM almost completely.
-
Famo.us calculates the absolute positions for every surface in the graph.
-
It does these calculations fast enough so that the browser can render at 60fps
-
This calculation is a simple linear transform, that is completely composable
oldprops | transform | newprops
This change has brought the server and the client into closer parity than ever before. Suddenly, approaches that worked on the server are far more viable.
It's the synergy between these three occurences that excited me the most though. This is going to allow us to deliver some very powerful solutions in the future.
We are going to reach out to the maintainers of the various libraries that we consider important, and have open and honest communication about the ways in which our individual visions align.
As we bring each set of developers into the fold, we will seek to learn and solidify our messages based on the experiences and concern they share with us, until we are confident that we have the right answers to all our questions.
We will build and agree on a very simple microservices implementation, that could be used to interact with all of the libraries we consider to be important.
The required code is very very simple and the entire scope begins and ends with being able to make and provide microservice calls.
We will test, and extensively document how an application that works along these terms works, but we will not enforce any of the choices that need to be made.
Microservices are fundamentally about making a small asbtract between the function that accepts or generates the message, and the one that actually receives it.
- Transport (local function default .. REST + more)
- Serialization (json default, AT LEAST PROTOBUF TOO, prolly xml, csv?)
- Service (the function called when triggered)
// in terms of your average express route
// it's specifying the abstraction
app.get('/path', serializeJson(serviceFn))The api is very very small, but it will have these consistent guarantees, which are all convention, but not assumption
- Everything is based on streams, with some of the properties of vinyl / highland.js.
- You have some consistent way to name/route messages (probably a url)
- Transports are required to meet at least the capabilities of REST (so they can do uploads)