- Load balancer fronting monolithic application
- Begin to decouple services into microservices and place another load balancer in front (kubernetes service)
- Soon multiple services in cluster each with own load balancer
- Each have own rate limiting, logging, authorization
- Leads to expensive maintenance (many individual load balancers etc)
5% - Scheduling
- Use label selectors to schedule Pods
- Understand the role of DaemonSets
- Understand how resource limits can affect Pod scheduling
- Understand how to run multiple schedulers and configure Pods to use them
- Manually schedule a Pod without a scheduler
- Display scheduler events
- Know how to configure the Kubernetes scheduler
5% - Logging/Monitoring
Application Lifecycle And Management
With THREE.js, you need to instantiate several objects each time you use it. You need to create a Scene, a Camera, a Renderer, some 3D objects, and maybe a canvas. Beyond that, if you need controls, maybe you setup DAT.gui
like the examples use.
The Renderer needs a reference to the Camera and the Scene. You need a reference to the Scene to add any 3D objects you create. It's up to you how to structure everything cleanly.
In contrast, React devs are now used to the ease and simplicity of using create-react-app
to try things out. It would be great to have a React component you could throw some random THREE.js code into and have it work!
Thinking further, imagine if you could somehow treat THREE.js scene objects like React components! What if you were able to write THREE.js code like this:
var mongoose = require('mongoose') | |
, testClient = require('api_client') // npm link'd | |
; | |
mongoose.connect('localhost', 'delete-me'); | |
testClient.getItems({name: 'foo'}) | |
.then(function(){ | |
console.log(item); | |
}); |