Today's post isn't necessarily too interesting code-wise, but it touches upon some greater, more broad, serverless topics that I'd like to bring up. A few weeks ago I discovered an interesting GitHub repository: https://github.com/gadael/icsdb.

This repository contains iCal files (think plain text calendar data) for non-working days for all 50 US states and various European countries. This could be useful in a number of ways, if, of course, you can parse the iCal data. I thought it might be interesting to build a simple service that would take a URL pointing to iCal data and return the information in JSON form.

There are multiple different ways of parsing iCal, but I felt ical.js by Mozilla was good enough. The ical.js library is pretty complex, letting you work with iCal data like a component, calling different methods to find data, but it can also just return a simple parsed version of the text. Here is the code I came up with:

const rp = require('request-promise');
const ical = require('ical.js');

function flattenEvent(e) {
	let event = {};
	for(let i=0;i<e[1].length;i++) {
		let prop = e[1][i];
		event[prop[0]] = prop[3];
		//console.log('e',prop);
	} 
	return event;
}

exports.main = (args) => {

	return new Promise((resolve, reject) => {
		rp(args.url).then((txt) => {
			try {
				let parsed = ical.parse(txt);
				let events = parsed[2];

				let result = [];
				events.forEach(e => result.push(flattenEvent(e)));
				resolve({events:result});
			} catch(e) {
				console.log(e);
				reject(e.message);
			}
		})
		.catch((e) => {
			reject(e);	
		});
	});
}

Basically - suck down the remote URL and parse using the library. As I said, there is a nice "object based" API that the library provides, but I found I could work with the initial data a bit easier. You can see where I just grab the third item in the array to get the actual events. I then "flatten" the data using flattenEvent. If your curious, the data is in a form called jCal, which has a specification: https://tools.ietf.org/html/draft-ietf-jcardcal-jcal-10. My flattenEvent function makes some assumptions that may not necessarily always work out well, but so far it's done ok.

I tested it by asking for Louisiana holidays:

wsk action invoke ical/get --param url 
https://raw.githubusercontent.com/gadael/icsdb/master/build/en-US/us-louisiana-nonworkingdays.ics
-r

And here are the top five results.


{
	"class": "PUBLIC",
	"created": "2014-01-09T00:47:56Z",
	"description": "",
	"dtend": "1970-01-02",
	"dtstamp": "2017-06-23T13:53:48Z",
	"dtstart": "1970-01-01",
	"last-modified": "2017-06-23T13:53:48Z",
	"rrule": {
		"freq": "YEARLY"
	},
	"sequence": 0,
	"status": "CONFIRMED",
	"summary": "New Year's Day",
	"transp": "TRANSPARENT",
	"uid": "b901ca08-d924-43c3-9166-1d215c9453d6"
},
{
	"class": "PUBLIC",
	"created": "2014-01-09T00:47:56Z",
	"description": "",
	"dtend": "1983-01-02",
	"dtstamp": "2017-06-23T13:53:48Z",
	"dtstart": "1983-01-01",
	"last-modified": "2017-06-23T13:53:48Z",
	"rrule": {
		"byday": "3MO",
		"freq": "YEARLY"
	},
	"sequence": 0,
	"status": "CONFIRMED",
	"summary": "Marthin Luther King day/Robert E. Lee day",
	"transp": "TRANSPARENT",
	"uid": "0ae8128a-e360-492c-b2bd-52ed0d6d06fd"
},
{
	"categories": "-New Mexico",
	"class": "PUBLIC",
	"created": "2014-01-09T00:47:56Z",
	"description": "",
	"dtend": "1970-02-01",
	"dtstamp": "2017-06-23T13:53:48Z",
	"dtstart": "1970-02-01",
	"last-modified": "2017-06-23T13:53:48Z",
	"rrule": {
		"byday": "3MO",
		"freq": "YEARLY"
	},
	"sequence": 0,
	"status": "CONFIRMED",
	"summary": "Presidents Day",
	"transp": "TRANSPARENT",
	"uid": "17425d41-9ed3-4088-adad-4693d1bd44c9"
},
{
	"categories": "Louisiana",
	"class": "PUBLIC",
	"created": "2014-01-09T00:47:56Z",
	"description": "",
	"dtend": "1970-04-02",
	"dtstamp": "2017-06-23T13:53:48Z",
	"dtstart": "1970-04-01",
	"last-modified": "2017-06-23T13:53:48Z",
	"rdate": "1970-02-10",
	"sequence": 0,
	"status": "CONFIRMED",
	"summary": "Mardi gras",
	"transp": "TRANSPARENT",
	"uid": "7ac45e93-a684-4061-a0c7-948a89e358b0"
},
{
	"categories": "Connecticut",
	"class": "PUBLIC",
	"created": "2014-01-09T00:47:56Z",
	"description": "",
	"dtend": "1970-04-09",
	"dtstamp": "2017-06-23T13:53:48Z",
	"dtstart": "1970-04-08",
	"last-modified": "2017-06-23T13:53:48Z",
	"rdate": "1970-03-26",
	"sequence": 0,
	"status": "CONFIRMED",
	"summary": "Good Friday",
	"transp": "TRANSPARENT",
	"uid": "3c46243f-00f8-418f-94cf-4eda72ae7cb2"
}

So... that's some data. Cool. What would I do next? When I first started thinking about this data, my first thought is that it could be a useful API for web apps. I'm a web developer so everything looks like a web-related source for me. Of course, why would I need serverless for that? I could run the iCal library in the browser - the only issue I'd run into is CORS - maybe. And I could always copy the iCal files to the same server as the app. But that's really limited thinking.

By creating this as a serverless action, I've opened it up to any event source, web or not. How about an example of something completely non-web based?

Imagine a support service where every day, my process gets a list of employees responsible for IT work in case of emergencies. I could imagine a process by which after getting a list of employees, I could check each one's home state against a list of holidays for that state and determine if that person is off today. It's the exact same code, but I'm simply using it in a different context.

And this is something important to keep in mind here. Serverless isn't just about building NodeJS apps simpler. Instead I'm creating a resource that can be used in multiple situations, both direct (web app making a request) and indirect (a process run on a timed schedule).

This is something I've talked about before, but I feel like it's something that's possibly not quite as evident.

p.s. You can find the source code for this demo here: https://github.com/cfjedimaster/Serverless-Examples/blob/master/ical/get.js