Greg Shackles: Getting Started With Serverless and TypeScript

If you’re doing any “serverless” development on AWS Lambda, you should definitely check out the similarly named Serverless framework. Serverless makes it much easier to build manageable applications with this sort of architecture, taking away a lot of the painful things you would otherwise need to manage and automate yourself.

As you write these event-driven systems, a lot of your functions end up looking like data pipelines – your function receives some input, processes or transforms it as appropriate, and outputs something that might be consumed by a user or even another function. These functional, stateless systems really benefit from having some static type checking, which is where TypeScript can really shine. In this post I’ll show how to get started writing a basic Serverless application using TypeScript, and even layer in things like linting and testing that you’d ultimately want in any real application.

Initial Project Setup

If you don’t already have Serverless installed, go ahead and do so via NPM:

npm install serverless -g  

Once that is installed you will be able to use the serverless command (or optionally sls or slss as shorthand) to invoke different commands for the framework. To start, let’s create a new Node app:

sls create -t aws-nodejs  

This will create a few files for you:

  • handler.js: the function’s implementation
  • serverless.yml: the function’s configuration
  • event.json: sample function input for local testing

This is obviously a JavaScript implementation, so now we can start replacing it with TypeScript. First, go ahead and install a few NPM packages:

npm i --save-dev typescript webpack ts-loader serverless-webpack  

If you’re familiar with using Webpack on other platforms, such as the web where it’s most common, then this should feel pretty familiar. Serverless provides a nice extensibility model, which helps enable us to leverage the same Webpack model we use elsewhere. Next, create a webpack.config.js file to configure Webpack:

var path = require('path');

module.exports = {  
  entry: './handler.ts',
  target: 'node',
  module: {
    loaders: [
      { test: /.ts(x?)$/, loader: 'ts-loader' }
  resolve: {
    extensions: ['.ts', '.js', '.tsx', '.jsx', '']
  output: {
    libraryTarget: 'commonjs',
    path: path.join(__dirname, '.webpack'),
    filename: 'handler.js'

This is boilerplate Webpack, passing TypeScript files through the TypeScript compiler and outputting a JavaScript file. We can also add a tsconfig.json file to configure TypeScript:

  "compilerOptions": {
    "target": "es5",
    "module": "commonjs"
  "exclude": [

With that ready to go, let’s update serverless.yml:

service: serverless-typescript-demo

  name: aws
  runtime: nodejs4.3

  - serverless-webpack

    handler: handler.hello

     - http:
         path: hello
         method: get

There are a few things going on in here:

  • service defines the name for this service
  • plugins defines the plugins we want to use, which in our case is the Webpack plugin
  • functions lists out all functions for this service
  • hello is defined as a function, specifies its handler method, and also connects a GET /hello HTTP endpoint to the function

With the plugin added, running the serverless command will now show you a few new commands added by the Webpack plugin. Before we do that, the last thing we need to do is create the TypeScript version of the handler. Rename handler.js to handler.ts, and replace the contents with:

export function hello(event, context, callback) {  
  callback(null, { 
    message: 'Hello from TypeScript!', 

The function’s handler receives three parameters here:

  • event: the payload for the event that triggered the function
  • context: information about the context in which the function is running
  • callback: a callback that must be invoked by the function to say that the function has completed, and also specify success or failure

In this case we simply return a successful invocation, where the response payload contains a message string and also relays the event that it received.

You can go ahead and run this locally by running:

sls webpack invoke -f hello -p event.json  

Go ahead and replace the default contents of event.json with something that matches the API Gateway event format:

  "method": "GET",
  "headers": {
    "host": "localhost:8000",
    "user-agent": "curl/7.49.1",
    "accept": "*/*"
  "body": {},
  "path": {},
  "query": {
    "foo": "bar"

You can also simulate API Gateway locally by running:

sls webpack serve  

This will allow you to hit http://localhost:8000/hello to trigger your function. If you run sls deploy Serverless will deploy your function out to AWS and provide you with the endpoint that you can hit there as well.

Add Some Types

That’s all well and good, but technically everything there was untyped. Let’s go ahead and add some basic types here in a new file named models.ts:

export interface IResponsePayload {  
  message: string;
  event: any;

export interface IQueryParameters {  
  foo: string;

export interface IEventPayload {  
  method: string;
  query: IQueryParameters;

export interface ICallback {  
  (error: any, result: IResponsePayload): void;

Now we have some really basic types around the function’s input and output, so let’s update the handler to take advantage of that:

import { ICallback, IEventPayload } from './models';

export function hello(event: IEventPayload, context, callback: ICallback) {  
  callback(undefined, {
    message: `Method: ${event.method}, Param: ${}`,
    event: event

If you go ahead and invoke the function again you should see basically the same output as before, except that the message will reflect what you provide via the query string ?foo=. If you tweak the format string for message to try and use, you’ll see the TypeScript compile step fail, just the way we want. These are obviously trivial types, but as you start to build out larger systems that deal with real events and data, these types can save you from a lot of mistakes that are otherwise easy to make.

Add Linting

If you’re like me, you like to make sure you have some linting rules set up for all your JavaScript and TypeScript projects. In the spirit of setting this up like a real world project, let’s layer that in. For this example I’ll use the TSLint config we use at Olo:

npm i --save-dev tslint tslint-config-olo  

We can add a tslint.json file to specify we’d like to use this config:

  "extends": "tslint-config-olo"

Finally, we’ll add an NPM command named lint in package.json to run TSLint:

"scripts": {
  "lint": "tslint *.ts"

Now you can run npm run lint to lint all the TypeScript files in the current folder.

Add Tests

Finally, no application is complete without some tests, so let’s set some up. You’re welcome to use your favorite testing frameworks, of course, but for this example I’m going to use Karma, Mocha, and Chai:

npm i --save-dev mocha chai karma karma-typescript-preprocessor2 karma-webpack karma-chai karma-mocha phantomjs-prebuilt karma-phantomjs-launcher  

Next, go ahead and create karma.conf.js which will configure the test runner and Webpack:

var webpackConfig = require('./webpack.config');

module.exports = function(config) {  
    basePath: '',
    frameworks: ['mocha', 'chai'],
    files: ['tests.ts'],
    preprocessors: {
      'tests.ts': ['webpack']
    webpack: {
      module: webpackConfig.module,
      resolve: webpackConfig.resolve
    reporters: ['progress'],
    colors: true,
    logLevel: config.LOG_INFO,
    browsers: ['PhantomJS'],
    singleRun: true

We can also install some typings for Mocha and Chai:

typings i --save dt~mocha --global  
typings i --save chai  

Next, let’s add another NPM command to run the tests:

"scripts": {
  "test": "karma start"

Finally, we can add a basic test file named tests.ts:

import { hello } from './handler';  
import * as chai from 'chai';  
const expect = chai.expect;

describe('hello function', () => {  
  it('processes the query string', done => {
    const requestEvent = {
      method: 'GET',
      query: {
          foo: 'bar'

    hello(requestEvent, {}, (err, result) => {
      expect(result.message).to.equal('Method: GET, Param: bar');


Now if you run npm run test you should see one successful test.


This only scratches the surface of what you can do with Serverless, especially when paired with TypeScript, but hopefully you can start to see the potential here. Admittedly the linting and testing pieces are somewhat tangential here, but I really wanted to show how easy it is to get started building out a real-world application on top of Serverless while being able to leverage modern technologies like TypeScript and Webpack. The full source for this example is available on GitHub.


Xamarin: Live Webinar | Xamarin University Presents: Introduction to Xamarin with Visual Studio

It’s an exciting time to be a mobile developer-there are many new technologies to learn and take advantage of, and the types of applications we can build today are incredible. From immersive augmented reality experiences such as Pokémon GO to always-connected social media and news, our mobile devices have truly become the central hub of […]

The post Live Webinar | Xamarin University Presents: Introduction to Xamarin with Visual Studio appeared first on Xamarin Blog.


Xamarin: Understanding Android’s Doze Functionality

The Android operating system enables developers to create complex applications that take advantage of background services, alarm scheduling, and data synchronization. With users downloading more apps than ever, it’s important that these mass amounts of apps don’t slow down and drain the users batteries, which is why Google introduced Doze in Android Marshmallow and expanded […]

The post Understanding Android’s Doze Functionality appeared first on Xamarin Blog.


Wallace B. (Wally) McClure: Smoky Mountain Boys and Girls Club Charity Golf Event

On October 5th, we ran the Smoky Mountain Boys and Girls Club Charity Golf Event.  This was using our golf scoring application.  The application is built on Microsoft Azure and uses Xamarin for some of the club management pieces, such as picture taking (Note the picture shown in the scoreboard below).  The event had 65 teams spread across two courses (River Course and Highlands Course at the Sevierville Golf Club).  Originally, there were 67 teams, however 2 did not show.  The system will allow teams to be entered, grouped together, flighted, etc.  There are two key items for the event:
  • Additional sources of revenue.  The scoreboard & scorecard provides for sponsorship placement.  Notice in the picture the three sponsors in the header.
  • The amount of time saved in team scoring, totaling, breaking ties, flighting, and etc. that occur after the event.  On an event this size, these typically take 1-1.5 hours and are prone to human error.

Does your charity have a golf event that it wants to take to the next level?


Xamarin: Bringing Platform-Specific Functionality to Xamarin.Forms Apps

Xamarin.Forms comes with over 40 pages, layouts, and controls for you to build beautiful, native mobile apps that run on iOS, Android, and Windows 10. In addition to the massive productivity benefits of code sharing, one of my favorite features of Xamarin.Forms is that we aren’t limited in what our applications can do; we have […]

The post Bringing Platform-Specific Functionality to Xamarin.Forms Apps appeared first on Xamarin Blog.


Johan Karlsson: PropertyChanged.Fody

Short story
When using MVVM as the pattern of choice for your app, make sure to use PropertyChanged.Fody to make your life a little easier. 
  1. Install the nuget-package PropertyChanged.Fody
  2. If using Xamarin studio, edit the Weavers.xml file in the root and add <PropertyChanged>. This is done automatically in Visual Studio.
  3. Create a base class for ViewModels and decorate it with the [ImplementPropertyChanged]attribute
  4. All your properties will be raising the PropertyChanged event on INotifyPropertyChanged.
Long story
MVVM heavily relies on ViewModels that implement ImplementPropertyChanged. This is the way that the View will be aware of changes in the ViewModel and what triggers UI-updates when you change a ViewModel property.

Before PropertyChanged.Fody

The usual way to tackle this is to implement the INotifyPropertyChanged your self. INotifyPropertyChanged only defines one event called PropertyChanged. This event is what the view hooks up to in order to listen to the ViewModel. No magic at all going on here.
So what we do is that we implement that interface and add a method to raise it in a simple way.
using System.ComponentModel; // The definition lives here

public class MyViewModel : INotifyPropertyChanged
// The only thing INotifyPropertyChanged defines
public event PropertyChangedEventHandler PropertyChanged;

// Helper method to raise the event
protected void RaisePropertyChanged(string propertyName)
if (PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

// And a property with a backing field
private string _name;
public string Name
return _name;
_name = value;
That is alot of code for a single property. What if we could get rid of most of that? 

After PropertyChanged.Fody

Enter PropertyChanged.Fody!
To install, do this:
  1. Install the nuget-package PropertyChanged.Fody
  2. If using Xamarin studio, edit the Weavers.xml file in the root and add <PropertyChanged>. This is done automatically in Visual Studio.
After installing the nuget package, rewrite the code above to look like this.
public class MyViewModel
public string Name {get; set; }

Can we make it better

Yes, create a base class for your ViewModels and decorate that one with the ImplementPropertyChanged attribute. Then you can forget about it.

How does it work

Fody is an IL-weaver. It modifies the IL code generated by the compiler and implements the interface for you.


Make sure to check out the official documentation at