This article is part of a regular series where I walk you through my journey of converting my Windows-based eBook Toolkit product to a cloud-hosted web application. In this article, I walk you through my thought process for figuring out how to create the business logic for my app.
Think ‘services,’ not ‘app’
When you write a mid-size application for Windows, it is usually one big — or a small handful of — projects you manage in Visual Studio. The project usually contains everything you need from the front end UI to the business logic and sometimes even the database.
Occasionally the app, like mine, may not always conform to best practices, whereby you add business logic to the front-end user interface, as the following image shows.
My app, in its future state, will be a service. This way, I can write native or web-based apps that do not contain the core business logic. Also, I may even open up my app so that third-party developers can make use of the service. You can see a marketing-style diagram of what I am trying to accomplish in the following image.
To create this new app service, I had to think long and hard about how to architect the business logic for my app. Here is how I managed to wade through the sea of options and come up with the options that are right for my app — right now, anyway 🙂
Business logic options
Azure Web Apps (too big)
An Azure Web App is essentially a scalable web application you create in Visual Studio and upload to Azure (granted it does not have to be Visual Studio, but let’s face it, VS users are Microsoft’s target audience). That application can contain the business logic, views (web UI), and other elements that make up your app. Building a web app is similar to building a Windows app but with the browser as the front-end.
While I want my app to support any operating system, I certainly want a browser version and a web-hosted Office Web Add-in version. For those reasons, I may create web apps for the front-end design (or maybe not, since I am playing with single page applications as another option).
Technically, I can write the business logic for my app as an Azure Web App. I can expose various services to solutions within and outside of the Azure network. However, if I expose the web app for outside use, then I need to write a bunch of custom code to manage things like security and other low-level elements.
Azure Functions (too small)
Back when I first started looking at cloudifying my app, I was reading gobs of reports that so-called serverless computing is the way of the future, with Azure Functions and AWS Lamba Functions leading the charge. Functions seemed like the ideal approach to implementing my application. They are small bits of code that perform nearly any action you can code up.
Functions work similar to app services like Zapier and IFTTT where something triggers it to run and it performs a quick function. For example, you can write a function that runs when there is a new entry in a database, web hook, timer, or some other external trigger.
To use functions, it became clear that I would have to break my app into such small component parts. Given the scope of my app, I do not think it is worth it to use functions as my primary solution for developing my app’s services. That said, Azure Functions are not dead to me. I think they will have a place in my code as small “helper” functions that perform unique operations I do not want in the base code. Read on, and I will share how Functions likely fits into the bigger picture.
Azure API Apps (just right)
Azure API Apps allow you to create the business logic for your app that handles requests coming from other apps. API Apps are sort of the bigger sibling to Azure Functions, allowing you to create rich APIs (application programming interfaces) that other apps will access. For example, I can create a web, mobile, or desktop app that sends a request to an API. The API will determine how to process the request, perform the proper business logic, and then return the result.
What I like about API apps is they are small, compact, and a separation of the business logic from my other apps. Further, you can protect the API by using Azure Active Directory to secure the service.
Putting it all together
The API is, of course, one element of the entire application. As I mentioned earlier in this article, I may use web apps for the front-end web elements of my app.
I may still use Azure Functions as well. I may want to offer some smaller services that just aren’t worth coding into the core business logic for my app. For example, let’s say the user would like a copy of their book to automatically publish to an online eBookstore, send an email, or publish the book to a Dropbox account. My API should be able to hand off that workload to small functions that are suited to performing those post-production actions.
With all this in mind, I can now start moving my application’s business logic to a set of APIs. At its core, I foresee at least two APIs my apps will access. The first API will convert a single document to various eBook formats. The other API will perform the much more complex task of packaging multiple Microsoft Word files into a single eBook.
Of course, both of those APIs do very similar things, so I might have to create additional “internal” APIs that house shared business logic.
As I get my first APIs set up, I plan on sharing my experience in future articles and if need be, some videos as well. Please comment if you have any questions. As always, I am also happy to hear your personal opinions or ideas.
For other articles in this series, go to:
Photo credit: Pixabay