DEV Community: Guilherme Oenning

🔥 Why I chose Tauri instead of Electron 🔥

Guilherme Oenning — Mon, 31 Jul 2023 12:33:44 +0000

TL;DR

I struggled to get started with Electron, which led me to find Tauri. It got me hooked due to it's incredible developer experience and I thought I'd share the journey of building an app with Tauri.

How it all started...

About a year ago, I decided to experiment with building a Desktop application.

I wasn't happy with the other apps in the niche I was working on, and I thought I could build something better. I have worked as a full-stack developer for a very long time, but I had never built a desktop application before.

My first thought was to build with SwiftUI. Developers love native apps, and I've always wanted to learn Swift. However, building on SwiftUI would limit my audience to macOS users only. I had a feeling that most of the users would be on macOS anyway, but why limit myself when I could build a cross-platform app?

Looking back now, I'm really glad I discarded SwiftUI early on. Just look at the diverse number of operating systems that people are using my app on.

By the way, this screenshot is from Aptabase, an open source analytics platform I'm working on.

https://github.com/aptabase/aptabase

Drop us a ⭐️ if you like it!

What about Electron?

I don't live under a rock, so I knew that Electron was a thing and that many of the popular apps I use daily are built on Electron, including the editor I'm using right now to write this post. It seemed like a perfect fit for what I was trying to do because:

✅ Single code base can target multiple platforms.
✅ Works with React + TypeScript + Tailwind, which I'm already familiar with.
✅ Very popular = lots of resources and guides.
✅ NPM is the largest (is it?) package ecosystem out there, which means I can ship things faster.

The other benefit of building on Electron was that I'd be able to focus on building the app rather than learning something completely new. I love learning new languages and frameworks, but I wanted to build something useful quickly. I'd still have to learn about Electron itself, but it wouldn't be as steep as learning Swift and SwiftUI.

Okay, let's get started!

I was settled. Aptakube was going to be built with Electron.

I normally don't read the documentation. I know I should, but I don't. However, I always read the Getting Started section whenever I pick a framework for the first time.

Popular frameworks have a npx create {framework-name} that quickly bootstraps an app for us. Next.js, Expo, Remix, and a lot of others have this. I found this super useful because they allow you to get started quickly, and they often give you a bunch of options like:

Do you want TypeScript or JavaScript?
Do you want to use a CSS framework? What about Tailwind?
Prettier and/or ESLint?
Do you want this or that?

The list goes on. It's such a great developer experience that I wish every framework had one.

Can I just `npx create electron-app`?

Apparently, I can't, or at least I haven't found a way to do it, certainly not in the Getting Started section.

What I found instead was a quick-start template that I could clone from Git, install the dependencies, and be on my way.

However, it's not TypeScript, there is no bundler, no CSS framework, no linting, no formatting, nothing. It's just a bare-bones app that opens a window.

I started building with this template and adding all the things I wanted to make it work. I thought it would be easy, but it wasn't.

An electron app has three entry points: main, preload, and renderer. Wiring that all up with Vite was painful. I spent around 2 weeks of my free time trying to get everything working. I failed, and I got frustrated.

I then found dozens of other boilerplates for Electron. I tried about five of them. Some were OK'ish, but I was a bit put off by the fact that most templates were too opinionated and installed way too many dependencies that I didn't even know what they were used for. Some didn't even work at all as they've been abandoned for years.

In summary, the developer experience for someone new to Electron is below average. Next.js and Expo have set the bar so high that I've come to expect that every framework would offer a similar experience.

So what now?

While mindlessly scrolling through Twitter, I saw a tweet from Tauri about the 1.0 release. They had been around for 2 years at that point, but I had no idea what Tauri was. I went to their website, and I was blown away 🤯 It seemed like exactly what I was looking for.

Do you know the best part? They had a npm create tauri-app instruction right there on the home page.

I decided to give it a try. I ran the create the tauri-app command, and the experience was very similar to Next.js. It asked me a few questions, and then it created a new project for me based on my choices.

At the end of the process I could simply run npm run dev and I had a working app with hot-reload, TypeScript, Vite and Solid.js, pretty much everything I needed to get started. I was impressed and excited to learn more. I had to add Prettier, Linters, Tailwind and all that kind of stuff, but I'm used to it, and it was easier than in Electron.

Getting started (again 😅), but with Tauri

While in Electron I could build the whole app with just JavaScript/HTML/CSS, in Tauri the backend is in Rust and only the frontend is JavaScript. That obviously meant I had to learn Rust, which I was excited about, but also did not want to spend much time on as I wanted to build the prototype quickly.

I've used 7+ programming languages professionally, so I thought learning Rust would be a walk in the park.

I was wrong. I was so wrong. Rust is hard, like really hard, or at least it was for me!

One year later, after more than 20 releases of my app, I still can't say I truly know Rust. I know enough to be constantly shipping new features on a regular basis, but I'm still learning so much every time I have to write something in Rust. GitHub Copilot and ChatGPT have been a huge help, and I still use them both a lot.

However, there is something in Tauri that makes this process a lot easier.

Tauri has the concept of a Command, which is like a bridge between the frontend and backend. You can define commands in your Tauri backend using Rust and call them from JavaScript. Tauri itself provides a bunch of commands that you can use out of the box. For example, you can open a file dialog, read/update/delete a file, make HTTP requests, and a lot of other interactions with the operating system right from JavaScript, without having to write any Rust code.

Well, what if you need to do something that is not available in Tauri? That's where Plugins come in. Plugins are Rust libraries that define commands you can use in your Tauri app. I'll talk more about plugins later but just think of them as a way to extend Tauri's functionality.

I've actually asked a lot of people building apps in Tauri if they had to write Rust code to build their apps. Most of them said they had to write very little Rust for some niche use cases. It's totally possible to build a Tauri app without writing any Rust code at all!

So how does Tauri compare to Electron?

1. Programming Language and Ecosystem

In Electron, your backend is a Node.js process and your frontend is Chromium, which means a web developer can build a desktop app with just JavaScript/HTML/CSS. There's a huge ecosystem of libraries on NPM and there is just so much content about it on the internet that makes the learning process a lot easier.

However, while it's generally seen as a good thing to be able to share code between the backend and frontend, it can also get confusing as developers might try to use backend functions on the frontend and vice versa. So you'd have to be careful not to mix things up.

In contrast, Tauri's backend is Rust, and the frontend is also a webview (more on this next). While there are a significant number of Rust libraries, they're nowhere near the size of NPM. The Rust community is also a lot smaller than the JavaScript community, which means there's less content about it on the internet. But as mentioned above, depending on what you'll be building, you might not even need to write much Rust code at all.

My opinion: I simply love the clear separation of backend and frontend that we get in Tauri. If I'm writing a piece of code in Rust, I know it'll be running as an OS process, and I have access to the network, file system, and a bunch of other things, while everything I have written in JavaScript is guaranteed to be running on a webview. Learning Rust has not been easy for me, but I'm enjoying the process, and I'm learning a lot of new things in general! Rust has started to grow in me 😊

2. Webview

In Electron, the frontend is a Chromium webview that is bundled with the app. This means you can always be certain of the version of Node.js and Chromium version used by your app, regardless of the operating system. This comes with major benefits, but also some drawbacks.

The biggest benefit is the ease of development and testing, you know what features are available, and if something works on macOS, it'll more than likely work on Windows and Linux as well. The drawback, however, is that your app size will be a lot bigger because of all these binaries bundled into it.

Tauri takes a drastically different approach. Instead of bundling Chromium with your app, it uses the operating system's default webview. This means that on macOS your app will use WebKit (Safari's engine), on Windows it'll use WebView2 (which is based on Chromium) and on Linux it'll use WebKitGTK (same as Safari's).

The end result is an extremely small app that feels super fast!

As a reference, my Tauri app weighs 24.7MB on macOS, while my competitor's app (Electron) weighs 1.3GB. 😱

Why does it matter?

It's so much faster to download and install.
It costs less to host and distribute (I run on AWS so I pay for bandwidth and storage).
I often get asked if my app is built with Swift, as users usually have a "this feels like a native app" moment when they see such a small and fast app.
Security is handled by the OS. If there's a security issue with WebKit, Apple will release a security update, and my app will simply use it. I don't have to ship an updated version of my app to fix it.

My opinion: I like the fact that my app is so small and fast. I was initially worried about the lack of consistency between operating systems because that meant I needed to test my app on all 3 operating systems, but I haven't had any issues so far. Web developers are used to this anyway, as we have been building multi-browser apps for such a long time. Bundlers and polyfills also help a lot in this regard!

3. Plugins

I briefly mentioned this before, but I think it's worth going into more detail as it's one of the best features of Tauri, in my opinion. A plugin is a collection of Commands written in Rust that can be called from JavaScript. It allows developers to compose applications by putting together different plugins that can either be open source or defined within your app.

It's a nice way of structuring an app, and it makes it easy to share code between different apps too!

Some examples of plugins you'll find in the Tauri ecosystem:

tauri-plugin-log - Configurable logging.
tauri-plugin-store - Persistent state for things like user settings
tauri-plugin-window-state - Persist window sizes and positions.
window-vibrancy - Make your windows vibrant.
tauri-plugin-sql - SQL client that works with SQLite and more
tauri-plugin-aptabase - Analytics for Tauri apps.
and a lot more...

These features could have been part of Tauri itself, but having them separately means you can pick and choose what you want to use. It also means they can evolve independently and be replaced with alternatives if something better gets released.

The plugin system was the second biggest reason why I chose Tauri; it makes the developer experience 1000x better!

4. Feature Parity

When it comes to features, both Electron and Tauri are very similar. Electron still has a few more features, but Tauri is catching up fast. At least for my use case, Tauri has everything I need.

The only major inconvenience for me was the lack of a Native Context Menu API. This is a highly requested feature by the community and would make Tauri apps feel a lot more native. I'm currently doing this with JS/HTML/CSS which is OK but could be better. Hopefully, we'll see this land in Tauri 2 🤞

But other than that, there's plenty in Tauri. Right out of the box you get notifications, tray, menu, dialog, file system, networking, window management, auto-updating, packaging, code signing, GitHub actions, sidecars, etc. And if you need something else, you can always write a plugin for it, or use one of the existing ones.

5. Mobile

This one came as a surprise to me. At the time I'm writing this, Tauri has experimental support for iOS and Android. It seems like it was always part of the plan, but I didn't know about it when I started my app. I'm not sure if I'll ever use it, but it's nice to know it's there.

This is something that is not possible with Electron, and probably never will be. So if you're planning to build a cross-platform mobile and desktop app, Tauri may be the way to go, as you'd likely be able to share a lot of code between them. Designing mobile-first interfaces with web technologies has gotten a lot easier over the years, so building a single interface that could run as a desktop and mobile app is not as crazy as it sounds.

I'll just drop this here to get you all excited about the future of Tauri.

As Jonas mentioned in his tweet, this is experimental and hacky; it might take a long time to be production ready, but it's still very exciting to see the innovation happening in this space!

Conclusion

I'm very happy with my decision to use Tauri. Combined with Solid.js I was able to make a really fast app, and people love it! I'm not saying it's always better than Electron, but if it has the features you need, I'd say give it a try! As mentioned before, you might not even need to write that much code in Rust, so don't get intimidated by that! You'll be surprised by how much you can do with just JavaScript.

In case you're into Kubernetes, check out Aptakube, a Kubernetes Desktop Client built with Tauri 😊

I'm now working on [Aptabase]https://github.com/aptabase/aptabase), an open-source and privacy-friendly analytics platform for desktop and mobile apps. It already has SDKs for various frameworks, including Tauri and Electron. By the way, the Tauri SDK is packaged as a Tauri Plugin! 😄

Lastly, I'm also active on Twitter. Feel free to reach out if you have any questions or feedback. I love talking about Tauri!

Thanks for reading! 👋

Complete Guide to Kubeconfig and Kubernetes Contexts

Guilherme Oenning — Fri, 16 Jun 2023 09:04:18 +0000

What the heck is Kubeconfig anyway?

When interacting with a SQL database such as Postgres, for example, developers often need the so called Connection String, which is a string that contains all the information needed to connect to the database. This includes the database host, port, username, password, and so on. All this information is often stored in a single string, which is then used by the application to connect to the database.

Kubeconfig is sort of a connection string, but for Kubernetes clusters. It contains all the information needed to connect to a Kubernetes cluster, including the cluster host, port, authentication method, and so on.

However, unlike the connection string, Kubeconfig is a file. It's often stored in the ~/.kube/config file and it's used by pretty much all Kubernetes tools, such as kubectl and Aptakube.

Let's take a look at a Kubeconfig file

apiVersion: v1
kind: Config
current-context: minikube
clusters:
  - cluster:
      certificate-authority: /Users/goenning/.minikube/ca.crt
      server: https://127.0.0.1:51171
    name: minikube-local
contexts:
  - context:
      cluster: minikube-local
      namespace: default
      user: admin
    name: minikube
users:
  - name: admin
    user:
      client-certificate: /Users/goenning/.minikube/profiles/minikube/client.crt
      client-key: /Users/goenning/.minikube/profiles/minikube/client.key

This is a Kubeconfig file generated by Minikube, which is a tool that creates a single-node Kubernetes cluster on your local machine. It's a great tool for learning Kubernetes and for developing applications locally.

Each kubeconfig file contains three main sections: clusters, contexts, and users. These sections are defined as an array of objects because you can have multiple clusters, contexts, and users in a single kubeconfig file. However, when working with multiple clusters it's often recommended to keep a separate kubeconfig file for each cluster, or at least group some clusters together in a single kubeconfig file based on whatever they have in common.

The context is what links the cluster and the user together. Every operation you perform in Kubernetes is done in a context, which is why kubectl has a --context parameter for you to specific which cluster you want to interact with.

The cluster object defines where the cluster is located (server) and what client certificate (certificate-authority) to use during the SSL handshake. This section may also contain other settings such as proxy-url in cases where the cluster can only be accessed through a proxy.

The user object defines the authentication method to be used when connecting to the cluster. In this case, the user is using a client certificate, which is a common authentication method for local clusters.

Using the Kubeconfig file with kubectl

When using kubectl (or any other Kubernetes tool), by default it will look for the kubeconfig file in the ~/.kube/config path. However, you can specify a different path using the --kubeconfig parameter or the KUBECONFIG environment variable. Here are some examples:

kubectl get pods # uses ~/.kube/config
kubectl get pods --kubeconfig /path/to/kubeconfig # uses config from /path/to/kubeconfig
KUBECONFIG=/path/to/kubeconfig kubectl get pods # same as above

In case you have multiple clusters in your kubeconfig file, you can use the --context parameter to specify which cluster you want to interact with:

kubectl get pods --context prod-europe # uses the prod-europe context from the ~/.kube/config
kubectl get pods --context prod-europe --kubeconfig /path/to/kubeconfig # uses the prod-europe context from /path/to/kubeconfig

Setting the --kubeconfig parameter on every command is tedious, so you can also set the KUBECONFIG environment variable to point to the kubeconfig file you want to use. This is especially useful when you have multiple kubeconfig files that you interact with constantly.

If you're on macOS or Linux, you can set the KUBECONFIG on your shell profile (e.g. ~/.bash_profile or ~/.zshrc) so that it's always available on future shell session and you don't have to set it manually every time.

Here's a cheat sheet with some useful context related commands:

kubectl config get-contexts             # display list of contexts
kubectl config current-context          # display the current-context
kubectl config use-context prod-europe  # set the default context to my-cluster-name

kubectl config use-context basically modifies your Kubeconfig file and sets the current-context to the one you specified. This is useful when you want to switch between contexts without having to specify the --context parameter every time.

Authentication and Security

Last topic we'd like to cover is related to how to keep your Kubeconfig file secure. The Kubeconfig file may contain sensitive information such as tokens and private keys, so it's important to keep it safe. However, the the best option to protect your cluster is by not having any sensitive information in your Kubeconfig file.

Authentication is where things can get tricky. There are many ways to authenticate to a Kubernetes cluster, and some of them are more secure than others. Some popular ones are:

Token: This is by far the worst authentication method in terms of security. If you Kubeconfig gets leaked, unless you've got some other network protection, anyone can use the token to access your cluster. Avoid using this for any important cluster, but it's generally OK to use on local clusters for testing/development purposes.
Client Certificate: This is somewhat similar to a token, however it can slightly safer if the content of the certificate is usually stored in a separate file. So even if the Kubeconfig gets leaker, the attacked might not have got access to the certificates.
Exec Plugins: This is what most cloud providers and managed Kubernetes services would recommend you to use. It's essentially an extension of Kubeconfig to use external CLI tools (such as the aws CLI, az CLI or gcloud CLI) to perform the authentication using a cloud-based IAM mechanism. This is the most secure authentication method because it doesn't require any sensitive information to be stored in the Kubeconfig file. However, it's also the most complex one to setup as it requires additional knowledge of each cloud provider and how to use their CLI tools.

Connecting to multiple clusters simultaneously

When working with multiple Kubernetes clusters, it might be useful to connect to more than one cluster at the same time so you can see the status of your application across multiple clusters in one view. This is especially useful when you're running an application across different regions or even multi-cloud.

Aptakube is GUI application for Kubernetes that uses the same Kubeconfig files we mentioned above and can connect to multiple clusters at the same time. It essentially presents all your Kubernetes resources as if it was a single clusters. We invite you to try it out free today 😊

How to detect iPadOS with Swift

Guilherme Oenning — Tue, 04 Apr 2023 11:37:20 +0000

The iPadOS was first introduced in 2019 and it is an operating system based on iOS. In some cases you might want to add some extra functionality to your app when running on iPadOS, or maybe you want to show a different UI. This short post will show you how to detect iPadOS with Swift.

The UIUserInterfaceIdiom enum is what you want to use to detect the user interface idiom, which can be accessed via the userInterfaceIdiom property on the UIDevice class. The UIUserInterfaceIdiom enum has a pad option which you can use to detect if the device is an iPad.

if UIDevice.current.userInterfaceIdiom == .pad {
    print("This is an iPad!")
}

But wait, there is more! Just because it's an iPad doesn't mean it's running iPadOS. Its only since the iOS 13 release that the iPad has been able to run iPadOS. So if you want to detect iPadOS specifically you can use the systemVersion property on the UIDevice class to check if the version is greater than or equal to 13.

if #available(iOS 13.0, *) {
    if UIDevice.current.userInterfaceIdiom == .pad {
        print("This is an iPad, and it's running iPadOS!")
    }
}

What about the `UIDevice.current.systemName`?

This property returns the name of the operating system. As of 2023, this property correctly returns iPadOS for iPad devices running iPadOS. But this was not always the case, up until iPadOS 15 this property would return iOS.

If you're targeting iOS 15 or later you can use this property to detect iPadOS. But if you're targeting iOS 14 or earlier you should use the method described above.

How to switch to Azure kubelogin

Guilherme Oenning — Wed, 21 Dec 2022 17:05:57 +0000

If you're using Azure Kubernetes Service (AKS) you may have already seen this warning:

➜ ~ kubectl get pods
WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.26+; use https://github.com/Azure/kubelogin instead.
To learn more, consult https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins

Or even this one if you're running kubectl v1.26+

➜ ~ kubectl get pods
error: The azure auth plugin has been removed.
Please use the https://github.com/Azure/kubelogin kubectl/client-go credential plugin instead.
See https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins for further details

It's pretty self-explanatory, the azure auth provider was removed after being deprecated for many months, and Azure/kubelogin is the future.

But then you visit https://github.com/Azure/kubelogin expecting an easy to follow guide on how it works and how to switch to kubelogin, but all you see is a wall of text and lots, lots of commands. I don't know about you, but it took me a while to figure out how that works. So I decided to write this post to help you get started. 😊

Back to the basics: What is the Azure Auth Provider?

You can skip this if you want, but it might be good for you to understand how the authentication to AKS works, I'll keep it brief and to the point.

When connecting to AKS for the first time, you most likely executed this command:

az aks get-credentials --resource-group {your-resource-group} --name {your-aks-name}

This command generates a few sections on your ~/.kube/config file, which is used by kubectl to connect to the cluster.

The relevant section looks like this:

users:
  - name: clusterUser_{your-resource-group}_{your-aks-name}
    user:
      auth-provider:
        config:
          apiserver-id: ...
          client-id: ...
          config-mode: '1'
          environment: AzurePublicCloud
          tenant-id: ...
        name: azure

This config is using the aforementioned azure auth provider, which is now deprecated. The logic used by the auth provider is embedded in the kubectl binary, which is why you can authenticate and connect to the cluster without having to install anything else.

Starting from Kubernetes v1.26 (December/2022), this auth provider will be removed from the kubectl binary, so you'll need an alternative method to be able to authenticate to AKS.

If the deprecation wasn't enough reason to switch, can I say that the current developer experience with azure auth provider is very poor as well?

During the authentication phase, you're presented with a UR that gives you a "Device Code", which you then enter into the terminal. This is how the auth provider knows that you're the one trying to connect to the cluster. This process is slow because it's interactive, you need to switch windows, click on buttons and then copy/paste some text.

If you don't like it either, you're in luck, because kubelogin is a thousand times better 🤩.

Downloading kubelogin

The authentication plugins are being moved out of the kubectl binary into separate binaries, maintained by the Cloud providers and distributed independently.

This is why the first step is to download the kubelogin binary. Is this specific to Azure? No, the GCP Auth Provider is also being replaced by the gcloud CLI.

To install kubelogin, follow the official guide and come back here when you're done 😁.

The binary should be on your PATH. You can verify that kubelogin is installed correctly by running which kubelogin on macOS/Linux or where kubelogin on Windows.

Ready to convert?

So here's where things get a bit more complicated and they don't really explain it very well.

To connect to AKS you need a token. The token is generated by the Azure Active Directory (AAD) and is used to make API calls to the Kubernetes API Server. This is what the azure auth provider does for you, it generates the token for you transparently.

There are many (many!) ways to generate a token in Azure and it's beyond the point of this article to cover them all, but you might have heard or used some of them, like:

Service Principal
User Principal Principal
Managed Service Identity
Azure CLI
Azure Workload Federated Identity

kubelogin convert-kubeconfig is the command we'll be using next. It'll modify our kubeconfig and replace the existing azure auth provider with a different authentication method.

Which one? It's your choice.

As a developer, if you're connecting to AKS from your machine, you're most likely to use the az Azure CLI. In fact, you probably already have it installed and configured, because that's what the first command on this article uses.

The Azure CLI can be used to generate tokens using the user's identity, which is great for development. Permissions are managed through Azure RBAC so administrators can control what developers can do on the cluster.

If you choose to use Azure CLI, stick with me. But if prefer another option, find the relevant section on official guide.

To convert your kubectl authentication method to Azure CLI, all you need to do is run:

kubelogin convert-kubeconfig -l azurecli

Shouldn't take more than a second to complete. If you inspect your ~/.kube/config again, you'll see that the azure auth provider has been replaced by kubelogin.

users:
  - name: clusterUser_{your-resource-group}_{your-aks-name}
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        args:
          - get-token
          - --login
          - azurecli
          - --server-id
          - 6dae42f8-4368-4678-94ff-3960e28e3630
        command: kubelogin
        env: null
        provideClusterInfo: false

This is using the new client-go credential plugin feature. The kubelogin binary is now responsible for generating the token, which uses the Azure CLI behind the scenes.

You can now use kubectl as usual, it'll connect to the same clusters it has been before, but with a different authentication flow. You might need to run az login once per day, but at least you won't be prompted for a Device Code anymore! 🎉

Conclusion

It might feel a bit too magical when you're asked to simply run a CLI and things just work. But what did it actually do?

I always try to understand what's going on behind the scenes so I troubleshoot it better when something goes wrong. I hope this article helped you understand what convert-kubeconfig does. As you can see, there is no magic, it's all just text files and some code.

Measuring the performance of a website from multiple locations on a budget

Guilherme Oenning — Sun, 10 Feb 2019 19:38:11 +0000

Global metrics for websites with global visitors

Measuring the performance of a website from multiple locations around the world is crucial with the current global scale of the internet. In most cases, your visitors are not only based in your home country but from all other countries too. From Canada to Australia, from Chile to Russia, your website is being visited by more people than you think.

It's easy to forget this fact and simply measure the performance of a website from the local machine, where it's usually close to the website Data Center. Not only that, but this machine is probably a beast too, it can open multiple tabs of Google Chrome and load any page with an insane amount of JavaScript in half a second.

But in reality, your visitors are using a 10 years old laptop with Windows 7 and are connected to the internet via a 3G network connection. Your Data Center is in San Francisco and these visitors are from The Philippines. Even your smartphone has 10x higher speed and lower latency than theirs.

There are a number of paid services that allow you to constantly monitor your website performance from multiple locations around the world.

But maybe you're a geek and you want to do it yourself?

On this post, I want to show you how to collect website performance from multiple locations using open source tools on a low monthly cost.

webpage-timing

goenning/webpage-timing is Node.js application that uses Headless Chrome to collect performance metrics from a web page.

This application is also available as a Docker image, so you can run it like this:

$ docker run goenning/webpage-timing

Go on, give it a try and execute this on your Terminal.

You should get a response similar to this:

{ "start": "2019-02-10T16:32:25.655Z",
  "start_ts": 1549816345655,
  "duration": 430,
  "origin": "iMac.local",
  "request_url": "https://example.org",
  "metrics":
   { "Timestamp": 300473.456095,
     "Documents": 2,
     "Frames": 1,
     "JSEventListeners": 0,
     "Nodes": 39,
     "LayoutCount": 1,
     "RecalcStyleCount": 2,
     "LayoutDuration": 0.053402,
     "RecalcStyleDuration": 0.000584,
     "ScriptDuration": 0.000015,
     "TaskDuration": 0.068091,
     "JSHeapUsedSize": 2108152,
     "JSHeapTotalSize": 3936256 },
  "entries":
   [ { "name": "https://example.org/",
       "entryType": "navigation",
       "startTime": 0,
       "duration": 427.6149999932386,
       "initiatorType": "navigation",
       "nextHopProtocol": "h2",
       "workerStart": 0,
       "redirectStart": 0,
       "redirectEnd": 0,
       "fetchStart": 0.2899999963119626,
       "domainLookupStart": 7.634999987203628,
       "domainLookupEnd": 8.984999964013696,
       "connectStart": 8.984999964013696,
       "connectEnd": 313.34999995306134,
       "secureConnectionStart": 0,
       "requestStart": 313.6149999918416,
       "responseStart": 414.7049999446608,
       "responseEnd": 415.8099999767728,
       "transferSize": 800,
       "encodedBodySize": 606,
       "decodedBodySize": 1270,
       "serverTiming": [],
       "unloadEventStart": 0,
       "unloadEventEnd": 0,
       "domInteractive": 426.6899999929592,
       "domContentLoadedEventStart": 426.7049999907613,
       "domContentLoadedEventEnd": 426.7049999907613,
       "domComplete": 427.6049999753013,
       "loadEventStart": 427.6149999932386,
       "loadEventEnd": 427.6149999932386,
       "type": "navigate",
       "redirectCount": 0 },
     { "name": "first-paint",
       "entryType": "paint",
       "startTime": 491.65999999968335,
       "duration": 0 },
     { "name": "first-contentful-paint",
       "entryType": "paint",
       "startTime": 491.68499995721504,
       "duration": 0 } ] }

This is a Timing object, it contains some information collected from the Headless Chrome that executed inside the container. In the example above, it took 430ms to load https://example.org. If this page had any CSS/JavaScript/Image files, it'd also download it and the duration would have been higher.

You can also specify some custom arguments, which allows you to collect metrics from any page.

$ docker run -e REQUEST_URL=https://github.com/docker goenning/webpage-timing

You'll also notice that the entries array has many more items now, which includes all the CSS/JavaScript/Image files the browser had to download.

Another useful parameter is MONGO_URL, which allows you to store the Timing object into a MongoDB collection instead of printing it to stdout. It is useful when you want to keep a history of execution over time and perform further analysis.

# Replace the connection string below with your own
$ docker run -e MONGO_URL=mongodb://user:pass@your-server:port/db -e REQUEST_URL=https://github.com/docker goenning/webpage-timing

Running it on a global infrastructure

We've seen so far that we can collect metrics from a web page using a local Docker container and store it in MongoDB.

To go one step further we'll use machines on the Cloud to run this container from multiple regions. You could spin up multiple Virtual Machines on the cloud provider of your preference and schedule this script on cron. But that's not very cost effective and you'd have to carry the burden of maintaining dozens of virtual machines.

But there's a better way 😀

Azure has a service called Azure Container Instances. It allows you to run a Docker container on the cloud without having to worry about the infrastructure behind it. The best of all? You only pay per execution time. If you start a container that runs for 5 seconds, you'll pay $0.000080. On this post, I'll show you how to perform this operation on Azure, but If prefer AWS, search for AWS Fargate, it's a similar service, so you apply the same idea presented here.

What we're going to do is create dozens of Azure Container Instance on each of its 17 regions and configure it to execute goenning/webpage-timing with our custom parameters. We'll also need to store the data from all locations to query it later. In this example, I'll be using MongoDB Atlas because it has a free tier and can also be hosted on Azure.

Assuming that you have an Azure Account and the Azure CLI is installed, run the following commands.

$ az login
$ az account set --subscription "<YOUR_SUBSCRIPTION NAME>" # you can skip this if your account has only one subscription

Create a file template.yaml with this content:

apiVersion: 2018-06-01
type: Microsoft.ContainerInstance/containerGroups
location: $location$
name: $name$
properties:
  containers:
  - name: $name$-01
    properties:
      image: goenning/webpage-timing
      environmentVariables:
        - name: 'ORIGIN'
          value: '$location$'
        - name: 'REQUEST_URL'
          value: '$request_url$'
        - name: 'MONGO_URL'
          secureValue: '$mongo_url$'
      resources:
        requests:
          cpu: 0.4
          memoryInGb: 0.7
  - name: $name$-02
    properties:
      image: goenning/webpage-timing
      environmentVariables:
        - name: 'ORIGIN'
          value: '$location$'
        - name: 'REQUEST_URL'
          value: '$request_url$'
        - name: 'MONGO_URL'
          secureValue: '$mongo_url$'
      resources:
        requests:
          cpu: 0.4
          memoryInGb: 0.7
  - name: $name$-03
    properties:
      image: goenning/webpage-timing
      environmentVariables:
        - name: 'ORIGIN'
          value: '$location$'
        - name: 'REQUEST_URL'
          value: '$request_url$'
        - name: 'MONGO_URL'
          secureValue: '$mongo_url$'
      resources:
        requests:
          cpu: 0.4
          memoryInGb: 0.7
  - name: $name$-04
    properties:
      image: goenning/webpage-timing
      environmentVariables:
        - name: 'ORIGIN'
          value: '$location$'
        - name: 'REQUEST_URL'
          value: '$request_url$'
        - name: 'MONGO_URL'
          secureValue: '$mongo_url$'
      resources:
        requests:
          cpu: 0.4
          memoryInGb: 0.7
  - name: $name$-05
    properties:
      image: goenning/webpage-timing
      environmentVariables:
        - name: 'ORIGIN'
          value: '$location$'
        - name: 'REQUEST_URL'
          value: '$request_url$'
        - name: 'MONGO_URL'
          secureValue: '$mongo_url$'
      resources:
        requests:
          cpu: 0.4
          memoryInGb: 0.7
  osType: Linux
  restartPolicy: OnFailure

This template will be loaded into Azure Container Service and it'll create 5 containers using the same image and parameters. It's also been configured to use up to 0.4 of the CPU and only 700MB of Memory.

Create another file aci.sh with the following content:

# The name of the resource group to be used on Azure
resource_group="webtiming-rg"

# The list of locations from where the test will be executed
locations=( "westus" "eastus" "westeurope" "westus2" "northeurope" "southeastasia" "eastus2" "centralus" "australiaeast" "uksouth" "southcentralus" "centralindia" "southindia" "northcentralus" "eastasia" "canadacentral" "japaneast" )

# The URL of the webpage we want to test
request_url="https://github.com/docker"

# The connection string to a MongoDB instance
mongo_url="mongodb+srv://webtiming:webtiming@cluster0-s5g8l.azure.mongodb.net/webtiming?retryWrites=true"

if [ $1 == "init" ]
then
  az group create --name $resource_group --location eastus
fi

if [ $1 == "run" ]
then
  rm -rf ./out
  mkdir ./out
  for loc in "${locations[@]}"
  do
    cat ./template.yaml | 
    sed 's|\$name\$|'$loc'-wt|' | 
    sed 's|\$request_url\$|'$request_url'|' | 
    sed 's|\$location\$|'$loc'|' | 
    sed 's|\$mongo_url\$|'$mongo_url'|' | 
    sed 's|\$location\$|'$loc'|' > "./out/$loc-wt.yaml"

    status=$(az container show -n $loc-wt --resource-group $resource_group --query containers[0].instanceView.currentState.state 2>/dev/null)
    if [ $? -eq 0 ]
    then
      az container start -g $resource_group --name "$loc-wt" &
      echo "$loc-wt has started..."
    else
      az container create -g $resource_group --location $loc --file "./out/$loc-wt.yaml" --no-wait
      echo "$loc-wt has been created..."
    fi
  done
fi

if [ $1 == "clean" ]
then
  az group delete --name $resource_group --yes
fi

The first lines are the parameters, configured it based on given comments and execute:

$ ./aci.sh init

This first step will simply create a Resource Group based on the configured name. You can skip this step if you prefer to do it manually through Azure Portal.

$ ./aci.sh run

This is the most important part of the script. It'll basically loop through each configured location and create a YAML file based on template.yaml.

By the end of the execution, you should have something similar to this on your Azure Portal.

Notice that there are 17 container groups (1 per region) with 5 containers on each. Some of them have already finished processing, while others are still in progress. This process can take a few extra seconds as Azure needs to pull the images from Docker Hub Registry first.

A few seconds later all groups should be on "Succeeded" state. By the end of this process, these instances will remain on Azure until you remove it. You can do so by executing ./aci.sh clean, which removes the Resource Group and all of its container instances.

But if you plan to periodically execute this, you can keep the resources on Azure and simply execute ./aci.sh run again. The script is smart enough to restart the container if it already exists on Azure. You can repeat this process as many times as you want.

The results

We should now have a few documents on our MongoDB database, so we can now look at the data and perform some analysis. We could hook up any BI tool to this MongoDB instance, extract the data and plot some charts.

But there is also MongoDB Charts, which is a data visualization tool to create visual representations of our MongoDB Data. At the time of this writing, this service is on beta and free to use, so I decided to give it a try. This is what I got from my execution.

As we can see, we have collected 595 timings and the global average is 4165ms. The chart shows that loading https://github.com/docker on Asian is 2seconds slower when compared to US.

You could go one step further and actually analyze the entries array to find out which HTTP resources took longer to load.

Where to go from here?

If you liked this and want to take it to the next level, here are some ideas:

Schedule this script to execute every X hours
Reduce the Docker Image size. The smaller the image is, the faster it'll be executed on the Cloud, which means less 💸
Fork the project and enhance it with extra timing information you need
Use puppeteer to emulate a slower network and CPU
Change the script to be a multi-step process. If you have an e-commerce and you want to measure how long does it take for a user to find a product and buy it. You can use this script as a starting point and include the extra steps of this process
Go wild and deploy hundreds of containers per region 😁, just keep in mind that it'll also increase your 💸

That's all! 🎉

What do you think about this? Please leave a comment if you any suggestion or feedback.

How we reduced our initial JS/CSS size by 67%

Guilherme Oenning — Mon, 26 Nov 2018 16:52:39 +0000

We have been working on reducing the amount of bytes that we send to all Fider users. Being a web application built with React, we have focused on JS and CSS. On this post we share our learnings, some concepts and suggestions on how you can do the same with your web application.

Fider is built with React and Webpack on the frontend, so the topics below will be mostly useful for teams using same stack, but the concepts can also be applied to other stacks. It is also an open source, so you can actually see the Pull Requests and the source code: https://github.com/getfider/fider

Webpack Bundle Analyzer
Long term caching with content hash
The common bundle
Code Splitting on route level
Loading external dependencies on demand
Font Awesome and Tree Shaking
Switching from big to small NPM packages
Optimising the main bundle is crucial
TSLib (TypeScript only)

Webpack Bundle Analyzer

webpack-bundle-analyzer is a webpack plugin that generates an interactive zoomable treemap of all your bundles. This has been crucial for us to understand which modules are inside each bundle. You can also see which are the biggest modules within each bundle.

If you don’t know the root cause, how can you tackle it?

This is an example of what this plugin will generate for you.

Did you notice that huge entities.json inside the vendor bundle? That's a good starting point to analyze the content of your bundle.

Long term caching with content hash

Long term caching is the process of telling the browser to cache a file for a long time, like 3 months or even 1 year. This is a important settings to ensure that returning users won’t need to download the same JS/CSS files over and over again.

The browser will cache files based on its full path name, so if you need to force the user to download a new version of your bundle, you need to rename it. Luckly webpack provides a feature to generate the bundles with a dynamic name, hence forcing the browser to download new files only.

We have previously used chunkhash for a long time on our webpack configuration. 99% of the cases where you want long term cache, the best option is to use contenthash, which will generate a hash based on its content.

This technique does not reduce the bundle size, but it certainly helps to reduce the amount of times the user has to download our bundles. If the bundle didn’t change, don’t force the user to download it again.

To learn more, visit the official documentation https://webpack.js.org/guides/caching/

The common bundle

Combining all the NPM packages into a separate bundle has been a long time practice for many teams. This is very useful when combined with long term caching.

NPM packages change less often than our app code, so we don’t need to force users to download all your NPM packages if nothing has changed. This is usually called the vendor bundle.

But we can take this practice one step further.

What about your own code that also change less often? Maybe you have a few basic components like Button, Grid, Toggle, etc. that have been created some time ago and haven't changed in a while.

This is a good candidate for a common bundle. You can check this PR #636 where we basically move all our own modules inside some specific folders into a common bundle.

This will ensure that, unless we change our base components, the user won’t need to redownload it.

Code Splitting on route level

Code splitting is currently a hot topic. This has been around for some time, but the tools and frameworks have evolved a lot, to the point where doing code splitting is much simpler now.

It’s very common to have applications that push one big bundle that contains all the JS/CSS required to render any page within the application, even if the user is only looking at the Home page. We don’t know if the user will ever visit the Site Settings page, but we have pushed all the code for that already. Fider has been doing this for a long time and we now have changed it.

The idea of Code Splitting is to generate multiple smaller bundles, usually one per route, and a main bundle. The only bundle we send to all the users is the main bundle, which will then asynchronously download all the required bundles to render the current page.

It seems complicated, but thanks to React and Webpack, this is not rocket science anymore. For those using React <= 16.5, we recommend react-loadable. If you’re already on React 16.6, then you can use React.lazy() which has been a new addition to this version.

In this PR you can find how @cfilby (thank you!) added code splitting to Fider with react-loadable: PR #596
After we migrated to React 16.6, we have then replaced this external package with React.lazy and Suspense: PR #646

We also had issues with some rare events where users were having issues to download asynchronous bundles. A potential solution has been documented on How to retry when React lazy fails.

Edit 4th Dec: You might also consider using loadable as per Anton's comment.

Loading external dependencies on demand

By using the Webpack Bundle Analyzer we noticed that our vendor bundle had all the content of react-toastify, which is the toaster library that we use. That is usually ok, except that 95% of the Fider users will never see a toaster message. There are very few places we show a toaster, so why do we push 30kB of JavaScript to every user if they don’t need it?

This is a similar problem to the one above, except that we are not talking about routes anymore, this is a feature used in multiple routes. Can you code split on a feature level?

Yes, you can!

In a nutshell, what you have to do is switch from static import to dynamic import.

// before
import { toast } from "./toastify";
toast("Hello World");

// after
import("./toastify").then(module => {
  module.toast("Hello World");
});

Webpack will bundle the toastify module and all its NPM dependencies separately. The browser will then only download that bundle when the toast is needed. If you have configured long term caching, then on the second toaster call it won’t have to download it again.

The video below shows how it looks like on the browser.

You can see the details on how this was implemented on PR #645

Font Awesome and Tree Shaking

Tree Shaking is the process of importing only what you need from a module and discarding the rest. This is enabled by default when running webpack on production mode.

The usual approach to use Font Awesome is to import an external font file and a CSS that maps each character (icon) on that font to one CSS class. The result is that even though we only use icon A, B and C, we are forcing the browsers to download this external font and a CSS definition of 600+ icons.

Thankfully we found react-icons, a NPM package with all free Font Awesome (and other icon packages too!) in a SVG format and exported as React Components on a ES Module format.

You can then import only the icons you need and webpack will remove all other icons from the bundle. The result? Our CSS has is now ~68kB smaller. Not to mention that we don’t need to download external fonts anymore. This change was the biggest contributor on reducing the CSS size on Fider.

Want see how? Check out this PR #631

Switching from big to small NPM packages

"NPM is like a lego store full of building blocks that you can just pick whichever one you like. You don’t pay for the package you install, but your users pay for the byte size that it adds to your application. Choose wisely." - @goenning

While using the Bundle Analyzer we found that markdown-it alone was consuming ~40% of our vendor bundle. We have then decided to go shopping on NPM and look for an alternative markdown parser. The goal was to find a package that was smaller, well maintained and had all the features we needed.

We’ve been using bundlephobia.com to analyse the byte size of any NPM package before installing it. We have switched from markdown-it to marked, which reduced ~63kB from our vendor bundle with minimal API change.

Curious about it? Check out PR #643.

You can also compare these two packages on bundlephobia:

Think twice before adding a large package. Do you really need it? Can your team implement a simpler alternative? If not, can you find another package that does the same job with less bytes? Ultimately, you can still add the NPM package and load it asynchronously like we did with react-toastify mentioned above.

Optimising the main bundle is crucial

Imagine that you have an application doing code splitting by route. It’s already running in production and you commit a change to your Dashboard route component. You might think that Webpack will only generate a different file for the bundle that contain the Dashboard route, correct?

Well, that’s not what actually happens.

Webpack will ALWAYS regenerate the main bundle if something else changes in your application. The reason being that the main bundle is a pointer to all other bundles. If the hash of another bundle has changed, the main bundle has to change its content so that it now points to the new hash of the Dashboard bundle. Makes sense?

So if your main bundle contains not only the pointers, but also a lot of common components like Buttons, Toggle, Grids and Tabs, you’re basically forcing the browser to redownload something that has not changed.

Use the webpack bundle analyzer to understand what’s inside your main bundle. You can then apply some of the techniques we’ve mentioned above to reduce the main bundle size.

TSLib (TypeScript only)

When compiling TypeScript code to ES5, the TypeScript Compiler will also emit some helper functions to the output JavaScript file. This process ensures that the code we wrote in TypeScript is compatible with older browsers that doesn’t support ES6 features like Classes and Generators.

These helper functions are very small, but when there are many TypeScript files, these helper functions will be present on every file that uses a non-ES5 code. Webpack won’t be able to tree shake it and the final bundle will contain multiple occurrences of the very same code. The result? A slightly bigger bundle.

Thankfully there’s a solution for this. There is a NPM package called tslib that contains all the helper functions needed by TypeScript. We can then tell the compiler to import the helper functions from the tslib package instead of emitting it to the output JavaScript file. This is done by setting importHelpers: true on the tsconfig.json file. Don’t forget to install tslib with npm install tslib —save.

That’s all!

The amount of bytes this can reduce from the bundle will depend on the amount of non-ES5 files, which can be a lot on a React app if most of the Components are classes.

The next billions users

Are you ready for the next billion users? Think about all the potential users of your app that currently struggle to use it on a low-cost device and slower network.

Reducing the byte size of our bundles has a direct impact on the performance of our applications and can help us make it more accessible to everyone. Hopefully this post can you help on this journey.

Thank you for reading!

How to retry when React lazy fails

Guilherme Oenning — Mon, 19 Nov 2018 17:09:09 +0000

React 16.6 has been released and it's now easier than ever to do code split within our React applications by using lazy and Suspense.

If you don't know what I'm talking about, you should definitely read this https://reactjs.org/blog/2018/10/23/react-v-16-6.html

After a few days monitoring a production application that is using lazy, I noticed some client-side errors like this:

Loading chunk 6 failed. (error: https://.../6.4e464a072cc0e5e27a07.js)
Loading CSS chunk 6 failed. (https://.../6.38a8cd5e9daba617fb66.css)

Why?!

I don't actually know why, but I can only assume this is related to the user network. Maybe they are on a slow 3G and there was a network hiccup? That's not a rare event, right?

Alright, if that's true, how do we solve that?

We can do the same thing that everyone does when a network request fails: retry it! 😄

How?

Did you know that the import(...) function that we use on lazy is just a function that returns a Promise? Which basically means that you can chain it just like any other Promise.

Below you can find a basic implementation of a retry function.

function retry(fn, retriesLeft = 5, interval = 1000) {
  return new Promise((resolve, reject) => {
    fn()
      .then(resolve)
      .catch((error) => {
        setTimeout(() => {
          if (retriesLeft === 1) {
            // reject('maximum retries exceeded');
            reject(error);
            return;
          }

          // Passing on "reject" is the important part
          retry(fn, retriesLeft - 1, interval).then(resolve, reject);
        }, interval);
      });
  });
}

Source: https://gist.github.com/briancavalier/842626

Now we just need to apply it to our lazy import.

// Code split without retry login
const ProductList = lazy(() => import("./path/to/productlist"));

// Code split with retry login
const ProductList = lazy(() => retry(() => import("./path/to/productlist")));

If the browser fails to download the module, it'll try again 5 times with a 1 second delay between each attempt. If even after 5 tries it import it, then an error is thrown.

That's all! 🎉

Thanks!

DEV Community: Guilherme Oenning

🔥 Why I chose Tauri instead of Electron 🔥

TL;DR

How it all started...

What about Electron?

Okay, let's get started!

Can I just npx create electron-app?

So what now?

Getting started (again 😅), but with Tauri

So how does Tauri compare to Electron?

1. Programming Language and Ecosystem

2. Webview

3. Plugins

4. Feature Parity

5. Mobile

Conclusion

Complete Guide to Kubeconfig and Kubernetes Contexts

What the heck is Kubeconfig anyway?

Let's take a look at a Kubeconfig file

Using the Kubeconfig file with kubectl

Authentication and Security

Connecting to multiple clusters simultaneously

How to detect iPadOS with Swift

What about the UIDevice.current.systemName?

How to switch to Azure kubelogin

Back to the basics: What is the Azure Auth Provider?

Downloading kubelogin

Ready to convert?

Conclusion

Measuring the performance of a website from multiple locations on a budget

Global metrics for websites with global visitors

webpage-timing

Running it on a global infrastructure

The results

Where to go from here?

That's all! 🎉

How we reduced our initial JS/CSS size by 67%

Table of Contents

Webpack Bundle Analyzer

Long term caching with content hash

The common bundle

Code Splitting on route level

Loading external dependencies on demand

Font Awesome and Tree Shaking

Switching from big to small NPM packages

Optimising the main bundle is crucial

TSLib (TypeScript only)

The next billions users

How to retry when React lazy fails

Can I just `npx create electron-app`?

What about the `UIDevice.current.systemName`?