ritch

import os
import shutil

import fiftyone as fo
import fiftyone.zoo as foz
import fiftyone.utils.image as foui

fo.core.dataset.delete_non_persistent_datasets()

exampleName = 'thumbnail-example'

ritch

interface Envelope {
  writeToResponse() 
}

class File extends Envelope {
  writeToResponse(res) {
    res.setHeader('content-type', this.getContentType())
    this.readableStream.pipe(res)
  }
}

ritch

LoopBack 3

Core + Boot + Connector refactor

0. setup

• all components loaded into registry
• all mixins loaded into registry
• registry mixins applied
• create models, apply model configs, etc
• create data sources

ritch

Model and Boot Scripts

Currently, model scripts and the way they are loaded are a bit naive.

Take a look at this example:

// models/my-model.js
module.exports = function(MyModel) {
  MyModel.findFooBars = function(filter, cb) {

ritch

/**
 * @module myServiceModule
 * @controller MyController
 * @inject $scope notify
 */

$scope.callNotify = function(msg) {
  notify(msg);
};

ritch

var $ = exports

$.GENERATORS = [
  'package',
  'app',
  'error',
  'start',
  'resource',
  'view',
  'orm',

ritch

// my existing express app

app.use(myMiddleware);

function myMiddleware(req, res, next) {
  doSomething(next); // does something async + takes a callback
}

app.get('/', function(req, res, next) {
  getHomePageData(function(err, data) {

ritch

Lessons Learned from Stateful Modules

Background

We forked the jugglingdb module to create loopback's orm. Jugglingdb allows you to define models and the relations between them. One of the fundemental mechanisms that it uses to do this is the type registry.

You can see this implemented in the original jugglingdb project

exports.Schema = Schema;

ritch

Here is a basic (truncated) callstack for a REST request to loopback.

• GET /users
• loopback.rest()
  • loopback.token()
  • Model.checkAccess()
  • sharedMethod.invoke(argsFromHttpCtx)
    • User.find()
      • connector.find()
        • driver.find()

ritch

Will it be possible to use continuous replication, so the client immediately triggers a replication when local data changes. And the server uses a push mechanism?

Yes... here is a basic example that relies on a socket.io style EventEmitter.

// psuedo-server.js
MyModel.on('changed', function(obj) {
  socket.emit('changed');
});