Skip to content

AngularJS

YGET initial architecture explanation

My current position is with Corefount Inc. as a Principal Architect and we are putting together a mobile platform for preventive healthcare. To accomplish this goal there are a few requirements:

  • Mobile Application UI
  • Web Application UI
  • Data Driven Backend

There are an unlimited number of ways to approach developing these items. I will layout what choices we have currently begun implementation with and why we chose them. One of the primary driving factors behind the decisions are the existing staff’s skill set. Myself, My Boss, and the QA lead are all experienced with Microsoft technologies. Also, we do not have any infrastructure and consider the overhead of maintaining our own servers an unnecessary burden at this stage. Another leading factor in the decision making is the initial teams Xamarin experience. Now that I have explained our backgrounds, I will expand on the initial requirements.

Mobile Application


The mobile application allows users to track their daily nutritional information while also prompting them with what they are lacking. It will also help them avoid items that they are allergic to or have a general disinterest in consuming. The application needs to allow the user to login using corporate credentials and may need to be hosted from a corporate app store. Users should be able to use the application offline. The application should support Android, iOS, and Windows Phone. This lead to the following decisions being made:

  • Xamarin Forms
    • Xamarin Forms allows us to build a cross platform UI with Xaml and easily override needs per platform.
  • sqlite
    • sqlite makes caching data locally easy.
    • Xamarin has an easy to use cross platform plugin for sqlite
  • Web API 2 client
    • Web API 2 client works with all the mobile platforms as a PCL
    • The backend is powered by Web API (this will be discussed later)
    • The identity provider is also through ASP.NET and can utilize the web api client
  • Syncfusion
    • Has controls with Xamarin Forms that allow us to quickly put together dashboards for users to track their progress

 

Web Application


The web application has many of the same requirements as the mobile application. The only true difference is the web application doesn’t need internal hosting or offline usage and it needs to be responsive. This lead to the following decisions to be made:

  • angularjs
    • allows for creating a SPA and seems to be the easiest to hire maintainers for
    • allows for reuse of existing JQuery widgets as directives
    • allows for code reuse between data management portals and consumer facing application
  • typescript
    • typescript gives us type checking and intellisense for writing large amounts of javascript
    • seems to be an easier pickup for non javascript developers (sometimes you have to throw bodies at a problem)
    • used with definitely typed gives intellisense and compile time checking to existing libraries
  • bootstrap
    • can quickly create a responsive website
    • customizable via less or sass compiler
  • less
    • helps to create complex css
    • extends bootstrap 3
  • kendo ui
    • facilitates the creation of dashboards quickly
    • works with angularjs
  • npm + gulp
    • manages javascript packages
    • allows for build automation and integrates easily with VS 2015

 

Data Driven Backend


The backend is going to be broken up into multiple sections. As with most platforms, the data is the real key to success. It is also the source of much of the complexity. For the YGET platform, the data drives decisions that affect patient’s lives and has to be good enough not to cause them harm. Because of this, the data has to be properly vetted and organized for use. Along with that, there should be multiple redundancies to ensure patients are not harmed.

There are some encompassing technological choices that were made that can be discussed in this section. One of the major choices was to use Microsoft Azure. Azure allowed us to host our solution more easily than managing our own data centers or managing more than one data center vendor. Azure was also chosen over other cloud providers due to the team’s knowledge of the product and our relationship with the local Microsoft team (I can’t state enough how important having local contacts are). Also, SQL Server was chosen as our primary relational database engine. Corefount’s CTO (my boss) has more experience with SQL server than I have experience so it was an easy decision.

Now that the over arching decisions have been explained, its time to look at the systems required to power the backend of the platform. I will try to organize the following systems in least dependent to most dependent:

 

Data Generation and Acquisition


YGET‘s need for data will require lots of manual input and lots of automated processes. First, let us focus on the automated processes. The major process currently is targeted web crawlers parsing aggregate data feeds. There are also smaller processes that grab published data from the web for import (pdfs and the like). These processes are run in Azure’s Web Jobs due to the simplicity of scheduling and the ability to expand resources on demand.

The web crawler needed to be a very low overhead and fast worker. This caused us to decide to write it in Visual C++. This lead to the following decisions:

  • boost
    • full of helper functions and classes (especially in string searching)
  • Casablanca
    • utilizes PPL
    • supports json and makes http lifecycle easier
  • sql api
    • simplest SQL Server client library I could find

After the web crawler has parsed and saved the data successfully there is an SSIS package that is able to take the data and put it into the management database.

 

Data Management and Configuration


After the data is acquired, it needs to be organized and sanitized. Also, the data may be incomplete and manual input may be needed. To accomplish this an internal website was put together using the following:

  • ASP.NET Web API
    • Easily expose OData endpoints for use with kendo ui tools
    • Expose data quickly and easily
  • angularjs
    • integrates with kendo ui easily
    • allows for SPA application
    • internationalization support for internationalization market data manipulation
  • kendo ui
    • controls allow for easy data management
    • controls support out of the box paging and filtering with odata
    • internationalization ease for international market data manipulation
  • Entity Framework
    • makes data access a non issue
    • works in the simplest manner possible with ASP.NET Web API OData

Data Endpoints


Finally, the last piece of the puzzle is exposing the data to the end user. The data will need to be available to users globally. The data also needs to be secured so that user’s can access only their data. User’s may be apart of a corporate domain, use a social login, or use a YGET local account. These requirements led to the following decisions:

  • ASP.NET Web API
    • Easily expose http endpoints
  • ASP.NET Identity
    • allows for integration with third party OAuth services
    • allows for integration with on premises and azure active directory
    • supports local accounts
  • AutoMapper
    • Allows for easy exposing of DTOs
  • Azure Service Bus
    • allows for offloading of computationally heavy code
  • Entity Framework
    • makes data access a non issue
  • Sql Azure
    • relational database hosted instance that covers data needs in the cloud

Creating Named Angular directives

On one of my pages I wanted to create an Angular directive that my controller could fire events on. To do so I needed to attach an object from the directive to the scope of the controller. In the following example, I will showcase a directive that exposes a “show” and a “hide” method to the wrapping controller.

First, I need to create the directive and controller:

var app = angular.module('app', []);
var myController = app.controller('myController', function ($scope) {
    $scope.toggle = function () {
        $scope.namedDirective.toggle();
    };
});
var toggleDirectiveName = 'toggleDirective';
var toggleDirective = app.directive(toggleDirectiveName, function () {
    return {
        restrict: 'A',
        link: function (scope, element, attrs) {
            function ToggleDirective() {}

            ToggleDirective.prototype.show = function () {
                element.show();
            };

            ToggleDirective.prototype.hide = function () {
                element.hide();
            };

            ToggleDirective.prototype.toggle = function () {
                element.toggle();
            };

            scope.$parent[attrs[toggleDirectiveName]] =
                new ToggleDirective();
        };
    };
});

In my code you notice a reference to $scope.namedDirective. The namedDirective will be defined in the markup as the name of the directive:

<body ng-app="app">
    <div ng-controller="myController">
        <button ng-click="toggle()">Toggle</button> <span toggle-directive="namedDirective">
            <p>Visit <a href="http://qimata.com">my blog</a> for more interesting and entertaining posts!</p>
        </span>
    </div>
</body>

Working Fiddle:

Twitter Auto Publish Powered By : XYZScripts.com