Cloud and Mobile

Working seamlessly online/offline when developing your Web applications with the Forge Viewer

By Philippe Leefsma (@F3lipek)

    Whether you are a frequent traveler or not, if you are developing a Web application using the Forge Viewer chances are that at some point you may be interested in doing offline viewing, that is loading your models not from the Autodesk Cloud but from the local machine. I can see various advantages of doing that: the first one obviously is being able to develop and work on your app with no internet connection at all, but even if you do have a connection, you may enjoy faster loading time of your model when you have to repeatedly reload the scene to see your code modifications when working on a viewer plugin. Other customers may be interested in running a viewer application in a closed environment  or behind firewalls of their company with no http calls to the outside world. The offline approach applies to this type of requirement as well...

    My application is using the following technologies: NodeJS server, mongoDB database, RESTful API, React and ES6 for the building the frontend. The details I'm exposing here relate to that specific stack, however the concepts I am discussing in that post should easily apply to any other backend/frontend stack combination you may use on your side.

    Here is the general idea of the workflow: you first need to upload and translate the models you want to view offline. Typically when you develop your application, one or a few different models can be used for testing purpose, so you won't have to store locally all the designs your app is working with. Once you have your local models, they can be served as static resources by your server. You use the database to store information about each model, including a specific field that indicates if the model is local or Cloud-based. The bootstrapping JavaScript code that initializes the viewer will first look at the info in the database prior to load the model and either perform local or Cloud initialization. That way when using the local database in dev, models will be loaded from the local files and when your app is connected to the production database, models will be loaded from the Autodesk Cloud. All of that being transparent to the JavaScript code in your app.

    Here are the detailed steps you can follow to get that set up:

 1/ Upload your design to Autodesk Cloud and use the Model Derivatives API to generate the svf viewable format: see our Prepare a File for the Viewer step-by-step tutorial

 2/ Upon successful translation, download the design package locally. You can use the following npm package for that: view-and-data-npm. Even if it is still relying on the V1 API, it does the job. See the "Offline" section in the readme

 3/ Populate your mongoDB database with the correct records. In the case of my app, it is using a models collection with the following schema for each record:

 1 {
 2       "_id" : ObjectId("57efaf0377c8eb0a560ef467"),
 3       "urn" : "dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bGVlZnNtcC1mb3JnZS1kZXYvZW5naW5lLmR3Zg",
 4       "name" : "Engine",
 5       "path" : "resources/models/engine/0.svf",
 6       "env" : "Local",
 7       "options" : {
 8         //some app specific options
 9       },
10       "thumbnail" : "... base64 encoded thumbnail of the model ... "
11     }

     The path field has to point to the location of the .svf file in the static resources route server by your server

    the env field has to be set to Local for offline viewing and AutodeskProduction for Cloud-based viewing. That is the only field that is changed between my development  and production databases

 4/ You also need a complete local copy of the Viewer API files. There is more than the .css and .js you would reference in an online setup. The Viewer will dynamically fetch the extra scripts and resources needed once it gets loaded. It will look for those file relatively to the viewer3D.js or viewer3D.min.js that you loaded in your app, so if you keep the file hierarchy of the lib, things should be ok. You can find all the required files for the v 2.10 of the API in my project.

 5/ The rest of the job will be handled by the JavaScript code initializing your viewer application based on the env field set in the DB when loading a specific model. You will pass that value to Autodesk.Viewing.Initializer and let the viewer lib do the initialization. Below is the code that I'm using to seamlessly load a design offline or online. You can notice that in the offline case, we already know the viewable path that we want to load. In online case you need to first load all viewable path and select the one you want to load - in case your document has multiple views - my code here is simply loading the first viewable path, but you can tweak that based on your needs:

6/ I am using an .ejs template to generate my main html layout, this way when creating a dev build of my app, it will use the local viewer3D.js and when creating a prod build, it will reference the online version. The template is being generated by the webpack build, you can see my build config there.

    Having worked with the viewer API for a while now, I came to use that setup by refining my experience with those tools and I find it pretty convenient so far.

    The complete project applying all those concept is located at:
https://github.com/Autodesk-Forge/forge-rcdb.nodejs

Using the Forge Viewer in a React Web Application

By Philippe Leefsma (@F3lipek)

    React - arguably the best front-end technology to built medium to large-sized web applications at the moment, says the JavaScript community. Unlike other tech out there from the JavaScript jungle, React is focusing only on the View part of the MVC pattern, bringing more flexibility to the developer choices. Components that you write in React and that you use in your app can be seen as interchangeable building blocks, a bit like what we intend to provide with the Forge Web API's. Well written components should be de-coupled from app main architecture and can be updated, rewritten, or replaced at no or small cost for the developer. In the current JavaScript ecosystem where things are evolving so quickly and new technology show up every other day, I definitely see that coming handy... Who wants to rewrite his entire application as your main framework is bumping major version? Not targeting any specific tech here ;)

    I was asked to write a demo web app to illustrate how to integrate seamlessly database information graphically with the Forge Viewer and decided to start on a clean base with a React application. The challenge when using React is to get your app architecture right because you have more choices to do and more moving parts. I knew I wanted to use Redux, to manage my app state, but that still leaves a great deal of choices to be made. After some research I stumbled accross that boiler plate: https://github.com/davezuko/react-redux-starter-kit. Over 6000 stars on github and recommended by Dan Abramov, creator of Redux - you can't go wrong with such references!

     I will post regularly my React tips, tricks and experiments as I go along with that project, but I wanted to start by showing how to use the Forge viewer in a React app. This post does not intent to be a tutorial on how to get started with React, you will find already so much resources on the web for that, so if you are not familiar with the technology, I recommend you spend an hour or two taking a look at the basics.

    The viewer is somehow different than - let's say - a classic web component because you can instantiate viewer3D object  only after the containing div has been appended to the DOM, so my code is using a little trick to reference that div from the component, see the render method. The rest of the code is pretty straightforward as far as the Viewer component is concerned. I tried to keep it as a strict minimum but provide methods to initialize the environment and load a document from its URN, so a maximum of control can be delegated to the controlling component while keeping the Viewer component flexible and easily reusable in any other project. But enough talking, here is the code of the Viewer React component in my app, links to the complete code on github and the live demo:

https://github.com/Autodesk-Forge/forge-rcdb.nodejs

https://forge-rcdb.autodesk.io

Here is a screenshot of the app featuring the Markup3D extension:

OSS Resumable Upload - Minimum Chunk Sizes.

The minimum chunk sizes recommendation for the OSS resumable endpoint(s) is a recommendation is 5MB ( and in certain cases, maybe adjusted to be no lower than 2MB in chunk size ).

However, we were not enforcing until now. We will be making changes to OSS to enforce a minimum chunk size ( 2MB chunks ) but we are still recommending a 5MB or greater chunk size.

Only the last chunk (identified by range covering the last byte in the total bytes of the object) will be allowed to be smaller than the 2MB limit.

Integrating Sphero BB8 Droid with View & Data API - Part II

By Philippe Leefsma @F3lipek

In the first part of this on-going series I was taking a look at controlling the Sphero BB8 droid from a local webpage just to get my feet in the plate. I spent the last couple weeks working on a better IoT oriented sample using a more realistic architecture. 

Here is the idea, there are three main components to the project:

• A node.js server sitting in the cloud and listening for incoming connections

• Local controllers running an instance of a node.js script which connects to the cloud server. Those controllers can be any device able to run node.js code and with a bluetooth BLE-capable adapter. It can scan for surrounding BB8 devices and send back that information to the server

• A webpage served by the same cloud application that allows a user to visualise each controller and each device, then connect to any device and send commands to it through the appropriate controller

The diagram below illustrates further the concept. By the way I was using https://www.draw.io to quickly draft it and it looks really handy:

 

The connection between server and controllers is achieved using socket.io, so pretty standard node.js event oriented implementation. The most remarkable feature - if I may say so - is that I wrote the code using Es7 async feature, so it needs to be transpiled, which can be done on the fly when running the scripts. It is also highly promisified in order to get rid of the callbacks and leverage the async syntax.

The implementation is mostly contained in some "service" classes on the server and the controller, which are then used inside thin wrappers. Below are the implementations of the IoTSvc (server side) and the SpheroSvc (controller side):

The UI and interaction with the viewer is the part I have a bit left behind at the moment: the model is actually not being updated if several devices are connected and no feedback is sent from the device to update the location in the 3d space.

It only exposes a panel which allows to visualise connected controllers and available devices, as well as a control panel for the BB8 device. The last enhancement was to play with automated path, so the droid is moving along a predefined path, in that case a square trajectory.


The next goal would be to play with data acquisition feature of the device (position, velocity, ...) and see if it can send some useful information in order to adapt trajectories for example. Also implement basic intelligence, thinking about contouring obstacles, sending video stream using HTML5 APIs is as well on my plate ...

You can grab the whole code from https://github.com/leefsmp/bb8

That little recording was shot in the office this morning, with the help of Kean's droid. Both devices are being controlled from https://iotea.herokuapp.com and affected to a square trajectory

I Make Changes and Nothing Happens

Things are going great. You have figured out how to upload a file, how to translate it, and maybe even add an extension or two in the viewer. Then it happens. You make a few changes in your design model or code and when you view the new version on your website site, nothing has changed.

Your fix isn't fixed. Your change isn't changed. NOTHING HAS CHANGED! You want to scream, pull out your hair, pound on your computer, and shout blame.

 

Hang on. Calm down. A great many errors are in fact mistakes born of haste. Even if you're operating under a tight deadline, try to remain calm, and collected, as you proceed. It will help. If you start to get unduly tense, or frustrated, simply get up and walk away for a few minutes. Sometimes all it takes is a fresh, rested pair of eyes to spot a missing semi-colon, or an extra quotation mark, or two to realize that the solution is much simpler than you originally thought. The problem might be with the viewer, it might be with your database, it might be with your server, or it might be something you did to screw things up, but the reality is that a lot of the time it is none of those things. The culprit is probably your Internet browser. Whatever the problem is, we're here to help.

Let's look at the possible problems and solutions for what to do when you make a change and nothing happens.

 

The Browser Cache

Did you know that a computer is supposed to make your life easier? Less complicated? It is supposed to save you time and energy and actually improve your life. No? Well, maybe not, but your Internet browser does its best to try to make your life a little easier.

When you first visit a web page, it often takes a while to load, right? But the next page you visit within that site doesn't take so long to load. This is because, in an effort to be helpful, the browser stores the information on your computer so it reloads it from your computer, not from the actual site. This is called the cache and it is meant to speed up your Internet browsing.

The problem comes when you make a small change to your site and the browser doesn't recognize it as a significant change, so it reloads the same page you just looked at. The solution is to clear or empty your browser's cache.

 

Clearing the Browser Cache

Normally, to see the changes on your page, you click the Refresh button on the browser toolbar or press the F5 key on your keyboard. In many cases, this simply reloads the page without clearing the browser's cache. There are some techniques to wipe clean the browser's cache so you will see the changes when your page reloads. On Chrome, I added a shortcut plugin to do the work, it is call 'The Clean Cache Shortcut', but there is equivalent solution for the other browsers such as the Ctrl-Shit-R for Firefox, and etc... Just try this before anything else.

 

Server-side Caching

Sometimes, your server might cache code/pages as well, or if you're running Node.js, you need to restart the server to see teh changes. It is always a good idea to disable server cache while developing. But make sure to test it with cache enabled before going on production.

 

Viewer caching

During the last Acceleartor in Praha (Czech Republic), I worked with Marius-Mihai Golea
from Stabiplan,  on a solution using the View & Data API, and Marius-Mihai had a cache issue when re-loading a different version of a model using the same URN.

It is true that if you use the same bucket/filename, the URNs will be identical, and to speed-up your viewing experience, the Autodesk viewer cache the information for 24h. So if you try viewing a changed URN, you'll immediately end-up seeing the same model again and again, unless you clear your cache.

After debugging the viewer code, Marius-Mihai came out with a very neat solution which does not require you to clean the cache manually. His solution was to modify the viewer header request like this:

Autodesk.Viewing.HTTP_REQUEST_HEADERS ={
"If-Modified-Since": "Sat, 29 Oct 1994 19:43:31 GMT"
} ;

Very efficient and simple,

This is only needed when you modify and re-translate your design file again and again in your workflow within the same session. The advantage of this technique is that you are not really cleaning the cache, you only force the viewer to reload the model definition from the server vs using the cache.

Cleaning the cache wasn't a solution in this case even if it would have helped. Marius-Mihai addressed the real issue vs hiding it.

 

Special thanks to Marius-Mihai for sharing his solution with us,

Become a Java EE developer - Part II: Basic RESTful API from a servlet

By Philippe Leefsma

Here is the second part of my Java EE tutorial series. Last week I took a look at setting up a Tomcat server and creating my first project with Eclipse. If you missed it, take a look here and make sure you are familiar with the basics.

The next step would be to create a RESTful API so our future web application will be able to easily talk to our backend. I want to start from the scratch to understand the challenges, so instead of using one of the many existing REST frameworks, I decided to implement myself a REST API using a simple servlet like the one I created last week.

I'm going to create an API that will perform the following tasks and look as follow:

- Get the list of models from our database or get a specific model based on its id:

    GET /models

    GET /models/{id}

- Add a new model to the database:

    POST /models

- Update an existing model in database:

    PUT /model/{id}

- Remove an existing model from the database:

    DELETE /models/{id}

A model will be a very basic structure containing info to load into the viewer:

So let's get started...

1/ First step is to add a new servlet to our project: right-click your project > New > Servlet. I name it "Models". By default the servlet will be mapped to the following url: /AppName/Models. We need to allow more routes to be redirected to that servlet, so edit the @WebServlet decorator as follow, so every request starting with /model will be redirected to that servlet:

2/ My REST API is going to use JSON as data format, there are some built-in classes to handle serialization and deserialization, however I'm familiar with a powerful library from Google: GSON which I used previously in some Android projects. So download the .jar from there and add it to your project: Right-click > Properties > Java Build Path > Add External Jars > browser to gson.jar.

Once you've done that, there is another trick: as your project now depends on a third party library, you need to include that in your deployment package, so it will be available when it runs on the server. No worries: Still from project's Properties > Deployment Assembly > Add > Java Build Path Entries > select gson.jar > done!

 

3/ Implement doGet, doPut, doPost and doDelete methods in your servlet. In the example below I'm using a simple hashmap to "simulate" a backend database, so it can keep track of my records, this is obviously not a real world scenario but it serves the purpose of that tutorial.

Here is a very naive implementation of my API:

4/ Finally run the servlet from Eclipse and you can use a tool like Postman to test your API:


To wrap it up: we have a working RESTful API run by a servlet, however I found it pretty laborious to parse the url to extract parameters like the model Id although it's very basic.

If we have to add some more complexity to it, let's say for example GET /models/{id}/components/{nodeId}/material to find material attached to a specific component of a specific model, then it will quickly become very messy.

Next week I will pick up a popular REST framework and take a look how much easier it can be to achieve the same, stay tuned ...

Related articles

Become a Java EE developer - Part II: Basic RESTful API from a servlet

Become a Java EE developer - Part I: Tomcat setup and my first servlet

By Philippe Leefsma

Being a complete newbie when it comes to web development in Java, I decided to take a step forward and build some expertise around JEE servers and web services. Another motivation is that we have some web technology coming up at Autodesk - more about that when it will turn public - that can be leveraged by, among other things, Java web services, so it makes sense to become a bit more familiar with it. 

I'm starting this series of posts where I will report my progresses as I learn along the path. To get started, let's take a look at running a local Tomcat server and deploy our first Java servlet.

Prerequisites:

- Java EE SDK  

- Eclipse IDE for Java EE developers

- Apache Tomcat 7

Let's start with installing the Tomcat server. I'm assuming you are running a Linux based system. I found that this blog post was very straightforward and easy to follow, so I'm simply going to copy the detailed steps, you should be able to install Tomcat on your system without pain:

1. Download a binary distribution of the core module: apache-tomcat-7.0.47.tar.gz from here. I picked the tar.gz in Binary Distributions / Core section.
2. Unarchiving the archive will create a folder structure in your Downloads folder:
   ~/Downloads/apache-tomcat-7.0.47
3. Open to Terminal app to move the unarchived distribution to /usr/local
   sudo mkdir -p /usr/local
sudo mv ~/Downloads/apache-tomcat-7.0.47 /usr/local
4. To make it easy to replace this release with future releases, we are going to create a symbolic link that we are going to use when referring to Tomcat (after removing the old link, you might have from installing a previous version):
   sudo rm -f /Library/Tomcat
sudo ln -s /usr/local/apache-tomcat-7.0.47 /Library/Tomcat

5. Change ownership of the /Library/Tomcat folder hierarchy:
   sudo chown -R <your_username> /Library/Tomcat
6. Make all scripts executable:
   sudo chmod +x /Library/Tomcat/bin/*.sh

Here is a tutorial that looks descent for Windows users.

Issue a /Library/Tomcat/bin/startup.sh from a terminal to start the server and open the following url in your browser: http://localhost:8080

You should see the Tomcat homepage:

If you try to take a look at the "Server Status" or "Manager App", it will prompt you for login and password: by default Tomcat is installed without user, so you need to create at least one to administrate your server.

Go to the "conf" folder inside Tomcat install, if you followed the tutorial "/Library/Tomcat/conf" and open "tomcat-users.xml", then add the following user, for example:  

1 <tomcat-users>
2 <rolerolename="manager-gui"/>
3 <rolerolename="manager-script"/>
4 <rolerolename="manager-jmx"/>
5 <rolerolename="manager-status"/>
6 <userusername="your-admin-name"7 password="your-admin-pass"8 roles="manager-gui,manager-script,manager-jmx,manager-status"/>
9 </tomcat-users>

You should now be able to log with the defined credentials:

Let's now shutdown the server as it will be started automatically by Eclipse when we debug our project: /Library/Tomcat/bin/shutdown.sh

Open your Eclipse IDE, if you didn't install the Java EE version of Eclipse, no worries, you can just install the required packages later on. Go to "Help" > "Install New Software..." > set the "Work with" to your Eclipse release and select the "Web, XML, Java EE, ..." category:

Make sure you have the following packages installed:

 

Let's create our first servlet: "File" > "New Project" > "Dynamic Web Project"

Then click "New Runtime" and select the appropriate server version, fill up the "Tomcat installation directory" and create the project.

Once created, right-click on the project root in the explorer > "New" > "Servlet" > put some name for your servlet and the package, I'm naming it "HelloServlet" and edit the code as follow:

package com.autodesk.adn.viewanddata;

import java.io.PrintWriter;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
 * Servlet implementation class viewer
 */
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    /**
     * @see HttpServlet#HttpServlet()
     */
    public HelloServlet() {
        super();
        // TODO Auto-generated constructor stub
    }

    /**
     * @see HttpServlet#doGet(
     * HttpServletRequest request,
     * HttpServletResponse response)
     */
    protected void doGet(
            HttpServletRequest request,
            HttpServletResponse response)
        throws ServletException, IOException {

          response.setContentType("text/html");

          PrintWriter out = response.getWriter();
          out.println("<h1>" + "ADN Servlet running!" + "</h1>"); 
    }

    /**
     * @see HttpServlet#doPost(
     * HttpServletRequest request,
     * HttpServletResponse response)
     */
    protected void doPost(
            HttpServletRequest request,
            HttpServletResponse response)
        throws ServletException, IOException {
        // TODO Auto-generated method stub
    }
}

Code Formatted by ToGoTutor

Once you are done, right-click the servlet in the project explorer > "Run As" > "Run on server" > open the page in a browser "http://localhost:8080/{project}/{servlet}" by replacing with the naming you used.

RESTful website architecture with Node and Angular

By Daniel Du

As a web programmer starting from the traditional ASP/ASP.net, sometimes my mind was constricted to the old days. My understanding of web application was how asp.net works, the HTML is generated at server side, and send it to browser to render. One guy asked me how to display some data which retrieved from server during a hackathon, while I am just in the middle of something, my distinctive response is to ask him to do something like <%= something%>, like ASP/ASP.NET does. But nowadays, it has been changed a lot, we have very different architecture – RESTful, which separates the server side and client side completely, and it also makes it easy for the server to serve different clients, including browsers and mobile devices.

Here is an architecture graph I “steal” from strongloop. As you can see, with RESTful architecture, the web server exposes some REST APIs, the client communicates with the server with REST call. This make it very flexible, the client can be a browser as a common website, it also can be mobile device like iPhone/iPad or Android phone or pad. For the browser, you can user different libraries or frameworks to build your UI, you can use JQuery, Angular.Js or anything else you like.

Let’s make a simplest sample to demo the idea, a web server with Node.Js + Express, and a browser client with Angular.Js. The idea is to make a todo list. Firstly I will create a simplest web server with Node.Js and Express. The express CLI make it really easy. If you do not have express installed, install it first with help of google. And then create a simplest express web application with express generator:

mkdir simpleWebApp

cd simpleWebApp

npm install

This will create a simplest web application with node.js and express, if you run “npm start” and go to “http://localhost:3000” you will see the first welcome page of express.

Now let’s do some simple work to add a REST API:

GET /todos   - Get all todo items

Before that, we will add some test data in JSON, in practice, you will get these todo items from a database like MongoDb. For simplicity, we make it a JSON file named as “todoItems.json”

[ 
      {    
          "task": "buy milk", 
        "complete":false 
    }, 
    { 
        "task": "toast bread", 
        "complete":false 
    }, 
    { 
        "task": "pick up newspaper", 
        "complete":false 
    }, 
    { 
        "task": "water flowers", 
        "complete":false 
    }

]

Then go to /routes/index.js, add a new route, response all todo items in json:

var express = require('express');
var router = express.Router();

/* GET home page. */
router.get('/', function(req, res) {
  res.render('index', { title: 'Express' });
});


var sampleToDoItems = require('../todoTasks.json');

/* GET Todo listing. */
//GET /Todos/
router.get('/todos', function(req, res) {

  res.type('application/json');
  res.status(200);

  res.json(sampleToDoItems);
});

module.exports = router;

Now, the REST API is ready, if I start the web application, and go to postman with GET http://localhost:3000/todos, or go to the url in browser directly, I will get all todo items:

 

The server side is done, next we will do the client side. We will use Angular.JS. Actually the client does not have to be in the same project of web server, but for simplicity, I put it together. The express has already setup the structure, the /public folder contains the static contents. I create a webpage named as “index.html” in it, and then I edit “route/index.js” file to change the route so that when I go to “http://localhost:3000/” it goes to my index.html page:

/* GET home page. */
router.get('/', function(req, res) {
  //res.render('index', { title: 'Express' });
  res.redirect('/index.html');
});

 

Let’s do the angular part, in “index.html” to include the angular js library, and create our angular module and controller. It is very simple one, so I put them into a single JS file. The idea is just to send a GET request to the web server and get all todo items, the import part is to inject the $http into the controller:

var app = angular.module('myTodoApp',[]);

app.controller('myTodoCtrl', function($scope, $http){

    $http.get('/todos')
        .success(function(response){
     
            $scope.todoItems = response;
        });
 
});

And then go to the “index.html” page, I put the important port in bold so that it is easy to follow. Firstly we need an “ng-app”, otherwise angular.Js will not run. And then put the “ng-controller” to the table, and build the table with ng-repeat="todo in todoItems", please note that the “todoItems” is populated in controller by http get request, they are completed in client side already:

     $scope.todoItems = response;

The the databind can be done by “ng-bind” or “{{  something  }}”.  Here is the complete code:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <title>Title Page</title>

        <!-- Bootstrap CSS -->
        <link href="//netdna.bootstrapcdn.com/bootstrap/3.2.0/css/bootstrap.min.css" rel="stylesheet">

        <!-- HTML5 Shim and Respond.js IE8 support of HTML5 elements and media queries -->
        <!-- WARNING: Respond.js doesn't work if you view the page via file:// -->
        <!--[if lt IE 9]>
            <script src="https://oss.maxcdn.com/libs/html5shiv/3.7.0/html5shiv.js"></script>
            <script src="https://oss.maxcdn.com/libs/respond.js/1.4.2/respond.min.js"></script>
        <![endif]-->
    </head>
    <body>
        <h1 class="text-center">Hello World</h1>

        <div class="container" ng-app="myTodoApp">
            <table class="table table-striped table-hover" ng-controller="myTodoCtrl">
                <thead>
                    <tr>
                        <th></th>
                    </tr>
                </thead>
                <tbody>
                    <tr ng-repeat="todo in todoItems">
                        <td>{{todo.task}}</td>
                        <td><div class="checkbox">
                            <label>
                                <input type="checkbox" value="" ng-model="todo.complete">
                            </label>
                        </div></td>
                    </tr>
                </tbody>
            </table>

        </div>

        <!-- jQuery -->
        <script src="//code.jquery.com/jquery.js"></script>
        <!-- Bootstrap JavaScript -->
        <script src="//netdna.bootstrapcdn.com/bootstrap/3.2.0/js/bootstrap.min.js"></script>

        <script src="//www.runoob.com/try/angularjs/1.2.5/angular.min.js"></script>

        <script src="/javascripts/myTodoApp.js"></script>
    </body>
</html>

And this is how it looks like when running the app:

 

OK, that’s the idea, very simple, of cause in practical, if will be more complex, and you can user various frameworks, like mean.io, cleverstack, sail.js.

Test REST API in an automatic way

By Daniel Du

In previous post, I learned that it is possible to integrate the build and test process automatically on new github push with Travis-CI, but as you can see, actually there is no test case yet. In this post I will keep sharing what I learned about the unit testing. Behavior Driven Development(BDD) or Test Driven Development(TDD) is very popular and recommended, which makes your code more robust and also makes you feel safe when refactoring your code.

I will start from the unit testing of the REST API, I use our basic view and data API sample workflow-node.js-view.and.data, the server side exposes a REST API to get access token, the viewer client will call this REST API to initialize the viewer and show models on web page. So I will do the unit test of the server side REST API first. There are quite a lot different test frameworks in node.js world, in this post I will use Jasmine-node and Frisby, I do not have strong oponion of these frameworks, you may have your own faverite ones, I use them just becase they come to me first :)

Install Jasmine and Frisby

If you do not have [Node.js] installed, you should install it first, I will skip this part.

Jasmine is a Behavior Driven Development testing framework for JavaScript. I am using Jasmine-node here since I am working on a node.js project. You can install it goblally:

npm install jasmine-node -g

Another test framework I use is Frisby, which is a REST API testing framework built on node.js and Jasmine that makes testing API endpoints easy, fast, as it desclimed on it's homepage. You can install it with NPM:

npm install frisby -g

To make them run on other environment, I need to add them into package.json of my node.js project so that they can be installed with 'npm install' command:

{
  "name": "AdnViewerBasic",
  "version": "0.0.0",
  "dependencies": {

    "jasmine-node" : "*",
    "frisby" : "*"
  }

Write test case and API implementation

Firstly let's write our test case with Jasmine. The convention of Jasmine is that the test case file name should end with 'spec.js', for convenience I put all the specification files into a folder named as 'spec', when I run the test case, I use following command, Jasmine will run all the '*spec.js' in this folder:

jasmine-node spec

Now I create an specification file for the REST API. To use Autodesk View and Data API, we need to create an App at http://developer.autodesk.com to get the consumer key and consummer secret, with this key pair to get the access token.Please refer to our code samples if you are not familiar with view and data API. I need to create such REST API for the access token. For example, with the HTTP GET /api/token, returns the token in JSON similar like blow:

{ token_type: 'Bearer',
    expires_in: 1799,
    access_token: 'agY5OU74WejC9fdWKZVMzsYvLYFU' 
}

Here is the simplest specification file, check whether the API end point is correct by returning HTTP status 200:

var frisby = require('frisby');

frisby.create('Get access token')
  .get('http://localhost:3000/api/token')
    .expectStatus(200)

.toss();

And here is the implementation of the token API，please find the complete code from the repo on github.

var express = require('express');
var request = require('request');

var router = express.Router();


///////////////////////////////////////////////////////////////////////////////
// Generates access token
///////////////////////////////////////////////////////////////////////////////
router.get('/token', function (req, res) {
    var params = {
        client_id:  process.env.ConsumerKey , 
        client_secret:  process.env.ConsumerSecret, 
        grant_type: 'client_credentials'
    }

    request.post(
        process.env.BaseUrl + '/authentication/v1/authenticate',
        { form: params },

        function (error, response, body) {
            if (!error && response.statusCode == 200) {

                res.send(body);
            }
        });
});

module.exports = router;

Run the test

Now it is time to run the test. Wee launch the test with following command, which runs all *spec.js files in spec folder.

jasmine-node spec

As you can see from the screen-shot above, the test failed, it is expected to get http 200, but we got 500.

Failures:

  1) Frisby Test: Get access token 
    [ GET http://localhost:3000/api/token ]
   Message:
     Expected 500 to equal 200.
   Stacktrace:
     Error: Expected 500 to equal 200.

Why? Oh, because we have not start our project yet. So we need to the launch the project in another tab of terminal, and then run the test again.

The test is passed:

workflow-node.js-view.and.data.api dudaniel$ jasmine-node spec
.
Finished in 2.406 seconds
1 test, 1 assertion, 0 failures, 0 skipped

Next, let's do more work, the token API should return a JSON result, the response content type should be JSON, so the spec should be similar like below:

var frisby = require('frisby');
frisby.create('Get access token')
  .get('http://localhost:3000/api/token')
    .expectStatus(200)
    .expectHeaderContains('content-type', 'application/json')

.toss();

If we run the test again, you will notice that the pass is failed, then we need to work on the token API to pass the test:

   request.post(
        process.env.BaseUrl + '/authentication/v1/authenticate',
        { form: params },

        function (error, response, body) {
            if (!error && response.statusCode == 200) {

                //set the content type to JSON
                res.setHeader('Content-Type', 'application/json');

                res.send(body);
            }
        });

Run the test again, now the test is passed:

workflow-node.js-view.and.data.api dudaniel$ jasmine-node spec
.

Finished in 2.27 seconds
1 test, 2 assertions, 0 failures, 0 skipped

So, that's it about basic REST API testing with Frisby, you can learn more about frisby at here. Here is my complete test case for my token API

var frisby = require('frisby');

frisby.create('Get access token')
  .get('http://localhost:3000/api/token')
    .expectStatus(200)
    .expectHeaderContains('content-type', 'application/json')
    .expectBodyContains('access_token')
    .expectJSONTypes({
        access_token : String,
        token_type : String,
        expires_in : Number
    })
    //the access token should contains {token_type : 'Bearer'}
    .expectJSON({token_type : 'Bearer'})
    .expectJSON({
        access_token : function(val) {
            //this is a valid sample access token
            var sample_token = '2974LErhmJIlyeewjp34lmfZaBpl';

            expect(val.length).toEqual(sample_token.length);
        }
    })


.toss();

Hookup the test script with npm

The continuous integration tool run the test automaticaly by running npm test, so we need to add our jasmine-node test to the package.json file as below:

{
  "name": "AdnViewerBasic",
  "version": "0.0.0",
  "dependencies": {
    "jasmine-node" : "*",
    "frisby" : "*"
  },

  "scripts" : {
    "test": "jasmine-node spec"

  }
}

With that we can run the test by following command or continuous integration tool.

$ npm test

> [email protected] test /Users/dudaniel/github/local/duchangyu/workflow-node.js-view.and.data.api
> jasmine-node spec

.

Finished in 2.585 seconds
1 test, 8 assertions, 0 failures, 0 skipped

Deploy Node.Js viewer sample to Heroku

By Daniel Du

I have been evaluating different cloud enviroment to host our viewer samples, in this post I will share my experience with Heroku, which is a Platform as a Service(PaaS) provider. The advantage of PaaS like Heroku is simplicity, we do not need to care about the infrastructure underneath, and we do not need to care about the load balance, scaling .etc. On the contrary, it gives us limited control with the infrastructure, and it only provides pre-defined hosting environments. Just in case something bad happened on the stack which our application is running, we have nothing to do it, what we can do is waiting for Heroku to fix it. Nevertheless, it is a good solution for a quick deployment and verification, and it is good enough for a simple sample application like what I did.

I am using the workflow-node.js-view.and.data.api sample which is a forked repo and I did some minor changes.

Develop and test on local machine

For view and Data API, we need a consumer key and secret key pair to do the authentication, protecting your data from being peeked by unauthorized hackers. We do not want to expose our secret keys to public right? We need to keep the keys on server side. And I am not comfortable to save the keys in source code, as I am pushing the source code to public repo of github all the time, sometime I may push the keys to public accidentally and it is not easy to clear the history, so I would prefer to set the keys at run time. In node.js, I can use process.env.variablename and pass the values to it when running the node server.

router.get('/token', function (req, res) {
    var params = {
        client_id:  process.env.ClientId , 
        client_secret:  process.env.ClientSecret, 
        grant_type: 'client_credentials'
    }

    request.post(
        process.env.BaseUrl + '/authentication/v1/authenticate',
        { form: params },

        function (error, response, body) {
            if (!error && response.statusCode == 200) {
                res.send(body);
            }
        });
});

For local testing, I can pass the parameters like "key1=value1 key2=value2 node server.js" when starting the node server. Of cause it is too long to input it all them time when running, so I put it into a shell script, name it as run.sh. It can be bat file for windows.

ClientId=replace_with_your_consumer_key \
ClientSecret=replace_with_your_secret_key \
BaseUrl=https://developer.api.autodesk.com \
node server.js

On Mac/Linux, I need to make it execuable by :

chmod +x run.sh

When I test my node server at local side, I can simplily run the script:

./run.sh

With that I can working on my node.js viewer sample and test it on my local machine.

Deploy to heroku

With that, I am OK to deploy my web site to Heroku. As we said, heroku is pretty easy to use to host a website, and it provides up to 5 free apps.

Firstly, sign up on heroku.com for a free account, and then download and install the Heroku Toolbelt , you can learn more about the Heroku Command Line Interface if you want to know detailed instruction of the usage.

Next, log in to your Heroku account and follow the prompts to create a new SSH public key.

$ heroku login
Enter your Heroku credentials.
Email: <your heroku account here>
Password (typing will be hidden): 
Authentication successful.

Create a new Heroku app through command line, it will create an app with random name if you do not give one in command line, it also add a git remote to Heroku so that you can deploy your code by git push.

$ heroku create
Creating quiet-shore-6917... done, stack is cedar-14
https://quiet-shore-6917.herokuapp.com/ | https://git.heroku.com/quiet-shore-6917.git
Git remote heroku added

Deploy your website to Heroku using Git once your are ready. Heroku will detect your app and setup the corresponding hosting environment, and then host it for you.

git push heroku master

Similarly, Heroku lets you externalise configuration - storing data such as encryption keys or external resource addresses in config vars. At runtime, config vars are exposed as environment variables to the application. Heroku will automatically setup the environment based on the contents of the .env file in your local directory, so you can create a .env with the key pair:

ClientId=replace_with_your_consumer_key 
ClientSecret=replace_with_your_secret_key 
BaseUrl=https://developer.api.autodesk.com 

Or set the config vars manualy by command:

heroku config:set ClientId=replace_with_your_consumer_key 
heroku config:set ClientSecret=replace_with_your_secret_key 
heroku config:set BaseUrl=https://developer.api.autodesk.com 

Ensure that at least one instance of the app is running(do this only once):

$ heroku ps:scale web=1

Once the deployment is done, you can open the website by following command line, it launches your website in your default web browser. You can note down the URL if you'd like to switch to another browser. "heroku open" uses HTTPS by default, you need to use HTTP instead for now due to some known issue of viewer, for example, browse to http://quiet-shore-6917.heroku.com instead of https://quiet-shore-6917.heroku.com

heroku open

If everything works fine, your website is hosted on cloud now. You can keep working on the project on your local machine, making some changes, testing on local machine and commit when the test is passed, and deploy your changes again to heroku by git push.

git push heroku master

Ok, seems easy and simple, right?