Namespaces and App structure

Apps Script (advanced level) posted on 8th Jan 2018


Take a moment to read these if this is a new topic for you.
Code is on github

GasThreader structure

Gasthreader is a  published Apps Script webapp. I considered making it a library but decided that the best approach was for you to take the template and modify it for your own app. There are a heap of script files in the project, but luckily, there are only 2 or 3 you have to modify, and these all run Server Side. 


  • Job contains the Work package
  • Orchestration contains the functions that will be called from the Work package and which retrieve and save the chunks of data for each thread
  • FusionToDb is the namespace that contains the specifics of my App. This would be whatever it is you are trying to do and can be many namespaces, or you can include all that the Orchestration namespace, and of course call it whatever you like. 
For re-usability and ease of testing I recommend you make separate Job and Orchestrate work spaces, and keep the specifics of what your app is doing separately - just like this pattern.

Notes 

Bear these tips in mind when creating your app
  • Test your specific app functions first - and structure them so they mirror stages that depend on each other, passing data from one stage to the other.
  • Create your work package stages once your app is working on a small data set.
  • Include parallel running if you can. It'll run faster overall, but bear in mind that you might hit rate limits if you are using services that measure things by user.
  • If you have very large data sets, use skipReduce in the work package - you'll read more about that in the next section
  • Keep your Orchestration code to a minimum - that way you can test what's flowing between stages using logReduce before plugging in your App logic.
  • Remember that threads run in parallel and asynchronously. They may finish in any order, and you won't be able to access the results of any chunk until all the chunks in a stage are completed and reduced. You don't have to worry about the asynchonicity, and can write your code as if it was being invoked as part of a synchronous process.
  • Visit my desktop liberation community if you get stuck, and do post about your successes as well as your problems.
  • Watch out for updates. I'll be adding restarting at some point.

Namespaces

I always recommend using namespaces to separate logic, encourage reusability between projects and for general cleanliness. This is the namespace pattern I recommend.

var yourNamespace = (function (ns) {

    // always have an init to ensure you can control execution order for dependencies
    ns.init = function (args) {
        // .. do some stuff
    };

    // encapsulate namespace settings in the namespace
    ns.settings = {
         yourParam1:100,
         yourParam2:200
    };

    // namespace methods look like this
    ns.yourMethod = function (args) {
          return something;
    };

    // dont forget this at the end of the ns.
    return ns;
}) ({});

 In your work package, which I'll get to next, you would define the execution of something from your namespace like this.
    instances: {
       nameSpace:"yourNamespace",
       method:"yourMethod",
       arg:args
    }

Executing global functions

Although I don't recommend it, there may be times that you want to schedule running a function in the global space.

function yourGlobalFunction (args) {
    return something
}

This can be specified like this in the work package
    instances: {
       nameSpace:"",
       method:"yourGlobalFunction",
       arg:args
    }

Changing the Orchestration namespace name

By default this namespace is expected to be Orchestration. You can change it in the Store namespace to something else if you really want to.

  // work info - need this to get started
  ns.orchestrationNamespace = "Orchestration";

Next

 Why not join our forum, follow the blog or follow me on twitter to ensure you get updates when they are available.

Comments