Add Build 2020 Schedule to Your Calendar

Last week Microsoft released the schedule for sessions for Build 2020. However, other than via the portal, there’s no easy way to get a list of sessions so that you can easily work out which sessions work for your time-zone and which sessions you want to attend. In order to solve my own dilemma of how to add the sessions to my calendar I built a quick service that would generate the appropriate ICS files. Actually my first option was a single ICS with all sessions, hence there are two options:

All Build 2020 Sessions in a Single ICS file

All Build 2020 Sessions as Individual ICS files

Here’s how the whole thing went down – mid-last week I was wondering whether there was an easy way to add the schedule to my Outlook calendar. At this point the only schedule that had been announced was a high level list of just some of the sessions eg:

Given there’s not that many sessions, it would have been quick enough for me to add them individually to Outlook. But no, the developer in me went hunting for how to automate this. Opening Fiddler I saw that there was indeed an API that was being called at endpoints beginning with https://api.mybuild.microsoft.com. However, at this point there weren’t any calls to retrieve sessions, speakers etc, the only calls were to the /chrome and /settings endpoints which didn’t really reveal much.

Thinking that I wouldn’t be able to get much further I tried a last ditch effort of searching for other uses on the web for api.mybuild.microsoft.com. I guessed there wouldn’t be any direct hits, other than for the mybuild.microsoft.com portal, but I figured that given the way that search engines look for similar matches, something might turn up. Sure enough, the api url is not to dissimilar to the one used for prior events eg https://api.mybuild.techcommunity.microsoft.com. This lead me to a pretty sophisticated PowerShell script that Michel de Rooij had put together for scraping session content for prior events.

Knowing that Microsoft typically uses the same vendor for things to make it easier year-on-year, it’s no surprising that the api described by Michel’s PowerShell script was again being used for Build 2020.

I quickly used Json2Csharp QuickType (I can never remember this name but the service is great!) to generate the classes required to interact with the API. I can’t say that I engineered the ASP.NET Core 3.1 Web API service to be particularly efficient, mainly because I predicted that I was going to put both Azure CDN and CloudFlare in front of it. It basically pulls requests the entire list of sessions and holds them in a static variable. The only caching being that if the service is requested again whilst the static variable hasn’t been collected, it will return the previously retrieved list of sessions (do NOT follow this architecture for a production application).

I used iCal.NET to generate the ICS files – initially one monster ICS which has all the sessions but then I realised that it might be better to have individual ICS files that were downloaded as a Zip file. The ICS file(s) also contain session speakers (with links to their profile and/or their company, where available) and a link to the session for registering and attending.

Next I published the ASP.NET Core service to a new Azure App Service. As this was a personal project I opted for a free Azure App Service Plan. Of course, this will not scale well, since it’s really designed for development and testing purposes. However, given that I’m generating ICS files that aren’t likely to change frequently, I figure I’m going to protect my service so that it doesn’t get slammed.

The protection comes in two forms:

• Firstly, I added an Azure CDN endpoint in front of the app service – this will cache the output of my service (level 1)
• Secondly, I added Cloud Flare for two reasons. This gives me a nice friendly url (ie build2020.builttoroam.com) that I can share, without exposing either my Azure CDN endpoint or my app service url. I also enabled the proxying option which means that CloudFlare also caches the output of my service (level 2).

The upshot is that even if a massive number of people download the ICS file(s), my service shouldn’t even need to wake up. This is reflected by the analytics from my Azure App Service that shows almost zero out-bound data over the last 24 hours.

Hopefully the ICS files (Single ICS file or Individual ICS files) helps you build your schedule for Build 2020. Look forward to seeing everyone there, virtually of course!