Lately I’ve been leveraging the “serverless” architecture often. I like its statelessness, the predictable cost factor, the simplicity of development and deployment, etc. It just fits for systems that are event-driven. It’s already a strong tool that is being used by many live products, yet still steadily being improved by providers and the community on aspects such as cold-start time and time-to-live. Not to mention frameworks such as serverless and apex further spoil us with ease of utilization.

There are also many technical reasons one can use to argue against using this architecture. Job security for certain overly-specific professions aside, at the end of the day, it should depend on use cases and automation requirements.

However, one of my rationale to justify the use of this architecture, as mentioned in the title, is related to attention span.

In today’s world, it is increasingly hard to be exempted from having a short attention span, which is often caused by constant interruptions of thought process and work-flow.

The interruptions may come from your co-workers that don’t understand why it’s not optimal to tap on your shoulder while you are in the “zone”.

The interruptions may come from your S.O. or close family member who brings up some important matter in your life while you’re trying to organize your thoughts on a nested for-loop.

The interruptions may even come from your own self-distractions – social networks, exciting announcements, or simply an accidental overhearing of topics that can suddenly pull you out your chair, so you can eagerly express your expert opinion.

Unless your work, your life, and yourself can all discipline and behave, having a short attention span is almost unavoidable.

There are rare developers who have adapted or been blessed to have a large enough reservoir of memory, and nimble enough brain power to handle quick and short context switches. If you are, or work with, one of these, congratulations! Some call them “10x” developers, I believe they’re truly genius.

Unfortunately, the vast majority of us aren’t.

So here comes the beauty of working with the serverless architecture. By its design and its common limits, the software you deploy serverlessly are hopefully simple and small. That’s why providers name their direct serverless offering as “Lambda”, or “Functions”, and encourage developers to write pure, stateless, stable input-output functions that often focus on one thing at a time. That naturally leads to simpler and smaller of the program that needs to be written (don’t be too extreme though). And that means shorter tasks that fit better in our shorter attention spans.

Now, before I’m accused of being a sales person of certain provider, or a fan-boy of the architecture, let me lay it out for you what’s in it for the providers – smaller pieces = more services needed to solve real-world problems = more usage fees $$$. Simple.

So to avoid being ripped off by naively hopping on the hype-train, a new challenge for developers who work with serverless architecture is to figure out a good balance for each service to maximize processing done per billable resource, while keep the logic simple enough or just stateless. That’s not always easy, because it often requires assessment of other services that it connects with. In the older times (or larger organizations), this type of duty falls on the hand of dedicated architects, which is a profession that’s increasingly obsolete in the younger and smaller organizations (and rightfully so).

“Serverless” is far from being the silver-bullet answer to all problems, it still requires fine tinkering and craftsmanship.

But my point stands, that in a world full of distractions, the naturally simpler, smaller, and often stateless functions help greatly in solution composition, as well as mitigating interruptions coming from whatever angle.

If you’ve played Dota, then you’d know an item called Poor Man’s Shield. Without getting too much into the meta and expose my laughable understanding of the game, the item is mostly about cost efficient way to deal with relatively tough situations in the early game, without the late game resources to go for a more luxurious option right away (except when you can stomp in early game against noobs like me).

In web development, there can be tough situations as well. One situation I encountered recently was to load potentially thousands of items each with multiple charts on a single page, in a nutshell:

In this post, I’m going to walk through my steps of developing the poor man’s approach to handle the tough situation. For examples below, we are going to utilize Vue.js v2 as the data binding layer, and Chart.js v2 for chart.

This works. However it becomes royally painful to load when you have so many items as the situation I described earlier. In fact, just a mere hundred of such items on a single page already causes unpleasant amount of time to render while showing a blank page, and blocking all user interactions except inviting end users to force close the browser/tab due to frustration (and probably never getting them back). Such horror is not tolerable on today’s internet.

Be Asynchronous

One way we can make this better is to explicitly instruct the component to asynchronously initialize the chart through the use of setTimeout:

This approach effectively causes Vue to render the charts in the “next” update cycle. It makes the UI a bit less painful to use as there can be some “primer” contents rendered, which usually exhibit as a part of the parent elements that hold the chart component. However, this is not good enough, as the deferred update cycle would still block the whole UI. This is especially bad when the page offers many items in a list fashion that the users would want to either search with CTRL/CMD + F or scroll down for items that are out of the current view. Besides, it’s very wasteful to render things that cannot even be seen yet.

Be Lazy

This leads to a tried and proven technique many refer to as “lazy-loading”. With so many years of such technique being matured, and thanks to the ever so successful open source community, one can easily pick a robust library that does it well while being delightfully simple to use. The following is an approach with one such library called ScrollReveal:

sync would be used when this chart component is nested under another component (which hopefully already applies some sort of render deferring optimization similar to what we’ve done thus far), and requires the chart to visually appear at the same time as its parent component

async is very similar to sync, except that we don’t require the chart to visually appear at the exact same moment as its parent component.

The third and the default mode would be the self-contained optimal approach that we worked out from above.

There’s room for more sophistication. One can wrap the above into an easy-to-use custom directive or wrapper component, or even directly make it into Vue.js, making it more of an “end game” approach. With some twist, this approach can also be adapted into other choices of data binding layer and chart library.

But there’s always the option to employ the poor man’s approach – simple, effective, easy to understand and not too shabby to apply to any existing applications of any scale.

Programming can be enjoyable, but not always so. I bet even those who claim to be the most passionate about programming suffer from impossible deadlines, technical difficulties and other causes. As a programmer, I certainly don’t want to have my final moment like this:

You see, when you lie on your death bed, you will look deep into your wife’s eyes, and think of all those lovely moments you spend in Visio drawing UML diagrams and writing clean, simple and maintainable code…Stack Exchange User 11170 - http://programmers.stackexchange.com/a/114888/95830

In a recent project, I needed to maintain quite a number (8-9 and growing) of charts that support “real-time” data updates (1 second interval) on a single page. The following open source libraries are what I have tried.

I had a simple problem along the way of exploring Node.js, which involves writing modules that work for both server and client sides. Just like many programmers nowadays, I google’d out a solution (which was written by the person who authored async, so I guess I need to thank him at least twice).

However this doesn’t solve all my problem since I am way too lazy to get rid of all those amazing open source libraries.

I was joking the other day, that by looking at the current Ubuntu version number, one could realize how fast time goes by.

Though I believe these time based concepts are just illusions that human beings created, that I would rather not let them clutter my mind as other unworthy things, they matter in the real world, or meta world that I would like to call it.