DEV Community: Tej Pratap

What makes your web app faster? (part 4, Progressive Enhancements)

Tej Pratap — Tue, 26 Nov 2019 12:34:25 +0000

What makes your web app faster? (part 4, Browser And Progressive Enhancements)

If you are coming to this story directly, i’ll suggest to take a look at part 1, part 2 and Part 3 of this series.

So, last time i left you saying,

“Be indistinguishable from native apps.”

As a web developers we were successful in convincing user to leave there Native Desktop Apps for a web app, Now only few people use an native email client over Gmail. But we are still not able to make user leave there native mobile app for a mobile web app.

This is because a native app feels more comfortable smooth and responsive than a web app. A native app has Push Notification for engagement, Device storage for offline access and much more. But this is changing quickly as web can do more things, check what web can do today.

* Progressive Web App

PWA (Progressive Web App) is the next step in making web feel more native to a device.

PWA give you access to native capabilities such as:

Offline Storage (Service Worker)
Push Notification (Service Worker)
Install as Native (App Manifest)
Open app links (App Manifest)

To use PWA you must be using https

PWA has 2 main Service Worker and Web App Manifest

1. Service Worker:

Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests and take appropriate action based on whether the network is available, and update assets residing on the server. They will also allow access to push notifications and background sync APIs.

To read more about service worker goto MDN.

2. Web App Manifest:

The web app manifest provides information about a web application in a JSON text file, necessary for the web app to be downloaded and be presented to the user similarly to a native app (e.g., be installed on the homescreen of a device, providing users with quicker access and a richer experience). PWA manifests include its name, author, icon(s), version, description, and list of all the necessary resources (among other things).

To read more about web app manifest goto MDN.

Other Enhancements:

As we know javascript executes all operations in a single thread. It becomes a problem while going more intensive tasks such as image processing. To overcome this situation we can transfer that task to Web Worker which will execute that task in a background thread. You cannot touch any DOM element from Web Worker and only transfer data using messages. To read more about Web Worker goto MDN.

What makes your web app faster? (part 3, Client App)

Tej Pratap — Tue, 26 Nov 2019 12:29:41 +0000

What makes your web app faster? (part 3, Client App)

If you are coming to this story directly, i’ll suggest to take a look at part 1 and part 2 of this series.

So, last time i left you saying,

“Not everything has to be done on server.”

We are living in a new age of web development, previously everything was done on server side (Rendering, routing etc). After introduction of AJAX, web development got a whole new way to create and manage user interaction. All the likes, adding comment does not needed a page refresh.

But without using a standard development pattern like MVC, it was getting hard to manage bigger and bigger applications.

Javascript Frameworks:

The Dawn Of Web Frameworks begins in 2009 when a guy at google started working on a js framework the made 18,000 lines of jquery code to 2,000 angularjs code (That app was google feedback).

The reason why they are so successful because:

The use a well proven app development pattern (MVC, MVVC, MV* etc).
Only load parts of web page that is changing (Single page application).
Reusing web components.
If you are using node js server you can user isomorphic javascript for a single codebase.
Takes care of your routing.

Leaders:

There are more than 100 frameworks in market, leaders are:

Angular
React
Vue
Meteor (we will be excluding this)
Backbone
Ember
Polymer

Here is a benchmark of these frameworks fighting for glory,

[## Javascript Frameworks Benchmarks

Duration for updating all 1000 rows of the table (with 5 warmup iterations).

stefankrause.net](http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html?source=post_page-----4ec0d4fde428----------------------)

I won't tell you to use a specific framework over other, you can look at the benchmarks and decide it for yourself.

So, now back to how you can boost your web app’s performance. Using a Javascript framework helps you from generating those heavy HTML pages on server but it also increase time for first meaningful paint.

The way our web app rendered is:

Get Container (simple page).
Load Javascript framework.
Load Controllers.
Get template (not in case of React).
Get api data.
Render template with data.

Which is even slower than older methods, just get HTML and BAMM first meaningful paint is here.

But it is still good because, everything that changes from here will be blazing fast and what can never be matched with traditional server pages.

But there is a solution for above problem → Server Side Rendering.

Server Side Rendering:

In server side rendering, web app’s are rendered as HTML from server and after serving that 1st page client apps kicks in and takes control of application from there. So, it is a mix of old methods with new technology.

Server side rendering also helps in keeping a single code base, you can achieve this with phantomJs (it has a npm module).

But i will suggest take one which handles server side rendering itself, this will boost your app performance big time.

Webpack:

Loading multiple javascript files surely takes more time than all file combined as one. Webpack helps you achieve that.

Javascript frameworks are big topic in itself, I will not going to explain you every one of them.

Choose one Choose Wisely:

One way to choose is, Just have a look at every frameworks homepage, go with the one loads faster.
If you are new to Javascript stay away from things you don't understand (means stay away from angular 2 or reactjs).
Some people also go for creating a minimal framework themself (They say they only needed that much, so why to include 50kb more).
Other way would be to get one which has everything you need.

Personally i would suggest to go for reactjs as they get new and shiny things first. (For now i am so much invested in angularjs, that i cannot leave it. But soon i will give vuejs a try).

OK, it time for another shower thought here:

“Be indistinguishable from native apps.”

Native apps always have a sweet spot in user’s heart, let's change that in next chapter → ** Browsers .**

What makes your web app faster? (part 2, caching)

Tej Pratap — Tue, 26 Nov 2019 12:27:04 +0000

What makes your web app faster? (part 2, caching)

If you are looking to boost performance of you web application, then do read part 1 of this series.

So in last part i left you after saying;

“Best way to use database is, not using it at all.”

Reading database is nothing but reading a well organised file (that is why they are persistent, duh). With use of some amazing algorithms, they are queried, read and written.

But reading a file comes with a cost in terms of cpu utilization and delay to serve those requests. This does not seem big problem when you are serving 4–5 requests per second, but as you reach something like 20–30 requests per second your database starts to show some strange behaviour in serving those requests.

Suppose you run a web app like twitter (which serves 143,199 tweets per sec and for read let's multiply that with 0.2 of 313M Monthly active users which comes close to 8964257.4M reads per sec), It is not possible to query database for every new request, so, solution to this problem is in-memory databases.

in-memory database

Server today do not have any boundaries (not literally), they have huge processing power, petabytes of petabytes of storage and some terabytes of RAM. With this amazing specs we get liberty to do a lot of operations in runtime and store a lot of things in memory.

Reading and writing to memory is faster than anything else, with this idea came concept of in-memory databases.

There are 2 major solutions for in-memory database:

Redis
Memcached

There are more but these are the famous once, and that's what i care about.

Memcached is a little part of Redis, redis is much more than a in-memory key pair database, it has powerful data types, transactions with optimistic locking, fast message channels and much more.

Twitter also uses redis, let me tell how:

Tweets made are stored in redis with an associated key.
Tweets are then pushed to users unique timeline which is also stored in redis (this could be the reason why you cannot update your tweet).
There are more questions like what happens to timeline when user follows another user or unfollows a user, but this is how they give you amazing response time.

So, key points to note here:

Anything which has a large read request but less write request can be stored in a in-memory database.
They can be blog, post or something like a tweet but not who liked post, comments of a post (these generally have a direct access with URL like /postid, /videoid).

If RAM is not a problem then there is no reason to not use a in-memory database.

Some more things that can be done on server side:

Choose a good server side language, because implementation to handle requests are done by those things, they handle your threads and all sorts of other stuff.
Choose a language that can take proper advantage of your server capabilities. That means, it should use 64 bit data bus if provided, use all 8 or 16 cpu cores if provided.
Here as well, you can use distributed system to form a cluster of servers use it as a load balancer.

Now, some more golden words by me:

“Not everything has to be done on server.”

Our server is stronger than ever so does our users devices, we will see how to use its power for some more performance boost with our client app in next chapter → Client App.

What makes your web app faster? (part 1, databases)

Tej Pratap — Tue, 26 Nov 2019 12:24:40 +0000

What makes your web app faster? (part 1, databases)

There is no sure shot way to make your app faster, it is a performance boost at each level of your app. Your database, server, caching, client app, user’s browser they all plays a major role in providing that smooth user experience.

So, let’s begin.

I will proceed like, databases → caching → client app → browser.

Databases:

Today’s databases are fast, secure and has a lot of perks we do not even use.

Databases can be divided into 3 categories (there are more):

Relational Databases
noSQL Databases
Graph databases

And they all have there their purpose in software world and you cannot pick a noSQL database when your application need transactions or a relational database if you need to compute a deeper relation between two separate object.

1. Relational Databases

If you want a great relational database you cannot go wrong with amazon’s Redshift or if you want something at your own system you can use postgreSQL which has been industry standard for a long time. (I use neither, because i don’t need one).

Taking a step ahead, there are some new databases making buzz with their capability to use GPU (Graphics processing unit) for operations, performance results are killing everything else. BlazingDB was featured on TechCrunch Disrupt 2016 and it is the greatest i have seen so far.

2. noSQL Databases

They are hell lot faster than Relational database because they do not have any constraint system (unique, joins or something like autoincrement) Or any kind of transaction (commits or rollbacks).

In noSQL universe cassandra was winning the war and most of the email providers still use cassandra as their way to go database, but lately a trend of startups with all javascript stack arrived since then Mongodb is kicking everybody's ass. Both are fast, industry grade and powerful databases. (I’m using Mongodb, because kick-ass).

3. Graph Databases

They are relatively new in the game and i do not know much about them, Only that they are best if you want some deep analytics/relations between objects. They can filter results based on some crazy combination of links. I personally did not get a chance to use any of these databases. If you simply google “Graph Database” you get first result for neo4j. So, i assume this is the best option available. But still, i do not have any evidence for this being the best.

So, now you know which one is best in what category. Choosing correct database is a crucial part, once you have set your heart on a one it will be very hard to migrate to other one (there are plenty examples set by big companies for this).

Now, all the databases have more or less same performance benchmarks and choosing one will not give you a solid upper hand in performance. So, to get the fastest performance, you have to follow these things:

Optimize your query: the way you structure your query will play a major role in your database performance. Fine tune your queries.
Minimal select: Do not select all properties (columns) as a query result. select only those you need at that point of time.
Distributed database: Distributed database cluster can save your ass by a big margin but they are a little hard to setup/manage. In a simple setup, you can test a master-slave system that can increase your fault tolerance, can act as load balancer on a peak time.
Computed data: If you can get some property by some simple mathematical computation then do that instead of selecting it from database, like percentage, profit, loss etc. Do not do it for complex operation like generating hash or finding mean of a large dataset.
Opposite of point 3: Although your machine will be a lot faster than your database but in some cases like fuzzy search (soundex source), pattern recognition etc. Store computed result in the database and query with newly computed property.

Remember the next few golden words for database optimizations.

“Best way to use database is, not using it at all.”

Meaning of above quote will be explained in next part → Caching.