DEV Community: Haseeb

Understanding PWAs - Exploring the Twitter PWA with Dev Tools

Haseeb — Sat, 10 Apr 2021 23:43:53 +0000

PWAs (Progressive Web Apps) have been around for quite some time now. With time the PWA developer ecosystem and browser support has become mature and most of the top web platforms are now starting to add PWA support to their web apps. So what exactly is a PWA?

MDN's under construction PWA page defines a PWA as

"Progressive Web Apps are web apps that use emerging web browser APIs and features along with traditional progressive enhancement strategy to bring a native app-like user experience to cross-platform web applications. Progressive Web Apps are a useful design pattern, though they aren't a formalized standard."

If this definition is too vague or broad for you, you can safely assume that PWAs are web apps which run in the browser but can be "installed" on the user's smartphone or computer to provide a native app like behavior but in the browser. Generally, some offline functionality or graceful application behavior without network connectivity is expected from PWAs.

To better understand how PWAs are implemented and what better experience this web application design pattern provides, let's try to dig into and reverse engineer the Twitter PWA using the Chrome Dev Tools.

The Manifest 📜

If your web app is going to be "installed" it needs to have some metadata, e.g the app's name, icons for different resolutions and a url to which the app opens to by default. All of this information is added in a json file present at the /manifest.json path.

Here is a screenshot of the Twitter's manifest.json file.

You can see the detail you can provide and the support for the possible interoperability of the Twitter Android native and the PWA app using the android_package_name property. Pretty powerful and feature rich!
Read more about the manifest file and what it can support here.

Service Worker 🧑‍🏭

The ❤️ of PWA - service worker is a JS script that lives separate from the browser page. Among other features, it provides a network proxy for the web page it is running for. This means every network request originating from that page passes through the service worker. This opens up possibilities and provides more control over resource caching, offline application behavior and requests for resources or API calls that are sent to the server.

The Twitter service worker is registered under the https://twitter.com/ path which means it will work as service worker for all paths under the twitter.com host. Service workers once installed against a web app keep running even when you navigate away from the page and become active every time user goes to the URL for which a service worker is registered in the browser. Read more about the lifecycle, features and nuances of service workers here.

Cache Storage 🛍️

The Cache Storage Web API provides a simple way to implement caching of resources in the browser. It is important not to confuse this API with the default browser caching implemented by default.

As you can see there is a list of js files stored in the cache storage and each one of them has a path in the name field. Remember when we said that the service worker acts as a network proxy for the page. This means every request for these js resources originating from twitter.com first passes through the service worker.

The service worker is implemented in such a way that for every resource request it first checks if the resource is present in the cache storage. If it is, the page is sent a 200 OK response along with the required resource, without ever hitting the twitter.com servers. You can see a live demo of it in the Network console.

As you can see in this screenshot, for the js resource bundle.HomeTimeline...js the request never hits the servers and the twitter.com page still gets the 200 OK response along with the script.

Similarly, the HTML skeleton/shell of the Twitter app is also cached.

Even if there is no internet connection, the Twitter web app's HTML and JS will be served to the page from the Cache Storage by the Service Worker, making the app resilient to slow or no internet connectivity.

IndexedDB 💾

Another one of the emerging web browser API that PWAs use is the IndexedDB API. The IndexedDB is an interface for storing and accessing structured data within the browser.

Twitter makes interesting use of this feature for optimizing user experience by storing different kinds of less frequently changing metadata for the logged in user and some recent user activity so that it can be fetched directly from within the browser when needed.

A quick look under the IndexedDB category for twitter.com shows multiple IndexedDB instances, some with only a single Object store, some with multiple.

Expanding in and looking at the contents of one of the DBs with an object store called keyvaluepairs we can see that it has stored a list of my recently used emojis on Twitter.

The Object store in the DB with the identifier localforge contains some more metadata about the user.

This kind of data could have been stored using good old Local Storage but newer features like IndexedDB are meant to server as an objectstore database for your application right within the browser.

Installing the Twitter PWA ⬇️

You can use a little button in the Chrome browser URL field to install the PWA as an app.

Once installed, you now have a Twitter app icon in your dock/task bar and the app opens in a separate window different from your browser.

The Offline Test 🚫

Let's see what happens if I turn off my network and try opening the newly installed Twitter PWA.

As you can see, the app's UI gets loaded. Most of the navigations work, but no tweets or trends data is loaded. It is important to understand:

The UI works because the app's HTML and CSS are in Cache Store and are being served through the service worker
The interactions and navigations work because the JS implementing those is also stored in Cache Store.
The profile page shows some of the user metadata, which means that data is stored somewhere maybe in the IndexedDB from which the app is fetching it rather than the API.
As the installed Twitter app is actually only a separate Chrome instance which only goes to https://twitter.com, but we are not seeing the 'No Internet Connection' page with a trex because the Service Worker is acting as a network proxy and still serving content and responding to the network requests of the twitter.com page even without a connection to the Twitter servers.

Phew you reached the end! Hopefully, you learned something new. If you want to ask a question, leave your thoughts about PWAs or you think there's a mistake in the article above, I'll be glad to hear from you in the comments below. You can also reach out to me on Twitter @haseebelaahi 🙂

What would this JS code print? 🤔

Haseeb — Mon, 09 Mar 2020 18:51:44 +0000

What do you think this piece of code will print? Most of you might know the answer but the behavior is really interesting to me and got me thinking and learning about a very important concept in JS.

function saySomething() {
    var greeting = "Hello";
    {
        greeting = "Howdy";
        let greeting = "Hi";
        console.log(greeting);
    }
}
saySomething(); //what would this print?

How to Work with a Not so Perfect Codebase - Based on My Experience of Working in One!

Haseeb — Thu, 25 Jul 2019 19:10:07 +0000

There is a good chance that at some point in our careers we find ourselves working in a difficult, not-so-perfect codebase. Maybe the code was initially written for an MVP with hacky code but now you have a full-fledged product built on top of it, maybe the code was maintained for years by a number of people without a proper code owner and code review process and now it is just thousands of lines of code that nobody is there to own, maybe the requirements changed so dramatically that most of the already written code became obsolete.

If you become part of a team which is dealing with a scenario similar to any of those mentioned above or in general you are dealing with a codebase that is not very readable, consistent and easy to tread through, I have tried to put out a short list about how to manage through, bring sanity and actually actively improve such codebases along with developing features according to business requirements - based on my experience with working on one such codebase.

1. Acknowledge the Issues 🔧

After every member of the team has spent some time with the codebase, the first thing you want to do is to have a discussion among your team with everyone sharing their opinion and acknowledging the issues that exist with the current architecture, the way the code is written, the practices that are followed or the lack of such practices.
It is important to have all members of the team on the same page about what is wrong and what needs to be fixed.

2. Tackle One Problem at a Time 🔨

Do not try to fix everything in one night! When it took years to get there, it is going to take you some time to fix it.
Identify parts of the application or specific modules that need improvement, decide how much every area is critical to your operation and prioritize accordingly.

3. Respect the Business Objectives 💰

Most of the products/projects developed in professional settings contribute towards helping a business achieve its goals. For an organization, achieving those business goals is the first and foremost priority.
As a developer, we need to respect those business objectives and make sure our quest to 'improve' the code doesn't come in the way of achieving our business's goals. Always remember when you are there to cross the swamp and when to fight the alligators 🐊 (<-- I know this is a crocodile)

// Detect dark theme var iframe = document.getElementById('tweet-1144647007627284481-553'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1144647007627284481&theme=dark" }

Showing respect for the business objectives also helps you build a relationship of trust with the product requirement and specifications teams. This will help you get more time assigned to cleaning things up.

// Detect dark theme var iframe = document.getElementById('tweet-1145052576167186433-190'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1145052576167186433&theme=dark" }

4. Establish a Code Review Process 👀 👀

Once you have agreed that you need to improve the codebase, the next step you want to do is to have a code review process. It is always better to put multiple sets of eyes on every piece of code that gets checked in. It is not necessary to have a senior resource review the code, initially, you could just start by peer-reviewing. This will also help the team eventually get familiar with different parts of the codebase.

5. Integrate Refactoring in Your Regular Bug Fixing/Feature Delivery ⬆️ ⬇️

Sometimes it becomes very hard for developers to get dedicated time assigned for code refactoring specifically especially in small to medium-sized projects with limited resources.
Continue your little operation cleanup along with every task, bug fix or feature you check into the code. This way every part of the code that gets touched will keep getting cleaned up without putting a significant effort at once.

All of my observations come as a junior engineer with 2 years of experience only, spending about a year with one such codebase and seeing it improve with each passing day. My opinions could also be biased only by the kind of teams and projects I have worked on.

Devs trying to find their way through such codebases, what do you guys think of this? Senior, more seasoned guys who have years of experience doing this correct me if I'm wrong or want to add something!

What Not to Do as a Programmer - My List After 2 Years of Working In Teams

Haseeb — Fri, 19 Jul 2019 05:07:41 +0000

There is a lot of content out there discussing what you need to do to become a good programmer. What concepts you need to understand, what technologies you need to learn, what tools you have to know, etc. When I joined the tech industry 2 years ago with dreams of being a great programmer who will change the world with code one semi-colon at a time, I had a mental list of what I need to learn in order to be an awesome dev. Over time I have learned that there should've been a list of what not to do as a programmer, dev, software engineer/ninja or whatever you call yourself.

I'm trying to put together a list here to keep reminding myself and for those who have just started their careers or are going to, soon!

1. Do Not Fall In Love ❤️ With Your Code

The number 1 mistake a lot of devs make at the start of their careers is treating their code like their babies or pets.
Sure, we all love our work but always remember what your end goal is, to write good code and collectively contribute to making the product/project you are working on better every day.
When you don't attach your feelings with the code you write, there is a better chance you'll always try to make it better and not let your feelings come in way of improving it.

2. Do Not Try to Learn Everything 📖

The kind of business we are involved in, there is always something new around, that new JS framework, a new library or another new productivity tool.
Do not lose your focus by thinking that you need to be expert in every tool and technology that is around. Keep exploring and trying out new technologies and stacks but always keep your focus on something particular.

3. Do Not Worship Frameworks & Languages💎

Sure keep your focus on something particular but at the start of your career do not try to put a label on yourself. Do not call yourself a ROR Engineer or a React Developer. Sure you work on React but do not let that define you. Frameworks and languages will come & go, you are here to stay!

4. Do Not Feel Proud if your Team Depends Heavily on You 👦

One thing I always thought of something to be proud of was doing a lot of heavy lifting in a team. I always thought the best programmer would be the one without whom the team will not be able to function. Do not try to be that guy! Teams that have a uniform distribution of responsibility and workload are less prone to failures and crisis. Always try to enable other members of your team and not keep the knowledge and expertise to yourself. Do not try to be that hero who's always there to save the day!

5. Do Not Mind 😠 Negative Feedback

Always assume that other people who work with you want to see a better self of yours. Do not take criticism or negative feedback from your coworkers as a personal attack on you. Listen to the feedback, contemplate and try to improve.

6. Do Not Keep Complaining ⁉️

Always try to take initiative rather than complaining. Realize the fact that even as a young or junior dev you are now part of the team. Do not act as an outsider who keeps complaining rather take initiative and suggest options to make things better.
Note: This does not apply at all in case of abusive, threatening, discriminating or harassing behavior. Do not wait a moment to report any such behaviors.

7. Do Not Point Fingers 👉

If something goes wrong e.g a deployment fails, bad code gets into master or a server breaks down, do not start pointing fingers at individuals. Teams operate as collective entities and take responsibilities as groups. Sure, you want to find out what went wrong but that does not mean you single out individuals and blame them.

8. Do Not Remove Your Work-Life 👪 Boundaries

Keep in mind that you have a life outside of your profession. Do not let being a programmer come in way of having quality time with your family, quietly reading a book or going on a vacation.

All of my observations come as a junior engineer with 2 years of experience only. My opinions could also be biased only by the kind of teams and people I have worked with.

Junior devs working in teams early in their careers, what do you guys think of this? Senior, more seasoned guys correct me if I'm wrong or want to add something!

Edit: There are some brilliant new points and discussion on these in the comments section. Please go through those as well, happy coding :)

What I Found When I Went Through My Facebook Location Data

Haseeb — Fri, 03 May 2019 22:19:14 +0000

Some visualizations and stats on my facebook location data and the results, well you could say are not very pleasant.

Image Source: www.cpomagazine.com CPO Magazine

For some time Facebook has been allowing users to download the data it has on them, so one curious night I went ahead and downloaded all of my location data that Facebook has.

Screen Capture: Facebook, Download Your Information Page

Facebook allows you to download your data as browser viewable HTML, but that view isn’t really interesting and doesn’t reveal much (as Facebook would probably want 🤷‍♂️). The HTML view just gives you a boring list of coordinates like this.

Screen Capture: Facebook User Location Data

I downloaded the data in JSON which is another of the supported formats and did some basic stats & visualizations.

I have been a Facebook user since 2011 but started using the Facebook app on my phone 3–4 years later. All of the stats and visualizations here are from location data ranging from January 2015–April 2019.

Number of Times Facebook Stored My Location

Facebook accessed and stored my location for a total of 2818 times in the period from start of 2015 to April of 2019 averaging almost 650 times a year , 54 times a month 🙀 or twice every day 😮. When you think about these numbers for a moment, it almost feels like basically being tracked literally all the time!

Stored Locations By Year

Facebook’s location collection seems to be tied with how often your location changes and obviously having your phone’s location turned on is a prerequisite. This graph shows a trend of location entries by each year.

My location data on Facebook by year

The reason for the huge spike in data collection from 2016 to 2017 is maybe due to some change in Facebook’s location collection policy or probably I just bought a good smartphone in 2017 and started having the location turned on all the time on my Android smartphone.

Busiest Location Collection Days

Digging deeper into the data, I went ahead and filtered out the ten days which had the highest location collection frequency. Can you guess how many times at maximum my location got stored on Facebook on any given day?

50, 100? Nope, Two Hundred and Thirty-Eight times!

Top 10 Highest Location Collection Days

Turns out I was traveling on that particular day and was on the road for the most part of my day and Facebook like any worried parent would do, checked on me for 238 times…

What would all of this data look like on a map?

Naturally I wanted to put all of this latitude and longitude data on an actual map to visualize where I have been moving around in all these years!

My location data from Facebook on my hometown’s map

So this above is a visual representation of my location data that Facebook has almost in a 15km radius of my house in my hometown (Lahore, PK). Each blue dot represents one instance of a location captured and stored by Facebook.

For some of the locations marked here I didn’t even remember visiting that area but thanks to Facebook for providing hard evidence I recalled _everywhere I’ve been in the past 4 years _ 🙃

With the location data, timings for each location capture and Facebook’s resources it is very easy to infer any Facebook app user’s home address, workplace, where do they go on weekends regularly, which restaurants they eat at and so on. All of this definitely makes targeting ads easier and of course classifying specific user personas for political and social purposes.

Considering the latest speculation about Facebook launching a dating service of their own, this data could be of a lot more use in “👫 bringing people together”!

So, next time when you meet someone and the next thing is that they start appearing in your ‘Suggested Friends’ list don’t get surprised 😆

You can find detailed analysis on my Facebook data here on Kaggle

https://www.kaggle.com/helahi/facebook-messages-analysis

Thank you for making it through! If you think I should dig in some more into this data to find any other stats or patterns, let me know in the comments!