Massive JS
JS application development at an enterprise levelĀ
EF Labs (Shanghai)
Defining Massive
Big is something like jQuery - a few modules, one-five maintainers, all modules synced in one release.
Large is something like GitHub - many separate modules, a few teams working in separate areas, but one core front-end team focused on the whole website.
Massive is something like GMail - many applications in one page, many different teams collaborating, separate release cycles per team and application.
These numbers are examples that I just invented about a minute ago, don't be emo about it.
N applications - N teams
1 experience
In the usual enterprise environment we see many applications maintained by many different teams.
A lot of the time these teams are not in the same group.
- or the same department
- or the same office
- or even the same company
So naturally code changes and releases are a P.I.T.A and are rarely communicated well.
But we still want it all to be one integrated and consistent experience.
All your modules
are belong to us
The first rule of massive scale
JS application development is modularization.
The second rule of massive scale
JS application development is modularization.
Everything should be a module
- your code
- your templates
- your styles
- your data
Develop small
Make modules as small as possible
(without fragmenting your code to much)
- easy to read ...because there's less of it
- easy to maintain ...as it's easier to debug and fix
- easy to use ...and modify ...and extend
Make sure your modules apply Separation of Concerns .
Deploy bigish
Use a build tool to bundle modules that make sense in your context.
- Common reusable code packaged in a separate bundle.
- Applications packaged in multiple bundles, by function.
- Massive application should be split into smaller applications.
On the server there's really no need for bundles.
For web go with multiple bundles, for mobile go with one.
Decouple
Or why a message bus rocks
Let's try to learn something from our friend / foe
the back-end developer
In massive systems (and probably everywhere else) small, modular and distributed always beats large, monolithic and centralized
This is why we have EIP , ESB and micro services.
Actually, this whole REST thing was invented for server to server integration way before all you DHTML kiddies came along with AJAX .
What about the front-end?
Similar patterns can be applied in the front-end to, but instead of just connecting to the back-end, we connect components.
Request-reply is fine, but fire-and-forget is better.
You are probably already doing (some) of this with DOM events and event bubbling.
A good rule of thumb
When you are talking to a logical parent component use DOM events, when talking to any other component use a message bus
Integration
One of the advantages of using a message bus is that components can subscribe to changes without affecting the whole application.
It also also allows the developer to swap out implementations of components without having to update all the dependent applications.
If you think about it, you can actually mock an entire component or application from the message bus, thus getting the same benefits we get when we mock the back-end.
Be async
Asynchrony, in the general meaning, is the state of not being synchronized.
- Wikipedia
Unless you are sure whatever you are doing
is and always will be synchronous
go async.
Because things change:
- Your connection speed.
- Your connection reliability.
- The weather.
- Solar flares.
Be event driven
Most of you are already doing this:
But you should think bigger:
Be expressive, declarative
and stay DRY
Don't forget to bring a towel
- HGTTG / Towlie
- Be expressive - name your methods, chain operations, think about your URL structure.
- Be declarative - what do we want to do instead of how do we do it.
- Do not repeat thyself!
In the end it's all about congnitive load.
So we split our code into modules that are used in our applications then package them into bundles. What now?
The root application
AKA
the one application to rule them all
- Is the only guaranteed singular application.
- Is responsible for managing common services.
- Is the container for other applications.
For example:
If you are GitHub , and you bubble DOM events like a drunken sailor , and you catch them all at in one place
you would probably call that piece of code the root application|controller|router|whatever
Questions?
Massive JS
By Mikael Karon
Massive JS
- 951