While part one of this blog post focused on our experience during the Microsoft Hackfest, this part will instead focus on the technical results of our trip to Redmond.
Co-Author: Eugen Timm
An explanation of the architectural decisions behind the solution we devised at the Microsoft Hackfest.
We arrived at the Microsoft Hackfest with Timeout, our SaaS product designed to handle vacation and sick leave requests. We employed the Lean Startup principle to develop Timeout. This principle allows us to quickly gain an insight into how this product/concept would be received by the market, and in turn allow us to make more informed decisions on the further development of Timeout.
Before our trip to Microsoft we had based “Timeout” on the JavaScript Full Stack Framework Meteor, which in our opinion was an excellent choice for the development of a prototype. However, as we quickly realized during the Trip to Microsoft, Meteor was in fact unsuitable for the long-term production and development of our product. One of the main reasons for this being the close interdependence between the database, backend, and frontend.
Our individual Timeout-Clients were hosted on Azure-VMs in separate Docker containers. The user authentication and team administration was instead set locally.
The Meteor configuration and individual Docker containers for each Timeout-Client was ideal for rapidly prototyping and to quickly gain insight into user opinions of our application. We could easily address potential new users through Online Performance Marketing, measure their conversion rate and quickly create a new Docker-Insurance for each new Client/Company. After the success of these tests we decided to transfer our system architecture to a more stable, and more easily scalable foundation, as well as to a technology that we were more familiar with.
Our goal for the Hackfest was to come away with a scalable, multitenancy model, and to successfully integrate various Microsoft services in Timeout.
Alongside the Microsoft experts for Active Directory, Teams, and Office 365, we decided on the following assembly:
The first step for the integration of Microsoft services is the creation and the integration of a Microsoft App (https://apps.dev.microsoft.com). An admin of an organization that uses Office 365 can then use this connection to allow our “Timeout” application access to company data over the Graph API. Additionally, employees of such an organization can log in to “Timeout” through their Office 365 account.
An important and simultaneously difficult decision to make at this stage is whether to work with Delegated Permissions or Application Permissions.
For Delegated Permissions, the Graph API permissions are obtained from the logged in user. This gives near unlimited access to resources such as E-Mails, Calendars, and Contacts. On the other hand, there are resources such as Groups or AD information, which cannot be accessed even when the currently logged in user has permission to access them. Although it is possible to gain these permissions with Delegated Permissions through Admin-Consent, this ends up being too cumbersome for the end-user.
Application Permissions solve this problem since the Admin Consent need only be given through the one Application. This enables access to the Graph-API without the need for user interaction whenever this data is required. Along with being the more secure choice, Application Permissions ended up being the simpler option as well.
In our case, we wanted to integrate as many functions as possible into the backend, which helps in the implementation of streamlined clients such as Mobile, or Web Apps, Bots, Voices Skills, and more.
At its core of our system is designed to be an API-application that also enjoys access to the data bank. This core must be robust, scalable and flexibly upgradeable. Fortunately for us, ASP.NET Core 2 can meet these conditions, and since our team already is quite familiar with ASP.NET MVC as a basis for RESTful APIs, this was an easy choice.
The choice of data bank was similarly easy as we have had fantastic results with Azure SQL DB in the past, and in our opinion it employs a relational data format which is suited for the “Timeout” core function.
Finally, we decided on React for our frontend technology. Since we consider a single page application for an implementation of this kind to be very user-friendly, and because our team currently tends toward React in any case. Sorry Angular…
The API-application is built according to a standard ASP.NET MVC/Web.API.
Data from the Web-Frontend or Bots passes over the Web API Controller of the API-application. The data from the controllers can be transferred to deeper layers through Services. Beneath the services lie the repositories, which integrate with the data service layer through the entity framework core.
As our dependency injection container, we employ the included DI container from ASP.NET core, and for unit-testing we use xUnit and Moq.
Extremely helpful for unit testing of repositories is the in-memory data bank of the entity framework core. With this in-memory data bank it is far simpler to test real write and read permissions without needing to deal with the long wait times of a “true” data bank.
Due to time constraints, we implemented only the most necessary frontend features. We employed React, Redux, Saga, and Tailwind CSS. Aside from Tailwind these are all well-known and oft used frontend stacks making their use self-evident. Tailwind was chosen since it appears to come with few preconfigured styles and just takes on the most annoying reoccurring definitions of frames, colors, positions, and sizes. However, this is only our first impression and still subject to possible change after more experience.
Of particular note to us was the ability more quickly implement functions that interact with the API-application by building a Teams bot instead of a Web-UI for the individual scenarios.
As mentioned earlier, we found that Teams bots are far more than simple gimmicks, rather they can be an efficient and lean method for user guidance.
On the advice from our Microsoft Hackfest partner we employ the Node.js Implementation of the Microsoft Botframework.
A tutorial for the various services necessary for running of a Teams Bot can be found here: https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/bots/bots-create
The tutorial also covers the helpful tools ngrok and Bot Framework Emulator, these tools allow you to test bots on your PC without the needing to deploy the Bot-Code in Team or Azure.
Essentially, our Bot runs inside a Node.js server application, which can be communicated with in the same fashion as a RESTful-API. The bot, in turn, communicates with the Timeout-API. This chain of communication allows for dialog between the Timeout-API and the Bot API.
The last step in the process of creating a “time-off request” is saving the date range of the time off as an event in the requester’s calendar.
With the Microsoft Graph API Explorer it is possible to test Graph API requests outside of the application itself.
The Graph API is a REST-base API. In our case, we transfer the Microsoft ID and the calendar of the user to the Graph API. Additionally, start and end dates for the time off request are sent to the API, and written to the given calendar.
Necessarily, we need to receive an Access Token with the appropriate permissions. The following video shows the connection between Delegated Permissions, Application Permissions, and Admin Consent.
For more examples of Azure Authentication visit Richard diZerga’s (one of our Hackfest mentors) blog: https://blogs.msdn.microsoft.com/richard_dizeregas_blog/
The following Github repository is a suggestion from Richard and a very useful collection of Code-Snipets and explanations of everything you need to know about Microsoft Graph and Authentication: https://github.com/User1m/microsoft-graph-notes
Although we had to spend quite a bit of time on Authentication and on research we are quite satisfied with the Stack that we decided on. It consists of a balanced mix of proven components and bleeding edge technologies. The Architecture is both stable and scalable due to the Azure hosting. Additionally, since we can essentially delegate the multi-client capabilities to Microsoft, we can develop a SaaS application customized to the client’s corporate structure.
The user side UI can be flexibly designed due to the RESTful API, which takes over our own business logic and places a thin wrapper around the Microsoft Graph API and OAuth authentication. This makes it possible to add a variety of user side applications such as a web app, native mobile app, chat bots, voice skills, etc.
An exciting new subject for us was the Botframework. We found this form of UI extremely interesting, since with the help of chat bots there is no need to develop your own UI, and the application is already available on every platform for which the messenger is running. This cuts down on development time which can in turn be spent developing new features or improvements.
After a hectic but exiting week we presented our results in a small demo for various Microsoft developers and product teams, which was also recorded by the Channel 9 Team.
We came away from the Hackfest with a multitude of valuable experiences which we can use on our future Projects.
The Graph API offers many interesting possibilities for interacting with the data from the Microsoft Product line. Ideally, we would like a few more features such as nested requests, or expanded filters, however even without these features the Graph API enables many exciting scenarios
As for Bots, we are planning on porting our internal Slackbots (for ordering food, and displaying WiFi passwords, or Printer IP addresses) over to Team bots. We also see potential in using Team bots for Timeout to add new functions, for instance, creating time-off requests through a team bot.
Finally, we have already been using Azure AD (B2C) in various projects and will continue to employ it as our platform for identity and access administration.
In part one of this blog post we focused on our experience during the Microsoft Hackfest check it out if you haven’t, yet.
Thanks Kailex for the translation :)
If you are interested in using Timeout in you company check it out:http://www.timeoutapp.de/