For those of us who don’t know, there are mainly four ways of auditing our web application with lighthouse :

• via Chrome dev tools

• Command-line

• NPM module ( which we are going to use in a while )

• PageSpeed Insights

To programmatically perform lighthouse audits, we can use the lighthouse npm package, mocha, and chai for writing our tests and chrome-launcher for running our lighthouse tests.

First, let's install the above packages as dev dependencies in our project :

npm install lighthouse chrome-launcher chai mocha --save-dev

Now, let’s create a file named lighthouse.tests.js in our tests directory. We’ll run our lighthouse audits through this file. Here, we’ll import the lighthouse module and chrome launcher that helps us to open our webpage from the local development server and run the audits to test against a minimum threshold that we want our lighthouse scores to be.

While this might sound a lot to do, it isn’t much. Here’s what it looks like on actual code :

const lighthouse = require("lighthouse");
const chromeLauncher = require("chrome-launcher");

function launchChromeAndRunLighthouse(url, opts, conf = null) {
  return chromeLauncher
    .launch({ chromeFlags: opts.chromeFlags })
    .then(chrome => {
      opts.port = chrome.port;
      return lighthouse(url, opts, conf).then(res =>
        chrome.kill().then(() => res.lhr)
      );
    });
}

And it is as simple as that. We launch the chrome browser instance with the chromeLauncher.launch method and then run lighthouse tests with the site URL and configuration for our audits. After that, we close/kill the chrome instance and return the results. And this is how it looks like when in use :

launchChromeAndRunLighthouse(testUrl, opts, config).then(res => {
  // Results are available in `res`
});

So now, we can put this call inside our before hook for the tests and then have tests for each metric, something like this :

describe("Lighthouse Audits", function() {
  // Timeout doesn't need to be same. It can be more or less depending on your project.
  this.timeout(50000);
  let results;
  before("run test", done => {
    launchChromeAndRunLighthouse(testUrl, opts, config).then(res => {
      // Extract the results you need for your assertions.
      done();
    });
  });
  it("performance test", done => {
    // test your performance score against the threshold
    done();
  });
  // Some more tests..
});

Still looks weird? Don’t worry! Check out this repository for an example setup of lighthouse tests with mocha and try that out with your web application!

This method can be applied to automate the tests in continuous integration/deployment environments so that you don’t have to worry about manually auditing your web application and checking whether it meets the minimum satisfactory levels.

So there you go. That’s all we need to do for automating lighthouse audits for our progressive web applications to make sure they are always worthy of the internet and user’s data packets!

Did you like this article? Or did I miss something? Is there something that you have that can make it even better? Please leave a comment below, or you can also contact me through my social media profiles.

Thank you for reading! 😄

Happy hacking! Cheers! 🎉

Before joining my first job, I had some experience as a freelancer but didn't know much about best practices and architecture apart from what I had come across either online or while development. And even as a freelancer, I didn't have experience with such large scale applications that we had to work with later in the job. This is when I started paying more attention to architecture. At the start, things used to get a little confusing sometimes - mostly because I was a bit more conscious about my code than before - which was obvious as I was part of a team now and not a solo freelancer.

So I started looking through GitHub, online articles, papers, and books. And as I kept working with React more and more on a large scale I had realized that

The key to a robust, scalable, and easy to maintain React application is architecture.

This applies to any application or software but with React, abstraction was a bit more difficult than other libraries/frameworks. This was until Hooks were introduced - but we will keep it out of the context for now as it is still fairly new and most of the applications are still built with older versions of React. Also, there are a lot of improvements to be made; a lot of do's and don'ts to be discovered with its usage.

As of now, I think the principle that I follow for structuring React applications will work fairly well with Hooks too! Since the focus was on a scalable web application architecture - not just React.

Let's quickly take a look at the setup and then I'll walk you through it and try to explain why it is structured that way. So the root of the project looks something like this :

And the src directory ( which will contain all the source code for our application, of course ) is structured like this :

The first thing you might notice and wonder maybe - and if you don't, I'd recommend taking a look again - that we have two directories named config in our project. No, this isn't by mistake! It has an ( extremely ) simple reason.

Two config directories for a single web application?! Why though??

The config directory at the root contains all the configuration files related to build - like our application's webpack config or any other bundler that we might use environment files, and other configs.

You might also notice that it is nested and that the webpack configuration lives in its own directory. This makes the configurations more organized and easier to manage. This might seem trivial but when the application starts growing, and with that the build process might also get complex - which then demands a well-organized place of its own. Also, this brings peace of mind while working with it -- a large mess of configuration files is the last thing you might want while deploying your application in production! 👀

The other config directory inside our src folder is for configurations related to our application, .i.e, the ones related to runtime. This may contain our JSON files ( or any other files ) that might shape the behavior or capabilities of our app. Although this may or may not be required as per your needs but for me, I have had this folder in most of the projects.

But wait, what about the resources and assets directories? Aren't assets also a part of the 'resources' for our react application?

Well, the assets directory here is meant only for images and other media , duhh,

whereas, resources is for data that might be required by our web application, for example, constants and other static data which basically doesn't have any or much logic associated with it. You can also add small methods to return the data, perhaps formatted to specific needs, and/or perform minor operations on them there which can be used by parts of our application, which by the way -- trust me -- will make your code a lot cleaner and more organized.

This directory may also contain data and other 'resources' which can be occasionally fetched, stored and updated; and maybe processed a little before they are used in certain parts of our web application. Well, I guess you get the idea.

And what about our pages and all the react components??

So, here comes the interesting part. At least I think so. This is something that has been derived from a few other solutions on architecting react applications as well as other web applications along with some of my own practical experience. And by far, I'm pretty satisfied with it! 🤓

To start with, let's assume our web application contains a home page, a profile page for the users, and just for the sake of not having just two pages in the example, a third page that we will call -- the other page. So the directory structure would look something like this :

-- src
----- components
----- config
----- pages
--------- home
----------- index.js
----------- index.scss          // Mandatory sass file - I just wanted to make this look realistic!!
--------- profile
----------- index.js
--------- other-page
----------- components
----------- index.js
----- resources

Notice how all the pages have their own separate directory with an entry point? And how that 'other' page has a component folder? Why do we need another component folder? Don't we already have a component folder in the root of src directory?

Wait, just hold on for a second! I'll explain it real quick! ☝

This is what I call the "branching" structure. Each page has their own directory, their own set of components which are not used anywhere else except in that specific page, their own styles rules and other stuff which are associated with only that page. If any component is shared by two pages, guess where they'd go? Yes, you guessed it right -- the components directory in the root of our src directory!

But.. you might wonder.. what is the point of doing that?

Let's say, one day you and your teammates decide to get rid of the 'other' page -- maybe the name wasn't good enough? -- so what do you do? Spend an entire afternoon or a day on removing code, breaking, and fixing the application? NO.

You just go ahead and delete the directory and remove its reference from where it was attached to / used in the web application. And voila, it's done! 💁🏻‍♂️

Nothing breaks in your app just because a bunch of code was deleted! Everything is independent of each other's existence even if they were bound together at some point! A lot less to work with and worry about, isn't it? And yeah, this principle can be applied to almost any application/software and not just some react application.

Some of you might think -- Well no, our application/software is quite complex and stuff is just too interconnected with each other. They shared code, were bridged together, etc. But I guess you might understand now what to do with the "shared code" and "bridges" if you try to apply this principle to it! This is just a simple example to demonstrate and give you an idea of how parts of the product can be organized for convenience and maintainability.

A little tip -- something that I learned while developing progressive web applications with GatsbyJS

You can also go ahead and add another directory to the src -- called layouts ( or maybe add it to the components directory, whichever feels more appropriate to you ) which contains a layout file which is global to the application or even has multiple layouts; each associated with certain parts of the application. For example, let's assume our application also has a fancy navbar and a decent footer that goes into all of our pages. Instead of having them shoved inside our components directory and then repeatedly used inside each page - we can have a layout file that contains the navbar and the footer and renders the children that are passed to it, like so :

<Layout>
 <div>
   Yayy! This is my fancy home page!!
 </div>
</Layout>

// And in the profile page :

<Layout>
 <div>
   This is the page of the user whose data we're secretly trying to steal!
   Please read our privacy policies (not so) carefully!!
 </div>
</Layout>

And in our Layout file, we can have something similar to this :

const Layout = ({ children }) => (
  <>
    <Navbar />
    {children}
    <Footer />
  </>
);

export default Layout;

Better now, isn't it? Even this website, with its simplicity, has a layout component! 🤓

But wait. There's more to architecting react applications!!

Yes, I haven't forgotten about reducers, the lengthy sagas, services, a ton of action creators, and what not! But that's for the second part of this article since I don't want it to become too long and exhausting to read. Also, this first part might serve as a good starting point for beginners or other fellow developers who are new to React development.

Did you like this article? Or did I miss something? Is there something that you have that can be added to this article -- that can make it even better?

Please leave a comment below or you can also contact me through my social media profiles.

Thank you for reading! 😄

Happy hacking! Cheers! 🎉

How many of you have installed Android Studio only to use the emulator for your native app? Oh, and don’t forget the way your system struggles when you try to run it!

And no, I’m not just talking about any average system — even my Macbook Pro with 8GB of RAM makes a lot of noise!

A lot of you might have also come across alternatives like Genymotion, Nox, BlueStacks, and a lot of others. Some are free, while a lot of others with really nice features and performance are paid.

So most of us stick to the free ones or end up downloading Android Studio for the excellent and easy to use emulator it provides.

But it gets worse when you already have Visual Studio Code, a few tabs on Google Chrome, and your music player running!

Also, some of us are just lazy ( and too comfortable with the command line ) that we don't bother installing some fancy GUI application when we can do it with a few commands. 🤓

Okay, enough with the memes, let’s quickly set up Android Studio’s emulator for our react native app in a better way this time — without actually installing Android Studio! ✊

Step 1: Install Java Development Kit 8.

First, you’ll need to install JDK 8. Windows and Linux users can directly visit the link and download it after accepting the license. For Mac users, I recommend installing via Homebrew :

brew tap caskroom/versions
brew cask install java8

Windows and Linux users should make sure that they have set up a path to their Java installation.

Step 2: Install the Android SDK.

Once we have installed and set-up Java in our system, we will need to install Android SDK so that we can get the necessary tools in our systems, including the android virtual device manager and the emulator itself!

Windows and Linux users can directly download the command line tools required for installing the android emulator.

Mac users can install it by running:

brew cask install android-sdk

Note for Mac users: If you run into an error like this while installing android SDK :

Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
at com.android.sdklib.tool.SdkManagerCli.main (SdkManagerCli.java:117)

Then you simply need to run the below command and try installing android-sdk again :

touch ~/.android/repositories.cfg

After installing, make sure you have added android-sdk to your system path.

For Mac and Linux users, you need to add the following line to your .bashrc or .zshrc :

export ANDROID_HOME=/path/to/android-sdk

Important note for the next two steps:

Incase your system complains about not being able to find the command while trying to issue the next set of commands involving sdkmanager , avdmanager or emulator — you can navigate to the directory where it is present inside the android-sdk folder and run them as ./sdkmanager, ./avdmanager and ./emulator respectively.

For those of you who are feeling lazy to find it yourself:

sdkmanager and avdmanager will be located inside android-sdk/tools/bin whereas emulator can be found inside android-sdk/tools.

Now that we know this let’s continue towards a better development experience!

Step 3: Install platform and build tools required for React Native.

Now we can go ahead and set up platform and build tools to help us in creating and running our virtual device in an android emulator. We will use the sdkmanager that we just downloaded to our system as a part of android-sdk.

To do this, open your terminal and run the following command :

sdkmanager "platforms;android-23" "build-tools;23.0.1" "add-ons;addon-google_apis-google-23"

Once we have downloaded the above packages, run the following command to list all the tools available :

sdkmanager --list

This command will fetch the complete list of the available packages on remote that you can download to your system. You can download packages from the list by running :

sdkmanager "sdk-path-for-package"

Note: sdk-path is the string in the leftmost column of the generated list. And it must be wrapped in quotes while running the above command. For example, let’s say we want to create a virtual device which requires Google APIs Intel x86 Atom System Image package, we can install the package by running:

sdkmanager "system-images;android-23;google_apis;x86"

You can download the packages that you need from the list, and if you look closely, you’ll find the android emulator package there too! But don’t worry I won’t make you go through the long list in your terminal, here’s the command you need to run to download the android emulator package :

sdkmanager "emulator"

That’s it! We’ve downloaded the android emulator, and we’re ready to set-up our Android virtual device!

Step 4: Create a new virtual device.

Let’s create an android virtual device with the help of Google APIs Intel x86 Atom System Image we downloaded through the previous command, which was :

sdkmanager "system-images;android-23;google_apis;x86"

Now to create a virtual device, run the following command :

avdmanager create avd --force --name myTestDevice --abi google_apis/x86 --package 'system-images;android-23;google_apis;x86' --device "myTestDevice"

This command will create a virtual device named myTestDevice using the Intel x86 Atom system image we downloaded.

To check if your device was created, you can run :

emulator -list-avds

This will list all the virtual devices present in your system.

If you followed all the instructions correctly, you could see your device listed as well, and you must be able to start your virtual device by running :

emulator -avd myTestDevice

And now, your android emulator will start with the device you just created! But this time in a better way just like you always deserved — without wasting your precious storage space! 🎉

Did you like this article? Or did I miss something? Is there something that you have that can be added to this article -- that can make it even better?

Please leave a comment below, or you can also contact me through my social media profiles.

Thank you for reading! 😄

Happy Hacking! Cheers!

But worried about it if the users would want to install it given its build size? Or maybe you just want to keep it lightweight and not take too much memory unnecessarily when it can be packed into a smaller size?

Or you’re just one of us who are paranoid about build sizes? Don’t worry, we got you covered! 😄 ✔️

In this article, we will cover the following two things:

• Compress the react native application size - by compressing the java bytecode that is generated while building our app and also asking it to try and shrink all the resources that are bundled with the application.

• Splitting our application bundle into multiple APKs to remove unnecessary code which is not required by the device which is going to run it - because a lot of code is bundled with the universal APK that is device-specific - meaning that we don't need a lot of code in the device we're going to install it in.

Let's get started! ✊

First of all, you’ll need to eject your native app if you’re using create-react-native-app for your project ( You might have already done this if you’ve built your application before reading this article ). This is important since you don’t have access to configurations until you eject, as the build folder is where we have to make changes. If you haven’t, you can simply do this by :

npm run eject

Note : Ejecting a react native application is a permanent action! ( Unless you’re using a version control system to keep track of previous versions of your app — from where you can recover the ‘unejected’ version of your app later if you need ). Learn more about ejecting.

Okay, so now we’re all set! Let’s get started and get that done fast. Don’t worry, it just takes a few minutes, and your app size will shrink dramatically!

Now, navigate to the android/app folder from your project root directory where you can find your build.gradle file.

Here, you’ll find your default build configurations already set up, find the line which looks like this :

def enableProguardInReleaseBuilds = false
def enableSeparateBuildPerCPUArchitecture = false

and change their value to true like this :

def enableProguardInReleaseBuilds = true
def enableSeparateBuildPerCPUArchitecture = true

So you might be wondering what it does. Well, if you scroll down a bit you’ll see enableProguardInReleaseBuilds and enableSeparateBuildPerCPUArchitecture written at a few more places like here:

As you can see, these variables are being used to enable or disable two build configurations —

• One for generating separate .apks for different device architectures,

...
splits {
 abi {
 reset()
 enable enableSeparateBuildPerCPUArchitecture
...

Don't worry about having to handle different .apks for each architecture — Google takes care of distributing it to the users! And separating the builds according to architecture removes unnecessary code from your file which is not required on the device it is running.

• Another one for compressing the Java bytecode generated while building, as in,

...
buildTypes {
 release {
 minifyEnabled enableProguardInReleaseBuilds
...

Phew, that was pretty easy! But wait, we’re not done yet! There’s one little thing we need to do.

Now let’s add this line right below the minifyEnabled configuration :

...
buildTypes {
 release {
 minifyEnabled enableProguardInReleaseBuilds
 shrinkResources true; /* <-- Add this line */
...

And we’re done! Now build your app again and check the output directory. You’ll find two different APKs of your app, which is specified in the configuration by default, i.e., for armebi and x86 architectures.

Oh, and by the way, if you need a universal APK that supports all device architectures — just set universalApk to true, and it’ll generate a universal APK next time you run build!

That’s all! Now you’ve set up your build configuration to shrink your code along with resources and create separate APK for different architectures — thus removing unnecessary code from the final build.

Thanks for reading! You can check out more resources on how to reduce the application build size.

Did you like this article? Or did I miss something? Is there something that you have that can be added to this article -- that can make it even better?

Please leave a comment below, or you can also contact me through my social media profiles.

Thank you for reading! 😄

Happy Hacking! Cheers!