A Developer’s Guide to Software Architecture by Building a Chrome Extension.

It has been almost 4 years since I took up software development as a full-time profession. Right from the start, the field has never failed to intrigue me and fill me with the enthusiasm to learn more, expand my horizon and build cool stuff.

Recently, the domain of software architecture has got my attention. Although I have been building software for a while now, the perspective has been mostly that of a developer rather than that of an architect.

So, I decided to take a quick dive into software architecture, by consciously laying out the system’s structure, it’s components and their interactions even before starting to write the first line of code.

To keep me from getting overwhelmed, I decided that the above said “System” will be a simple chrome extension. The aim of this short learning venture was to build the mindset to craft a system with the bigger picture in mind and meticulously build it rather than ruthlessly coding modules and then fitting them together.

The System

“BingeTrendz” was the name of the extension, that I decided to build. Although not catchy enough, I guess it served its purpose of teaching me a thing or two about software architecture in general.

So, here is what the extension would do: It would turn your default chrome tab into a nice looking dashboard that would list the top 20 trending series of that day.

The Architecture

The Details

So, as in the above illustration, TMDB’s TV endpoint was chosen as the data source. But the problem was, it will require an API key to be passed along with every request.

As we all know by this point, this is a purely client-side chrome extension that will have its code written in Javascript which will ultimately be run on the end user's Chrome browser.

The above fact puts us a challenge. Since it’s a client-side script, we cannot make the endpoint calls directly from here, without exposing our API key to the end-users. Honestly, who would want to risk their API keys by exposing them to the public?

That’s where I decided that we should be having a proxy server to avoid exposing the key to the client. But this proxy should also be an on-demand server code that only performs it’s operation when needed to and doesn’t require a dedicated server instance, because after all, it’s just a simple chrome extension and why waste server resources on it?

The solution

So the decision was clear, to have an event-driven server-less AWS lambda function as the proxy which will, in turn, make the actual request and return the response to the client.

With that decision, we have our problem of API key exposure taken care of. But there are still some components to be described and integrations to be made to make the system more efficient.

Efficiency with Cache

At this point, all is fine and we could easily build a working prototype with the discussed architecture. But, if we remember, the data is for a day, since it’s that day’s trending list.

So, it would be highly inefficient to hit the endpoints through our proxy every time a single user opens a new tab on their browser.

How do we make it more efficient and practical? Yes, that’s right..we cache the data. I decided to use the local storage as the cache and to evict the data after 12 hours, but any reasonable duration lesser than 24 hours should be fine for us here.

The Blueprint to Build

With our planned architecture, we have a pretty solid blueprint that we can implement without much friction. This architecture is also optimized to be network efficient due to caching, which will save us a lot on the proxy bandwidth and the number of API calls made in general.

Further, we have also made security considerations by introducing a proxy in the architecture.

The Build Out

I went ahead and implemented the plan and converted the architecture to code. If you would like to try out the extension you can get it from the Chrome store link here

The implementation part hasn’t been covered in this writing intentionally as I wanted to keep this as a walk-through on how I came up with the architecture by thinking through the problems and coming up with solutions even before starting to write code.

Maybe I will write another article on the implementation part at a later time.

Thanks for staying with me till this part and I hope this write-up has motivated you to start your next project by planning the architecture prior to the implementation.

Cheers.