This website uses cookies

We use cookies to personalize content and ads, to provide social media features and to analyse our traffic. We also share information about your use of our site with our social media, advertising and analytics partners who may combine it with other information that you've provided to them or that they've collected from your use of their services. Please read more at our privacy policy page.



X

Cloudifying my app: Eureka! I've created my first API

Shutterstock

I have a confession to make. I’m a product manager, not a software developer, but when I first decided to migrate my Windows eBook app to the cloud, I thought it would be easy to migrate all my source code. After all, I wrote my product using languages and frameworks that are wildly popular and supported by all the major cloud platforms. What I did not foresee was just how much work it takes to familiarize myself with cloud computing infrastructure, products, and development techniques. The good news is I hit a significant milestone this month.

Re-rethinking the architecture

As I already mentioned, I am less a developer and more of a product manager, but since this product is a labor of love, I write most of the code myself. It was interesting attending conferences from Amazon, Microsoft, and Google, to learn what other developers thought of my code and project.

Recently, at a cloud event here in San Francisco, I had three developers surrounding me. Each developer told me the ideal approach in which to convert my app. At some point, we started whiteboarding the approach. Fortunately, my original design was confirmed to be (generally) sound by all, but the specific implementation ideas were vastly different.

For example, one developer suggested I run my code in a virtual machine and be done with it. Another developer suggested I completely rip apart my code and start from scratch with JavaScript (Node), converting everything into microservices. The other developer (the one I agree most with) suggested I create a serverless application but keep it monolithic.

Side note: I’m not sure where this term monolithic came from, but I believe it stems from the AWS marketing machine as they push developers to move their code from one big (monolithic) app to smaller microservices (also termed serverless computing).

Later, the conversation shifted from business logic development to the frontend design. We discussed the best approach to writing a reusable frontend that would work across multiple browsers and operating systems. It is clear that building an app that is native to the operating system, using that manufacturer’s core tools is the best approach (.Net for Microsoft, Swift for Apple, HTML/JavaScript for the web, etc.). Given my project is not some big startup with swaths of VC money behind it, I need to choose a technology that does the best job, is relatively easy to program, and has cross-platform capabilities. The developers I spoke with agreed that Angular and React were the best programming frameworks as they are open platforms maintained by Google and Facebook, respectively.

Getting antsy

The last two months have been a great experience for me as I learn about serverless architecture design, programming languages, JavaScript libraries, pre-compilers, and much more. That said, I need to get down to business and start creating.

The worst thing you can do when programming is to do nothing, and I am not ashamed to admit that I spent too much time thinking and not enough time just doing. I forgot the reason I was able to release the original product was just to sit down, do some design, code, design again, code again, and just get through the iterations until things came together.

Easy looking stuff can be hard

My product produces eBooks for professional authors and publishers. Despite there being hundreds of writing tools on the market today, Microsoft Word is still the most popular, with estimates that 80 percent of all books start in Microsoft Word. That makes sense, because unlike Google Docs, Scrivener, Apple Pages, and other word processors, Microsoft Word comes from the print world and most authors like their books in print and eBook formats.

Naturally, the first step in the process is to get the book file(s) from a writer’s device and up onto the cloud for processing. To store a file in the cloud, you create a BLOB (binary large object) storage service. AWS calls their storage service S3 (simple storage service), and Microsoft calls their product Storage (or Azure Storage).

The API

Going back to my little group of developers (well, maybe more of an ad-hoc support group), they all decided that yes, I need to get my files into the storage account, but oddly enough, no one could give me advice on how to do that. Some said just send the file to the storage account, but that is not feasible because a web browser would have to store my cloud credentials to do that. Instead, we decided the web page should use JavaScript to upload the files to an API. The API would then determine if the user has security rights to do so and then handle uploading the files, as I show in the following image.

Looking at my API, you might think this is pretty straightforward as its job is simple: verify the user and shuttle files into BLOB storage all the while providing status back to the sender. Given the popularity of websites that allow you to upload pictures and documents, I thought this was going to be pretty easy. After all, there are thousands of examples scattered across blogs, YouTube videos, and Git repositories.

Getting there is half the battle

As it turns out, creating my API was not as easy as I thought. For example, before you even get started, you must set up your cloud environment to provide a secure login service. Of course, you can build your own security model, but I figure it is easier just to use what the cloud provider already offers. The next step is to set up the structure for how you will store the files and then you need to create the API (sort of a stub for where you will place your code).

After getting all those core elements in place, I could then focus my energy on the API itself. At the end of the day, I wrote my app in C# using .Net Core because all the base code for my existing app is already in C#. The frontend, which is currently just a website, is using good old HTML and JavaScript.

Even though I used two very popular and proven technologies for my API and web page, those were not without some trial and error. For example, it turns out C# offers plenty of options to receive and manage files. After a lot of research, I am pretty sure my API uses best practices and is the most modern approach. Even though my initial API code taps in at around 100 lines of code, it uses a dozen different framework references.

As for the test website, it is just a basic wireframe at the moment but to make life easier I still had to use two different frameworks in jQuery and Bootstrap (to learn more about these two technologies, click here and here). The following image shows my still-very-early-stage website in action.

I am certainly a beginner at programming for the cloud, and my technical skills are building fast, but as you can see, planning out an app and delivering it can be quite an undertaking. My original estimation was three weeks just to get this far, and it took me two months (that’s less than part-time, mind you). If you are programming for the cloud or getting up to speed on the latest frameworks, do not underestimate the learning curve.

Catch up on Cloudifying my app

This article is part of a regular series where I share my experience migrating my Windows application to a cloud-based infrastructure. You can follow the series at this link.

Photo credit: Shutterstock