Peter Mekhaeil

3 benefits interviews bring you

Tue, 14 Jun 2022 00:00:00 GMT

Not only do interviews open doors to new opportunities, they also help you sharpen your skills with new learnings. Interviews keep your career moving forward and I will share some learnings from experience.

Learn about what you know

When you answer questions during the interview, be aware to what level you understand the topics being discussed. Speaking out loud about what you know helps you articulate those past career learnings and experiences. With each interview, the more you can improve your confidence in talking about what you know.

Learn about what you do not know yet

You may not have an answer to some questions during the interview and that is totally fine - this will be an opportunity to learn something new! Ask the interviewer for the answers to those questions. Now whether or not you decide to continue with the interview rounds, you have now learnt something new that you can take to your existing job or you take to your next interview. With each interview, you are building up your knowledge base.

Learn to negotiate

When you get to the offer stage of the interviews, you have the opportunity to practice negotiation, a very handy skill to have at any level in your career. With each interview, sharpen your negotiation skills and pick up experience in handling those situations.

A great book on this topic is The Coding Career Handbook - a chapter is dedicated to salary negotiation where you’ll learn that you have an upper hand simply because the best alternative is staying at the job you already have.

Each experience will be unique

Each person will have their own learning experience. With each interview, practice a useful skill for your career, such as building your confidence, expanding your knowledge and salary negotiating.

Accelerate your delivery with modern tools

Tue, 27 Dec 2022 00:00:00 GMT

By using modern tools in the development of large front-end repositories, we can potentially improve the speed of deliverables. This will benefit both the business and the development team. The business will benefit from a faster time to market, and the development team will be more motivated as a faster pipeline reduces the need for context switching. I'll share 3 development tools that will lead to faster delivery of your development.

Use a fast package manager

A fast package manager will improve developer productivity by reducing the time it takes to install packages and manage dependencies. This will lead to reducing build times and faster feature delivery.

pnpm is described as a fast, disk space-efficient package manager. It focuses on saving disk space while boosting installation speed.

pnpm is performant because it uses a content-addressable store that contains each version of each dependency and pnpm will hard link the project's node_modules to that store. This means that pnpm only stores one copy of each package in the store, regardless of how many projects are using it. This strategy will save disk space and improve the speed of installing and managing packages.

I've seen this result in projects speeding up their installations by 75%. The team behind pnpm have also posted benchmarks on how pnpm compares to other package managers in terms of installation speed.

Migrate to a fast development tool

A fast development tool can reduce the time it takes to build and deploy. This can be particularly important for large applications that is frequently deployed.

Vite is a modern JavaScript development tool that focuses on providing a fast and efficient development experience. It uses a new approach to building and serving web applications using native browser capabilities to load modules on demand, providing a faster and more efficient development experience.

One of the advantages Vite provides is how incredibly fast it is at building. Vite uses rollup for bundling and esbuild for transforming. Esbuild is written in Go and is 10-100x faster than the JavaScript-based alternatives.

Vite includes Library Mode that allows you to bundle libraries that do not have an HTML entry. Not only can you use Vite to build your applications, you can also take advantage of the power of Vite for packages that are consumed by those applications.

Swapping out a create-react-app (CRA) app to Vite is a matter of replacing the npm scripts and reconfiguring vite.config.js to match your needs. I've seen real world CRA apps migrate to Vite and have improved their build times by 50%.

Use a build system

Build systems like Turborepo and Nx can cache the results of tasks to speed up the build process in subsequent builds.

Each task in a CI pipeline has inputs and outputs - for example, a build task may have source code as inputs and bundled files as outputs. When a task is run, the build system generates a hash based on the inputs and stores the output under that hash. If the task is run again and the inputs have not changed, the build system can reuse the saved output stored under the same hash, rather than running the task again.

This can be especially helpful for large projects with many tasks, as it reduces the overhead of running tasks that have not changed, and can significantly reduce CI time.

AI Native Documentation

Tue, 30 Dec 2025 00:00:00 GMT

Most documentation traffic now comes from AI crawlers and agents read docs more than humans do. Here's how teams are adapting.

Render Markdown for Agents

Agents send Accept: text/markdown in the request header when fetching pages. Servers can detect this and return markdown instead of HTML. Less tokens, cleaner content.

Bun and @thdxr shared this pattern.

AI Prompts

Docs now include AI prompts you can paste directly into your agent to handle setup.

Examples:

Ask AI

Docs sites embed AI chat as a sidebar or popup. Many are powered by Kapa.

Examples:

Copy Page as Markdown

Make it one click to copy documentation as markdown.

Cursor and Vercel do this with a "Copy page" link in the sidebar.

Markdown URL Support

Support viewing pages as Markdown by adding .md to the end of the URL. nuqs does this and includes a "Copy Markdown URL" button along with "Open in..." options to open the markdown URL directly in ChatGPT or Claude.

llms.txt

Put a llms.txt in the root. Some sites include links to key docs, others include the full content in markdown format.

Examples:

Some sites provide both llms.txt and llms-full.txt files.

MCP Servers

Projects run their own MCP servers for documentation, like Astro Docs MCP Server. Context7 works across documentation for many tools and libraries.

Be strong like your code

Sat, 21 Nov 2020 00:00:00 GMT

We spend our days building scalable and performant applications, so why are we not doing the same to our mind and body? Staying fit and active is important to our well-being and I'd like to remind us to take care of ourselves while we code away.

Daily Maintenance

H20 yourself

Water is your body's battery to keep you going throughout day. I remind myself to drink water by keeping the water bottle near my monitor. Keep it in view so you take regular sips while working.

Get yourself 2L of water a day.

Take breaks

We get reminded of this so often but we ignore it because we tend to be in the "zone". Take your breaks. It will help you stay focus in the long run.

Don't spend more than 15min on a problem. Take a break, leave it for the next day, or ask someone to help. If you have spend more than that on a problem, chances are you have gone down the wrong path. We have all been there - we spend hours on a problem, and after sleeping it off, we find a solution first thing in the morning because we started over.

Take the stairs

Aim for 10 sets of stairs a day. This will also help achieve the recommended 10,000 steps a day. I know this is easier said than done. Start with one set, build a habit. You'll start doing 10 naturally without too much thought.

Stand while working

Prolonged hours sitting down has a hugh impact on your posture and health. Get yourself a standing desk, or ask your office to supply one for you. Stand up while taking a call. Even yet, go for a walk while talking. Not only will it help you with your health, it will help shorten the duration of the call.

Cut out the snacks

Very common I see engineering desks packed with towers of snacks and sugars (I'm so guilty of supplying these snacks!) to keep engineers going for long hours. I've learnt to avoid this at all costs. Replace with fruits or nuts. The sugar hit is only temporary and fil the stomach for a short time, but it has a long term effect on your health that is not worth it.

Avoid desk lunches

Lunch is your break away from work, take advantage of it. Go for a walk, stretch your legs and have lunch outside. Get some sunlight and walk off your meal afterwards. Otherwise you'll get distracted and get back to work, or even be interrupted by a colleague.

Working Out

Get your blood flowing

Cannot stress this one enough. I've picked up many injuries because of my laziness to warm up before a work out. While at work, 3pm would hit and I would close my laptop. I then rush to the office gym, change into my active wear and get straight on the treadmill without warming up. You can imagine what happened next. Because we have been sitting down for long hours coding, our muscles are not prepared for the surprise they face when we rush to the gym. This is where stretching is important and I talk about it later below.

Create a workout schedule

It not too important how much you workout, as long as you are consistent with your schedule. Book your week in advance and block out your calendar so you are not interrupted by work activities. Add some buffer for warming up and stretching. I suggest having a training program that you can follow.

(Recommendation: Team Grit OCR have a 4-week home workout suitable for all fitness levels. Does not require equipment and can be done at home.)

Join a Club

Think of it as pair programming. Find other like-minded engineers who want to join the fun and stay active together by joining a club. For your colleagues, you can start a private group chat to share your schedules or tips. It's easier to start an activity with others. And it goes two ways - let them know you're willing to keep them company in the gym.

Connect with them on Strava to track and stay in touch with each other.

Strava turns every iPhone and Android into a sophisticated running and cycling computer (and we work with your GPS watches and head units, too). Start Strava before an activity and you can track your favorite performance stats, and afterwards, dive deep into your data. - Strava.com

(Connect with me on Strava - I would love to virtually run with other engineers!)

Measure your activities

Like we execute performance tests against our applications, we should also be measuring our physical activities and use the results as benchmarks. Track your activities in your favourite notes editor, or use an app to automatically track the activities for you. I personally use Notes on my iPhone + Garmin Connect.

Stretching

Prior to knowing the importance of stretching, I would spend a lot of long hours on my desk coding away and over time, picked up poor posture which led to a few nasty injuries in my shoulders and hips.

Common scenarios I see engineers (and myself!) faced without awareness:

Hunched Shoulders - Because the desk and chair are not aligned, so the shoulders become tensed for a long period of time while typing at the wrong height.
Tensed Hips Caused by long hours sitting down, the hips don't get any movement. Over time, the muscles tighten up and will cause injury when you need to participate in an activity.

Some stretches I have picked over time to help with common tightness from an extended period of sitting down in front of a computer:

Child's Pose to release tensions on your back.
External Shoulder Rotations to stretch out your shoulders.
Place a tennis ball under your hamstrings while sitting down to help release tightness while working.

Without going into too much detail on how to stretch - My message here is to bring awareness of the importance of stretching for anyone who is sitting down for a prolonged period of time.

(Recommendation: Living in Singapore? Visit The Stretch Clinic. I regularly visit them for a good stretch and they have been very helpful with taking care of my body from any injuries I have faced from long hours at work or while working out.)

Building a Today I Learned Habit

Sat, 28 Dec 2024 00:00:00 GMT

One of the best habits I've picked up is maintaining a "Today I Learned" (TIL) list. What started as a casual way to jot down things I didn't want to forget has grown into a useful way to track what I'm learning.

Why TIL?

It all started with the realization that I was learning something new every day, but often these lessons would fade as quickly as they came. Whether it was solving a coding problem, uncovering a technical insight during a discussion, or learning from a mistake, I wanted a way to capture these moments.

So, I began documenting them. Over time, this habit evolved into my TIL list, a structured way to track and reflect on my growth.

Inspired by "Learn in Public"

The idea of TIL is closely tied to the concept of Learn in Public popularized by Shawn Wang (aka Swyx). The principle is simple: share your learning journey openly so others can benefit from your experiences. This approach not only reinforces your own understanding but also invites collaboration and feedback from the community.

By embracing "Learn in Public", my TIL list became more than just a personal tool. It turned into a way to give back, spark discussions, and connect with others who share similar interests.

Turning a Habit into a System

Consistency is key to making any habit stick. To ensure I didn't lose momentum, I built a system around TIL:

Daily Capture: Each day, I aim to record at least one key takeaway. It could come from debugging, reading, or collaborating with others.
Automating Reminders: I set up tools like calendar alerts to remind me to add new entries. These small nudges keep me on track.
Periodic Reflection: Regular reviews of my TIL entries help me reinforce past learnings and spot areas for deeper exploration.

This structured approach has kept the practice alive and valuable.

Broadening the Scope

While my TILs are currently focused on technical insights, the beauty of this habit is its flexibility. It doesn't have to be limited to coding or development topics. You can capture learnings from any area like leadership lessons, communication strategies, process improvements, or even personal hobbies. The key is to document anything that adds value to your growth and understanding.

If you're starting a TIL list, think broadly. Reflect on all aspects of your day-to-day experiences. Did you learn something new about managing a team? Did a conversation provide a fresh perspective? These moments are just as valuable as technical insights and deserve a place in your list.

How I organize mine

As your TIL list grows, having a structure can make it more useful. Here's an example of a format you might use:

Date	Title	Category
2023-01-20	Deep clone object with structuredClone()	JavaScript
2023-01-31	Spaces vs tabs: It's an accessibility issue	Accessibility
2023-02-28	Git: Work with multiple accounts	Git

This format can help you quickly search and revisit specific learnings. You could also add categories like "Technical", "Leadership" or "Communication" to make your list even more navigable.

Sharing and Collaborating

One of the most unexpected benefits of TIL has been its impact on collaboration. Sharing my TILs, whether in team meetings, blog posts, or discussions, has:

Sparked conversations and new ideas.
Helped others solve similar problems.
Encouraged teammates to start their own TIL lists.

By "Learning in Public", I've seen how sharing knowledge can amplify its value.

Why You Should Start a TIL List

Whether you're a beginner or a seasoned expert, starting a TIL list can transform your approach to learning. Here's why:

Build Confidence: Seeing your list grow over time is a great reminder of how much you've learned.
Give Back: Sharing your learnings online might help someone else solve a problem they're facing.
Stay Curious: TILs make you more attuned to new opportunities to learn.

If you're new to the idea, start small. You don't need to publish your list right away. Even a private journal can work wonders. But if you're comfortable, take the plunge and share your learnings with the world. You might be surprised at the connections and conversations that follow.

What did you learn today? Share it with me on Twitter.

Building my personal AI Assistant

Thu, 18 Jun 2026 00:00:00 GMT

I built an AI assistant that runs on my homelab. I named her Tatl, after the fairy from Majora's Mask.

In May I attended AI Engineer Singapore, Singapore Foreign minister Vivian Balakrishnan gave a keynote about his personal AI setup, a self-hosted assistant running on a Raspberry Pi. It was his second brain. He shared the setup in a public gist.

It clicked so I had to build my own.

What Tatl Can Do

Tatl connects to the services I use daily:

Gmail - summarises yesterday's emails every morning
Google Calendar - briefs me on today's agenda each morning
Garmin + Strava + Oura - pull my fitness data and training plans on demand
Home Assistant - check cameras
Homelab - monitors services like Uptime Kuma and Grafana, sends alerts when something is down
Voice notes - send a voice message and she transcribes it locally via whisper.cpp

The morning briefing means I can mute most of my notifications during the day.

Every message is processed with persistent memory. She builds up a knowledge graph over time and recalls relevant context before responding.

Visualising the Wiki

The memory graph synthesises into markdown pages that Tatl writes and maintains. To browse them I use Quartz - a static site generator that turns markdown into an Obsidian-style website with graph view. Self-hosted privately.

The Stack

Built on NanoClaw.

Runs on the Mac Mini and handles message routing
Each conversation spins up an isolated Docker container running Claude
Credentials are managed through a local vault - containers never see API keys
Memory is stored in a local knowledge graph via mnemon
Voice notes transcribed locally via whisper.cpp
Wiki is visualised using Quartz

What I learned

I tried local models first - Qwen, Mistral, Gemma. At the time, they weren't reliable enough for tool use. The ecosystem is moving fast though and I will revisit this.

The memory layer is what makes it feel different. Without it, it's just a chatbot with integrations.

Get your own

NanoClaw is open source and runs on anything from a Raspberry Pi to a Mac Mini.

Get a Claude API key
Start with Telegram as the main messaging channel.

Then explore from there, you'll find yourself adding more of your day-to-day to it naturally.

The hardest part was finding a name for the agent.

Page Speed Performance of Formula 1 Websites

Tue, 15 Dec 2020 00:00:00 GMT

F1 2020 is over - Mercedes took 1st and 2nd position, with Red Bull right behind them in 3rd. But which team won in terms of web speed performance?

How Scores are Measured

PageSpeed Insights is a tool that reports on site performance and it includes both lab data and real-world field data.

Lab Data is collected by running Lighthouse and is measured under controlled conditions - simulating a single device with fixed network conditions. Field Data is collected from Chrome User Experience Report (CrUX) and it is capturing real-world user experience - these are from real page views over a set period of time.

I have aggregated the results and built a site to show us a summary: F1 Page Speed Insights.

We will start with the score everyone wants to see first:

Performance Score

At the time of this post, Haas takes the lead with a score of 64. This score is a weighted average of a collection of performance metrics measured in Lighthouse:

First Contentful Paint (FCP) - time at which first content appears.
Speed Index - how quickly content visibly populates.
Largest Contentful Paint (LCP) - time at which largest content appears.
Time to Interactive - time at which page becomes interactive.
Total Blocking Time - time from FCP to Time to Interactive.
Cumulative Layout Shift (CLS) - the movement of elements within the viewport.

Important to note here that these Lighthouse scores are based on Lab Data.

A score of 90 or above is considered good. So these teams have some work to do on their season breaks.

Field Data Scores

The list is ordered according to their Performance Scores. We can see Racing Point takes the lead for Cumulative Layout Shift and Williams for Largest Contentful Paint.

You will notice 3 of the Field Data metrics are used in the Performance Scores. The 4th one being First Input Delay (FID). Each of these metrics have their own scoring.

Team Breakdown

Racing Point

The big number is the performance score we spoke about earlier. Right under it is the Core Web Vitals assessment summary.

Core Web Vitals are a common set of signals critical to all web experiences, measuring the quality of a site's user experience. A site either passes, or does not pass the assessment. 3 metrics are used to measure a website's Core Web Vital assessment: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) and First Input Delay (FID).

To pass the assessment, 75% of page views need to hit the recommended target of each metric for it to be considered good performance. When the 3 metrics hit that target, the site passes the assessment. Take a read on how Google defines the metrics thresholds.

In the example above, Racing Point passed. And it can be seen in more details on the right hand side. These are the Field Data scores we saw earlier, but broken down to indicate the percentage of viewers and their experience. For example, for CLS - 79% of viewers had a good experience and 9% had a poor experience.

Let's take a look at the Williams too. They scored very similar scores but with a noticeable difference:

Williams

The Lab Data didn't perform as well (which is totally fine! Lab Data has its purposes) and it passed the Core Vital assessment from the Field Data, collected from real-world users.

Time strips

Perhaps it is not always about the score? Take a look at the time strip Lighthouse has generated for both sites:

Racing Point Timestrip

Williams Timestrip

We can see that content is loaded earlier for Williams.

Jake Archbald has written a detailed post on who has the fastest website in F1. Highly recommend to read his break down analysis.

How does 'F1 Page Speed Insights' site work?

F1 Page Speed Insights was built using Next.js - Using the PageSpeed Insights API and the Chrome UX Report API to collect the data. Both sets of data are collected during the build of the app and a static export is deployed on Netlify. This site will refresh monthly for us to monitor changes to the data.

UppubDate: 2020-12-19

Previously on F1 Page Speed Insights, the performance score was based on Lab Data captured from Lighthouse. Lab Data has it's benefits - the data is collected from a simulated load on a site using a single device and a fixed network connection. This allows for a reproducible environment which aids in debugging performance issues.

Lighthouse scoring can fluctuate. This is because of external conditions such as internet traffic routing, testing on difference devices or network conditions. And because of this, it might not be the right choice to the performance comparison I am looking for.

I have come across lighthouse-plugin-field-performance which lets Lighthouse weigh the scoring using the Field Data collected from the Chrome UX Report:

The scoring algorithm weighs values for Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS) and picks a minimum score. It uses Core Web Vitals assessment that expects all its metrics to pass thresholds.

Updating the F1 Page Speed Insights scoring to follow this approach results in new positions in the scoring:

The scoring is based on the Core Web Vitals metrics and Lighthouse will score those metrics accordingly. The metric with the lowest score is the final performance score.

All of F1 Page Speed Insights data comes from the Chrome UX Report which is collected from real-world users over the last 28 days.

Credits to Treo for this approach!

How I landed my first job as a software engineer

Fri, 28 Jan 2022 00:00:00 GMT

I was once an entry level developer with no experience, looking for my first door into an engineering career. I finished my studies back in 2009 and for almost a year I could not find a job. It almost felt like a blind journey from one interview to another, that all ended up in rejection because of lack of experience and knowledge. Without knowing where to look or without knowing what to research, I was mostly answering interview questions with answers that I thought was right, based on my limited knowledge in web development (my computer science studies did not include web dev subjects).

It was until my approach changed during an interview at what soon to become the first company that accepted me.

At the very start of the interview, without any thought behind it - I told the engineering manager something I’ve never said during my previous interviews: I said something along the lines of “Before we continue, I want to tell you - I do not know anything. But I want to learn”.

Everything changed from that moment. The manager continued the interview by listing their tech stack and asked if any of it sounds familiar, and my answer was no to all of them. Nevertheless, he did not mind because I showed my eagerness to learn. The interview turned into a crash course introduction to the technologies and soon after, I was accepted for the job.

Call out your area of focus so others are aware that you are know. Shawn calls this the Power of Lampshading.

For entry level developers looking to land their first job as a software engineer, it is totally okay to call out your area of focus. Let the interviewers know that you do not know the answers and you are willing to learn. This is powerful in itself and calling out your focus areas will have an impact throughout your career.

Data Fetching in Next.js

Tue, 18 May 2021 00:00:00 GMT

Next.js offers different methods to fetch data for your page content - choosing the right approach for your application will allow you to benefit from the performant advantages that Next.js provides. We will first start with describing the different methods available, followed with an e-commerce use-case example.

Static Site Generation vs Server-side Rendering

Static Rendering

Your pages are generated as static HTML and this is done at compilation time. It is then served to your users when they request your page.

This is done by using the getStaticProps API. If Next.js finds a page using only this API to fetch data, it will pre-render the page at build time using the props returned from this API.

The content can be cached and served from a CDN. The advantages of this approach:

Very performant - no server required to render content.
Always available - no need for a database when user requests the page.
Less load on backend services - the backend is only required during compilation.

Although, because the content is generated ahead of time, it can be outdated and requires additional deployments to refresh the content.

Server-side Rendering

When a user requests a page, Next.js will generate the content on the server and return it to the user. This is done on per request.

Next.js will enable Server-side rendering when the getServerSideProps API is used in a page.

Additional deployments are not necessary and the user will always get the latest content because the server will be ready to take in requests and generate the content, but the page will lose the benefits of static site generation and it will have the added processing time required to build the page on the server.

Use Case: E-commerce

You can configure each page of your application to fetch data differently. Let's take an e-commerce app as an example:

Product Catalog Page: Static generation

A product listing page will require a list of all available products. We can use getStaticProps to generate a static HTML page and Next.js can fetch the content from an external data source during build time.

export async function getStaticProps() {
  return {
    props: {
      products: await getProducts()
    }
  };
}

const Products = ({ products }) => {
  return (
    <section>
      <h1>Products</h1>
      <ul>
        {products.map((product) => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </section>
  );
};

export default Products;

Product Detail Page: Static generation with dynamic routes

We need a page for each product and for us to do this, we will use getStaticPaths to return a list of product IDs. For each product ID, we will generate a static product page:

Create a page page/products/[id].js which uses dynamic routes.

// Pre-render the path of each product
export async function getStaticPaths() {
  const products = await getProducts();

  const paths = products.map((product) => ({
    params: { id: product.id }
  }));

  return { paths };
}

// Pre-render the page with data related to each product
export async function getStaticProps({ params }) {
  return {
    props: {
      product: await getProduct(params.id)
    }
  };
}

const Product = ({ product }) => {
  return (
    <section>
      <h1>{product.name}</h1>
    </section>
  );
};

export default Product;

Shopping Cart: Static generation + client-side fetching

The content on a shopping cart is different for each user, we can render the page layout as static content and then load the client-side data in the browser:

const ShoppingCart = () => {
  const { data } = useSWR('/api/cart', fetchCart);

  return (
    <section>
      <h1>Your Cart</h1>
      <ul>
        {data.products.map((product) => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </section>
  );
};

export default ShoppingCart;

The above example uses SWR to handle the data fetching.

Conclusion

Next.js supports different ways to fetch data, with static site generation having the advantages required for a fast page load experience. Take the load off the browser rendering your content and prepare it ahead of time during compilation time.

This approach is demonstrated with projects such as Go Bare, an e-commerce website that fetches the content from Shopify and builds the static HTML content. The user is viewing content served from a CDN, rather than requesting it directly from Shopify. When the user is at the shopping cart, we do a client side fetch to Shopify to request data related to the shopping cart session.

How to build an npx starter template

Mon, 05 Sep 2022 00:00:00 GMT

Our favourite frameworks have starter templates to help us get started with setting up our projects with minimal configuration. Some known examples:

Create React App (npx create-react-app my-app)
Next.js (npx create-next-app@latest)
Remix (npx create-remix@latest)

I have created a sample starter template that I will walk through in this article.

How they work: these npm packages have an executable file configured in the package.json:

{
  "name": "create-my-template",
  "version": "1.0.0",
  "bin": {
    "create-my-template": "./index.js"
  }
}

When the user installs the npm package, it will also install the executable configured in bin, allowing the user to run the executable:

$ npm install create-my-template
$ create-my-template

npx is part of npm: it allows you to run a command from an npm package. If the package has a single bin script configured, that command will be used. npx will also fetch the package remotely if it is not installed locally.

This means users run the below command and npx will download the package and run the executable in one line:

$ npx create-my-template

Now that we can execute a command, let's write up an installation script that will generate a starter template. A basic script can look like the one below:

#!/usr/bin/env node

// Usage: npx create-my-template my-app

const spawn = require('cross-spawn');
const fs = require('fs');
const path = require('path');

// The first argument will be the project name.
const projectName = process.argv[2];

// Create a project directory with the project name.
const currentDir = process.cwd();
const projectDir = path.resolve(currentDir, projectName);
fs.mkdirSync(projectDir, { recursive: true });

// A common approach to building a starter template is to
// create a `template` folder which will house the template
// and the files we want to create.
const templateDir = path.resolve(__dirname, 'template');
fs.cpSync(templateDir, projectDir, { recursive: true });

// It is good practice to have dotfiles stored in the
// template without the dot (so they do not get picked
// up by the starter template repository). We can rename
// the dotfiles after we have copied them over to the
// new project directory.
fs.renameSync(
  path.join(projectDir, 'gitignore'),
  path.join(projectDir, '.gitignore')
);

const projectPackageJson = require(path.join(projectDir, 'package.json'));

// Update the project's package.json with the new project name
projectPackageJson.name = projectName;

fs.writeFileSync(
  path.join(projectDir, 'package.json'),
  JSON.stringify(projectPackageJson, null, 2)
);

// Run `npm install` in the project directory to install
// the dependencies. We are using a third-party library
// called `cross-spawn` for cross-platform support.
// (Node has issues spawning child processes in Windows).
spawn.sync('npm', ['install'], { stdio: 'inherit' });

console.log('Success! Your new project is ready.');
console.log(`Created ${projectName} at ${projectDir}`);

This is a basic example. Other things you will need to consider when you build your own:

You can use tools like commander or inquirer to add interactive command-line interface.
Add some error-handling. Examples: Does the project directory already exists before attempting to create it? Did the user specify the project name?
Check which package manager the user prefers to use (eg pnpm, yarn).
Add some styling using chalk.
Do you want to initialize a git repository in the project directory?
Should the installation script do a clean up if installation failed?

Working on a monorepo? This approach can also be used to create packages in your monorepo from a template!

Once you're happy with your starter template, you can npm publish for everyone to use.

Source code examples

A great way to learn is by reading the source code of other starter templates that are known across the community:

Astro (npm create astro@latest)
Create React App (npx create-react-app my-app)
Next.js (npx create-next-app@latest)
Nuxt.js (npx create-nuxt-app my-app)
SvelteKit (npm create svelte@latest my-app)
Remix (npx create-remix@latest)
Turborepo (npx create-turbo@latest)
Vue (npm init vue@3)

How to get started with improving site performance

Fri, 18 Jun 2021 00:00:00 GMT

With so many techniques on improving site performance - how does one start learning about site performance and what are the first steps?

Going to break it into 3 sections that should be explored:

Know your application
Know your HTML
Know your tools

Know your application

Your application is like a high-performance car owned by a motor sport team. How does the team improve their lap times? By improving the cars performance. How does the team improve the cars performance? By first knowing what is in your car.

Get to know what is in your application, get to know what is being bundled inside because the size of your script files will have an impact on performance and reducing bundle size is one of the first techniques I recommend to getting started on improving site performance. Most modern web applications are bundled with many dependencies and the first step in knowing what to improve is by first knowing what libraries are being imported into your application. Get curious about the size of your application.

One of the first tools that I started using is webpack-bundle-analyzer. It generates a report of the output of your webpack build which visualizes the file size of your JavaScript files and what libraries are included in each file. Here is an example screenshot:

So we know what is in our application. What can we do with this information?

We can see lodash takes a large portion of the file. Lodash was one of the first libraries that got me interested in reducing bundle size because it was always included in projects when I first started in my software development career. This is where my curiosity kicked in - why was it so large every time, regardless of the functions that I was using?

After some researching, I came to learn that how you import your dependencies, and how your dependencies were build makes a difference. Using lodash as an example - the package is not tree-shakable. So instead of doing this:

import { difference, isEqual } from 'lodash';

Importing the features directly would avoid the complete package from being imported into the bundle:

import difference from 'lodash/difference';
import isEqual from 'lodash/isEqual';

You can see that instead of the whole package being imported, only the modules that were required are being imported.

This technique doesn't work for every library because it depends on how it is built. The idea here is - get curious about the size of your application. Understand the dependencies being imported and why are they are being imported. There could be better ways to import only the code you need for your application.

A great tool to help you know the size of a packages is Bundlephobia. It's great for times when you want to know the file size cost of a package before importing it into your application. It also suggests similar libraries and the file size comparison.

For example - if you look at the bundle report above, you will see moment being imported and it looks large enough for us to investigate if it can be reduced. Bundlephobia will suggest smaller packages:

Replacing moment with a dayjs, a much smaller alternative with very similar API:

By looking at the bundle size, I was able to drop the JavaScript file size from 868.16 KB to 151.43 KB (83% smaller bundle!).

Small note: moment was a popular library before it went into maintenance mode - highly recommend you to start using the other alternative libraries instead.

Know your HTML

Let's go back to the basics. A HTML page has a head and body. The head is used for the "metadata" of the page, information that is not rendered. body is the document that is being rendered to the viewer.

<html>
  <head>
    <title>My Website</title>
    <script src="./fancy-script.js"></script>
    <link rel="stylesheet" href="./really-large-stylesheet.css" />
  </head>
  <body>
    <h1>Hello world!</h1>
    <p>Welcome to my little place in the web.</p>
  </body>
</html>

Where you place your JavaScript and stylesheets has an impact on how your page renders. The <script> and <link rel="stylesheet"> in the example above is considered render-blocking. Which means they must be loaded and processed before the browser renders the page.

Why is that? Because browsers follow rules to determine if a resource is render-blocking.

A web.dev article on Eliminate render-blocking resources explains perfectly the rules:

A <script> tag that:

Is in the <head> of the document.

Does not have a defer attribute.

Does not have an async attribute.

A <link rel="stylesheet"> tag that:

Does not have a disabled attribute. When this attribute is present, the browser does not download the stylesheet.

Does not have a media attribute that matches the user's device.

With this knowledge and the techniques explains in the article - The HTML sample from above can be improved:

<html>
  <head>
    <title>My Website</title>
    <!-- Defer non critical scripts not required for first render -->
    <script src="./fancy-script.js" defer></script>
    <!-- Inline critical styling required for first render -->
    <style type="text/css">
      h1 {
        color: blue;
        font-weight: bold;
        text-align: center;
      }
    </style>
    <!-- Preload stylesheets not required for first render -->
    <link
      rel="preload"
      href="./non-critical-stylesheet.css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet'" />
  </head>
  <body>
    <h1>Hello world!</h1>
    <p>Welcome to my little place in the web.</p>
  </body>
</html>

Take a look at the HTML source code of projects or your favourite websites and see if there are ways that the scripts and stylesheets can be re-arranged to improve the site performance. This can be a great way to get started and get familiar with how browsers handle resource requests.

Know your tools

Tools that can help you get started on improving site performance:

Google Lighthouse

Provides insights on best practices for your websites. It can run from Chrome DevTools or from a CLI. It scores your website on the Core Web Vitals and also provides suggestions on how to improve page load speed.

This is a great place to start. Run it on your own websites to get familiar with some of the suggestions reported and use them to explore many other techniques in improving performance. The suggestions also link to web.dev articles that go in details on why these suggestions are listed.

Lighthouse reports on Lab Data which means the scores may change each time depending on network conditions, so do remember to run it a few times before finalizing any solutions.

PageSpeed Insights

Analyses the performance of a website and generates a report that provides suggestions on what can be improved. It provides Lab Data powered by Google Lighthouse and is always updated when a new version of Lighthouse is released.

It also reports on Field Data from real users collected from Chrome UX Report, which is a great way to report on how your users are experiencing your website.

WebPageTest

Measures your website performance using different locations, different browsers and different devices. It runs three tests and provides a summary which includes a waterfall view that chronological lists all the resources that were downloaded.

The other features that will come useful to you:

Can generate videos comparison of how your website loads against other sites.
Highlights which element on the page was the largest contentful paint.
Generates videos of any layout shifts that occurs on your website.

The waterfall view is very useful in understanding the load times of each resources being downloaded and which were potentially blocking you from having a faster website. For example - when running a test on my site, we can see 2 resources were downloaded before first render:

I can improve the load times even further by inlining the critical styling and lazy loading the image because it is found at the bottom of the page.

I go a little further with WebPageTest in Page Speed Comparison of Singapore Commerce.

Where to go from here?

web.dev is a great place to learn everything you need on making your websites faster. Start with the Fast load times to learn techniques on improving site performance.

Once you got a hang over some of those techniques, take a look at the Metrics course to learn the metrics used to report on site performance.

When you are ready, head over to the Web Vitals course to learn all about the Core Web Vitals and why these metrics are important for a great user experience.

Jamstack vs Traditional Web

Sat, 11 Dec 2021 00:00:00 GMT

Traditional Web

Here is a story about a popular online store - Uncle Bobba’s Bubble Tea. Uncle Bobba had a traditional web application that looked like this:

This is a simplified diagram and the idea behind this is to show you a rough example of how a typical e-commerce website looks like. It’s not limited to auth and payment services and can also have other moving systems. When the user requests a page, the server is generating the content on the server side before returning the content back to the user.

It works. It does it’s job. Uncle Bubba had happy customers.

Then came a time when Uncle Bubba decided to release a new product. The news spread fast across the land and Uncle Bubba found a lot of customers coming to his store:

Suddenly, things did not go to plan. The team soon discovered the pages were not responding. There was lag in server response and API calls between services were timing out. The systems were so heavily coupled together and it was too difficult to pin-point where it went wrong. Not long after, Uncle Bubba found himself with some angry customers who didn’t get to enjoy his new bubble tea flavours.

This could be caused by many reasons in Uncle Bubba's architecture and there is a high chance of happening in systems that are highly coupled with so many moving parts.

Surely there is a way to solve this. After all, we are only serving a product catalog of some text and images. What if we can remove this black box (the server in the diagram) and allow the users to interact directly with the HTML without needing a server to generate the content on the fly every time the user requests the page?

This is where Jamstack comes to play.

What is Jamstack?

Statically generating your UI application and decoupling it from your other systems.

Javascript Client-side interactions such as navigation and talking to API services.

API Interact with third-party services that are decoupled from each other.

Markdown Prebuilt HTML pages generated using a static site generator.

Using your favourite front-end framework (eg React, Vue, Svelte) to build a pre-rendered copy of your UI application and deploying it on a CDN. Think of it like taking a snapshot of your UI and storing it on the cloud. Your users do not need to interact with your server.

How is a Jamstack site generated?

This happens in the continuous-integration (CI) build pipeline:

Source code It all starts in the git repository. Jamstack requires the application stored in a version control.

Static site generator On a new commit, a build step is triggered and the static site generator will build the application. During the build, if the application requires any content from an external data source, the static site generator will fetch that data. This can be from any external service that provides content in a format that the static site generator supports. Example of data sources: Headless CMS, databases, Markdown.

Static content Once the package is bundled and optimized for the web, it is deployed to a CDN. Which is an important element of Jamstack and it one of many reasons why Jamstack is so fast - the pre-rendered static HTML content is served around the world.

This process of building a Jamstack application moves the server generation of your page to the build pipeline.

How does it look like now that there is no server?

There is no connection with the users and the build pipeline. The users are only requesting the prebuilt HTML markdown that has been served from the CDN and the user is only interacting with the client-side APIs.

Why Jamstack?

Lower costs: No server costs (only paying for storage).
Security: No user-facing systems required to serve the content.
SEO: Crawlers work better with pre-rendered content.
Performance:
- Static pages served from CDN.
- No flash of unstyled content.
Web-optimized image rendering:
- Fetch above-the-fold images immediately.
- Delay rendering of off-screen images.
- Image placeholders to avoid layout shifts.
- Automatically compressed and optimized for web.

Any limitations?

Some limitations that the community and static-site-generators are working on solving:

Previewing content before publishing can be challenging.
Long builds times if there are a large number of pages to generate.
Not suitable for dynamic content.

Conclusion

By moving away from a traditional architecture, an online e-commerce store can now handle a large number of users by serving statically generated pages from a CDN - fast rendering pages decoupled from the underlying systems that were used to generate the content.

Jamstack decouples your UI from your other systems, making it a powerful approach in building high performing applications that can scale and is cost-efficient.

Measuring the performance of the McLaren Racing website

Sat, 19 Mar 2022 00:00:00 GMT

With McLaren Racing recently announced a partnership with Google Chrome, this is a great opportunity for McLaren to measure the performance of their website and look into how it can be improved. Today, we will look at their performance scores and talk about some possible improvements that McLaren can do to their website performance.

How the McLaren Racing website will be measured

We will use a couple tools to measure:

F1 Page Speed Insights - an online tool that aggregate the scores and compares the websites of the teams involved in Formula 1.
PageSpeed Insights is an online tool that reports on site performance and it includes both lab data and real-world field data.
WebPageTest can test websites from different locations around the world using different browsers and can provide in-depth analysis in a site’s performance.

An earlier post was written on the page speed performance of Formula 1 websites which explains in details how web performance scores are measured. Read “Page Speed Performance of Formula 1 Websites”.

The performance score of the McLaren Racing website

Using F1 Page Speed Insights we can see how McLaren Racing is doing against the other teams. Lots of room for improvement if McLaren wants podium wins this year.

The detailed breakdown on McLaren Racing’s website shows that it did not pass the Core Web Vitals assessment. We will look at some possible improvements that can bump the score up.

The current state of the McLaren Racing website

The filmstrip generated by WebPageTest is a good tool to see the rough timing of elements as they start to appear on the page. Here we can see the main background starts to load around the 6 second mark.

WebPageTest also provides a waterfall of the network requests made by the page. We can use this to understand the sequence of the requests and their timings:

Possible Improvements to the McLaren Racing website

Avoid blocking resources on other domains

Row 5 of the waterfall shows a render-blocking CSS that is loaded in the head of the page. The thin line at the start of the request is the connection setup because it is located on a different domain. We can prepare this connection set up earlier by using <link rel="preload"/> to initiate the download sooner.

Learn more about how to preload critical assets to improve loading speed.

Avoid loading unused CSS

A deeper look into the CSS from above and we can see that 94.7% of it is unused on the landing page - it is render-blocking and mostly unused on this page. We can cut a lot of the 500ms if we only load the CSS required on this page (we can also just remove this CSS file entirely and inline the small amount of CSS that was used).

Learn more about removing unused CSS.

Preconnect for early connection setup

The McLaren Racing website loads the assets from different domains which has a connection cost (indicated by the thin line that appears before the requests in the waterfall chart). We can preconnect to those domains to let the browser know we intend to make a request to those domains and so the browser will prepare the connection early and avoid having to do it later when we make the requests:

<link rel="preconnect" href="https://static-cdn.mclaren.com" />
<link rel="preconnect" href="https://media-cdn.mclaren.com" />

Learn more about establishing network connections early to improve perceived page speed.

Avoid blocking parsing with JavaScript

The JavaScript file on Row 6 is parser-blocking. It is located in the body in the document and the browser has decided to parse and execute this JavaScript file before it attempts to download the other assets on the page. This can be seen on this waterfall. Row 35 is the main hero background image which has a “wait” time because the browser was waiting for Row 6 to finish executing. This was also seen in the filmstrip video above. By using the defer or async attribute on the JavaScript file on Row 6, 7 and 8, we can remove the render-blocking and the rest of the images on the page can be parsed earlier. And in return, the main background image may possibly load earlier which will bring up the Core Web Vital score. A good illustration on how these attributes work can be found on async vs defer attributes.

Learn more about eliminating render-blocking resources.

Optimise images for the web

The biggest opportunity to improve the McLaren Racing website could be in optimising the large images that they are serving. Here is a screenshot from Google Lighthouse pointing out the possible savings if we are to optimise the images:

The images on the McLaren Racing website aren’t optimised for the web and there is over 13MB worth of these large high-quality images. We can use Squoosh to reduce the file size of these images while maintaining quality.

Doing a quick Squoosh run on the top 3 sized images, there is a cost savings of:

Samsung-Galaxy-S9-v3.png: 805.4 KB -> 88.4 KB (-89.0%)
mclarenplus.jpg: 240.1 KB -> 36.3 KB (-84.9%)
2022-drive-to-survive-4.jpg: 161.1 KB -> 104.5 KB (-35.1%)

Using AVIF format we can even reduce the size even further. AVIF is not supported on all browsers but we can progressively support those that do:

<picture>
  <source type="image/avif" srcset="img.avif" />
  <img src="img.jpg" />
</picture>

Learn more about serving images in modern formats and efficiently encoding images.

Lazy load images that are below-the-fold

Below-the-fold is a term that describes the area of the website that the user cannot see unless they scroll down. Most of the images on the McLaren Racing website are below-the-fold and they are being downloaded even though they are not in view. We can avoid the requests being made by lazy loading those images using <img loading="lazy" /> so they are only requested as the user scrolls closer to those images. This will improve performance and save bandwidth.

Learn more about lazy-loading images and browser-level image lazy-loading for the web.

Summary of opportunities

Recapping the key focus areas that McLaren Racing can take advantage of to improve their web performance:

Avoid blocking resources on other domains.
Avoid loading unused CSS.
Preconnect for early connection setup.
Avoid blocking parsing with JavaScript.
Optimise images for the web.
Lazy load images that are below-the-fold.

How to keep undefined values in JSON.stringify

Mon, 22 Aug 2022 00:00:00 GMT

The JSON spec does not allow undefined values, so when you try to stringify an object that contains an undefined value, the key will get removed:

const person = { name: 'Peter', age: undefined };

JSON.stringify(person);
// '{"name":"Peter"}'

There are workarounds to keep undefined in the return value, but because it is not part of spec, you will not be able to parse the string back to a JSON. Instead, we can replace it with null which is valid.

JSON.stringify has an optional second parameter replacer that can recursively transform properties during the stringify process.

Using the replacer parameter of JSON.stringify, we can replace undefined values with a value that is accepted - such as null:

const person = { name: 'Peter', age: undefined };

function replacer(key, value) {
  return value === undefined ? null : value;
}

JSON.stringify(person, replacer);
// '{"name":"Peter","age":null}'

An example use case where this can come useful is network request payloads in the case we need to let the server know which values are not defined. POST requests have a string body, if we need to send over an object, we require to JSON.stringify the request. The above approach will help us send over values that are not defined (provided that the server understands null as an acceptable value).

How to build an app with Remix and Netlify Graph

Thu, 03 Mar 2022 00:00:00 GMT

In this tutorial, you will learn how to build an app using Remix and use Netlify Graph to talk to third-party APIs. We will use Netlify Graph to fetch data from GitHub and show the user a collection of repository issues. Along the way we will learn about the tools chosen and why they are a great fit for our use case.

Source code and demo

The source code for this app can be found in this repository. Add an issue to the repository (or add a comment to an existing issue) to see the changes get reflected instantly on the demo app.

What is Remix

Remix is a full stack web framework that let's you focus on the user interface and work back through web fundamentals to deliver a fast, slick, and resilient user experience. Remix is great for our use case because it generates fast responding pages on the server so we can get the latest data from GitHub each time the user hits our pages.

What is Netlify Graph

Netlify Graph provides developers with a GraphQL-based approach to integrating with third-party APIs without needing to operate a separate GraphQL server. Developers do not need to spend time learning the API structure of each provider and writing code to piece it together. This is great for our use case because we do not want to worry about how to authenticate with GitHub as Netlify will handle this for us.

Getting Started with Remix

Create a new Remix site. Choose "Netlify" when prompted:

$ npx create-remix@latest

Install dependencies

We will need to install some dependencies for our app to work. Change directory to your new project and run:

$ npm install slugify marked

slugify: Generates URL-friendly paths based on a text string. We will use to generate URLs based on the title of our GitHub issues.
marked: Markdown parser to convert Markdown to HTML. We will use it to render the GitHub issue body onto our HTML page.

Create a GitHub Repository

You will want to create a new repository in GitHub and commit the code that was generated in the earlier step. This will be the repository that we will be fetching data from using Netlify Graph.

$ cd [name of project]
$ git init
$ git add .
$ git commit -m "first commit"
$ git remote add origin https://github.com/your-username/name-of-project.git
$ git add push -u origin master

Install the Netlify CLI

Install the latest version of Netlify CLI and log into your Netlify account:

$ npm i -g netlify-cli@latest
$ ntl login

Change directory to your new project (if you have not done so already) and create a new Netlify site:

$ cd [name of project]
$ ntl init

Start Development Server

Start the Netlify Dev Server with the --graph flag:

$ ntl dev --graph

This will start up a local development server that we will use to build our app. It will also start up a Netlify Graph session that we will use in the next section.

Create a GraphQL query with the Graph Explorer

Select your site from your Netlify team dashboard and then select “Graph” from your Netlify site dashboard menu. Click on "Connect API or service".

Netlify Graph supports a handful of API providers that we can connect with:

We are going to connect to GitHub. Select "GitHub" from the list of providers and you will need to enable both "Authentication" and "Graph Explorer". Then continue with "Start querying GitHub":

Once you have selected your open session (that was created when you started the dev server), you will be presented with a Graph Explorer. This will allow you to query the GitHub API for the data you are interested in fetching. For our use case, we will want to fetch the GitHub repository issues and their comments.

Below is a GraphQL query with Issues as its operation name. Copy the below snippet and paste it in the explorer.

query Issues(
  $owner: String = "petermekhaeil"
  $name: String = "netlify-graph-remix"
) {
  gitHub {
    repository(name: $name, owner: $owner) {
      issues(first: 100, states: OPEN) {
        edges {
          node {
            id
            body
            title
            createdAt
            url
            comments(first: 100) {
              nodes {
                body
                createdAt
                id
                author {
                  avatarUrl
                  login
                }
                url
              }
            }
          }
        }
      }
    }
  }
}

After clicking "Save Changes", you can head back to your IDE and you will notice some changes that have been made to your workspace. A new netlifyGraph folder has appeared:

netlify/functions/netlifyGraph/index.d.ts
netlify/functions/netlifyGraph/index.js
netlify/functions/netlifyGraph/netlifyGraphOperationsLibrary.graphql
netlify/functions/netlifyGraph/netlifyGraphSchema.graphql

Netlify Graph has generated code for us to use to fetch the data from our app.

Fetching Data from Remix

The Remix app we created earlier came with a demo index page. We can remove it and replace the content of ./app/routes/index.jsx with the code below.

import { Link, useLoaderData } from 'remix';
import slugify from 'slugify';
import NetlifyGraph from '../../netlify/functions/netlifyGraph';

export const loader = async () => {
  const { data } = await NetlifyGraph.fetchIssues(
    { owner: 'petermekhaeil', name: 'netlify-graph-remix' },
    { accessToken: process.env.ONEGRAPH_AUTHLIFY_TOKEN }
  );

  return data.gitHub.repository.issues.edges.map(({ node }) => {
    return {
      ...node,
      slug: slugify(node.title).toLowerCase()
    };
  });
};

export default function Index() {
  let data = useLoaderData();

  return (
    <div>
      <h1>Issues</h1>
      <ul>
        {data.map((item) => (
          <li key={item.id}>
            <Link to={item.slug}>{item.title}</Link>
          </li>
        ))}
      </ul>
    </div>
  );
}

Walking through the code:

The loader function is a built-in data loading Remix API. Each Remix route is served from the server and each route can fetch external data before generating the HTML and returning it back to the user. It is in this function that we will fetch data from Netlify Graph and use it in the React template. Learn more about the loader function on the Remix Docs.
NetlifyGraph.fetchIssues is the generated function from Netlify Graph that we will use to fetch the data from GitHub. This was generated when you clicked "Save Changes" in the Netlify Graph Explorer from the earlier step. You can replace the value of owner and name to your own repository, or use the default value if you wish.
The useLoaderData hook from Remix will return the data from the loader function so we can use it in the React template.

Refresh your browser and you will see Remix rendering the list of issues from the GitHub repository.

There are two things we should note from the above code:

Authentication will be taken care by Netlify regardless of which API provider you decide to work with. This is an awesome feature of Netlify Graph because it allows us not to worry about the structures of the third-party APIs. Netlify takes care of this by handling the value of the ONEGRAPH_AUTHLIFY_TOKEN environment variable.
Netlify Graph generated the JS function with the name fetchIssues because the GraphQL query that we wrote had the operation name as Issues. We can have many operations in the GraphQL Explorer and Netlify Graph will generate a JS function for each one with unique names based on the operation name.

Dynamic Routes in Remix

Instead of creating each page manually by hand, Remix can create a route for each of the GitHub issue dynamically.

We can create a dynamic route by creating ./app/routes/$slug.jsx:

import { useLoaderData } from 'remix';
import NetlifyGraph from '../../netlify/functions/netlifyGraph';
import slugify from 'slugify';
import { marked } from 'marked';

async function getLoaderData(title) {
  const { data } = await NetlifyGraph.fetchIssues(
    { owner: 'petermekhaeil', name: 'netlify-graph-remix' },
    { accessToken: process.env.ONEGRAPH_AUTHLIFY_TOKEN }
  );

  const post = data.gitHub.repository.issues.edges.find(({ node }) => {
    return slugify(node.title).toLowerCase() === title;
  });

  return post?.node;
}

export const loader = async ({ params }) => {
  const post = await getLoaderData(params.slug);

  const html = marked(post.body);

  return {
    ...post,
    slug: params.slug,
    html
  };
};

export default function PostSlug() {
  const post = useLoaderData();

  return (
    <div>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ "{{ __html: post.html }}" }} />
    </div>
  );
}

Walking through the code:

getLoaderData will fetch the GitHub data via Netlify Graph and filter for the GitHub issue we want by the value of title.
We have been introduced to params in the loader function. params contain the dynamic key that is attached after the $ in the filename. In our example, the filename $slug.jsx will return params.slug with the value from the URL. We will use this value as the title of the GitHub issue we want to display on this page.

Now if you refresh the page and click on any of the GitHub issues, you'll be redirected to a page with the full issue content. An example of a dynamic route from the demo app:

/getting-started-with-remix-and-netlify-graph

What we learnt today

Each Remix route supports a loader function that is called on the server before rendering. It provides data to the route and can be used in the React template.
Remix supports dynamic routes by using the $ filename convention.
Expected errors can be caught in Remix and we can render user-friendly messages using a CatchBoundary.
Netlify Graph uses a Graph Explorer to query the data we need and is synced with the session opened by the CLI.
Netlify Graph generates code that we can use to fetch data from a third-party API without needing to worry about authentication or understanding the API structure.

Notes - The Coding Career Handbook

Fri, 19 Feb 2021 00:00:00 GMT

These are my learnings from reading The Coding Career Handbook by Shawn Wang. Notes for my future-self. I highly recommend this book for everyone of all levels in their career.

Notes from Part I - Your Coding Career:

Chapter 4: Junior Developer

"It is quite often that doing the things nobody else wants to do often ends up making you indispensable, because A) it has to be done and B) nobody else wants to do them. If you figure out a clever way of doing it, you could even make a career (or startup) out of it!"

Tests are the most common example of this. In fact, a really great way to start a new job is to volunteer to write tests.

“When one teaches, two learn.” - Robert Heinlein

Chapter 5: From Junior to Senior

Much of your learning from Junior to Senior involves gaining tacit knowledge. You can read all the programming books in the world, but, by definition, you are still limited to things that people can write down. Tacit knowledge in engineering is a real thing. Keep a look out for all the lessons you don’t learn in classes or from books. To really make your career explode, make a habit of writing them down for everyone else (Chapter 18 - Write, A Lot!).
In particular, anything you do in public - blogging, speaking, podcasting, making video tutorials, open source work - can help you grow your knowledge and your network at the same time, opening up the possibility for inbound opportunities to come to you. Remember to fight Impostor Syndrome every step of the way!

Chapter 6: Senior Developer

"The best way to be a 10x developer is to teach 10 people what you know."

"The most valuable engineers are the ones who habitually view their work through the lens of what the business needs to succeed. Which is a skill you have to practice and foster and cultivate, just like any other." - Charity Majors

Chapter 7: Beyond your Coding Career

"Becoming a manager is not a promotion - it’s a lateral move onto a parallel track. You’re back at junior level in many key skills." - Sarah Mei

"The best individual contributors are the ones who have done time in management. And the best technical leaders in the world are often the ones who do both. Back and forth. Like a pendulum."

Page Speed Comparison of Singapore Commerce

Thu, 10 Jun 2021 00:00:00 GMT

An online commerce store that offers a great user experience will satisfy the needs of its users and page speed performance is a driving factor to this. This is where Core Web Vitals comes into play. The Core Web Vitals aim to measure user experience. It is a set of metrics that Google uses to measure user experience and it has become one of their key factors in search result rankings. It is also a great way to compare your commerce store against your competitors.

How this will work

10 popular online commerce stores were chosen from Singapore. We will score them based on a scoring system (defined below) and for a few of the sites, we will go into detail on how they performed and what improvements can be made to improve their score.

How Scoring Works

The scoring algorithm weighs values for the 3 metrics used in the Core Web Vitals: Largest Contentful Paint (LCP), First Input Delay (FID) and Cumulative Layout Shift (CLS).
The metric with the lowest score is the final performance score.
The data comes from the Chrome UX Report which is collected from real-world users over the last 28 days.
It is an aggregated data over all form factors (desktop + mobile) and over all effective connection types.

The Performance Score

Live dashboard available at SG Page Speed Insights. You can check out the source code to see how the scores are calculated.

Analysing the stores in detail

We will use WebPageTest and Chrome Dev Tools to analyse a few of these online stores and look at any areas of improvement that can help improve their scores. The test location of the WebPageTest test run will be Singapore and Chrome will be the browser.

I've chosen 3 sites from different markets:

FairPrice (Grocery Retailer)
Sephora (Beauty and Cosmetics)
Circles.Life (Telecommunication)

FairPrice

URL: https://www.fairprice.com.sg/

We will start by looking at the request waterfall:

Possible Improvement - Remove unused JavaScript

The site is built using Next.js which is packed with features to help with performance. A noticeable feature is Dynamic Importing which we can see from their chunk requests. By using Chrome Dev Tool's Coverage feature, let us see how much of these chunks are being used:

1.5 MB (57%) of the chunks are not being used on page load. Reducing the amount of bytes the user needs to download will save the bandwidth and result in rendering the page faster.

Possible Improvement - Reduce HTML Size

Lets look at the very start request waterfall again:

What we see here is that the page didn't render until around the 1.2s mark. The green vertical bar represents the start of first render. The browser is smart enough to render HTML while it is still downloading the rest of it. This tells us that there was no render-blocking resources - that is a good thing!

There are two questions here though - why did it take 1.2 seconds to start rendering, and why did the HTML take 2.5 seconds to finish downloading? The answer could possibly be because of the size of the HTML - it is 269kb of compressed size. If we open up the HTML to see why its so large, we see the server side generated page content and if we look a little deeper down towards the end of the page, we can see a very large JSON script tag used in Next.js applications.

The site is server side rendered using Next.js - once the page has been rendered, the browser needs to take over control of the page and this is called Hydration. The browser needs to understand the components being rendered and for that it requires the data that was used to generate this page. Next.js provides this through a JSON payload found in the HTML (the script has an ID __NEXT_DATA__). If we grab this JSON from the website and run it through JSON Size Analyzer we can examine what sort of information is being send in the HTML.

That's a pretty huge JSON embedded in the HTML. There is a big win for FairPrice if they can cut this down to only what is required for the content that appears on the top half of the page (and then client-side fetch the rest after page load).

If you look up again at the requests up above, row 30 (highlighted in green) is their home banner, the image that is their largest contentful paint. Here it is again:

That thin bar at the start of the request is the connection setup. This occurred because it is the first connection made to this server (this image is hosted on a different domain). FairPrice made an attempt to start this connection setup earlier by using preconnect and dns-prefetch:

<link rel="preconnect" href="https://media.nedigital.sg" />
<link rel="dns-prefetch" href="https://media.nedigital.sg" />

This connection setup could have started earlier if the HTML was received earlier. You see the thin yellow bar at the start of Row 31 and 32? The browser knew about these requests too but it is also waiting for the same connection setup to start downloading the other images. If they cut down the time it takes for the HTML to download, then these image potentially render earlier.

Another method to avoid this connection setup is to move the largest contentful paint to the same server. Either technique can improve their LCP score (which is right now their lowest mark in their Core Web Vital audit).

Possible Improvement - Profiling the layout shift

Above is 2 frames that occurred when the layout shift happened. We can see the font loading and the lazy loading of products (in the bottom-right corner) is causing the layout shift and resulting in the low CLS score.

By examining the frames of your page loading, you could understand more of the experience your user is facing and find any unexpected layout shifts. Reducing the layout shift will improve your audit score. WebPageTest is a great tool to grab these frames and highlight where the layout shift occurs.

Sephora

URL: https://www.sephora.sg/

Two areas we will look at for Sephora is their layout shift and the delay in the largest contentful paint. Let's start with the waterfall request:

Possible Improvement - Reduce render-blocking font files

9 font files were loaded as highest priority from the <head> which is render-blocking. Sephora has split the fonts by weight and style into separate font files. If we loop through all the elements on the page and list down their font usages (using some quick JavaScript) we can see the usages of these 9 font files:

The most fonts used are: "Sephora Sans 700" (83% of the page) and "Sephora Sans 400" (13% of the page). Avalon isn't loaded on this page but 2 render-blocking assets for this font is loaded.

If Sephora is certain they need this many fonts for the landing page, it will come with a heavy cost of delayed page load. If the Sephora brand is okay with an alternative - they can swap out the other 58 elements (4% of the page) to use the same fonts. They can then remove 7 font files that was holding up page rendering.

Possible Improvement - Remove unused JavaScript

We can use Chrome Dev Tools to see how much of that JavaScript is being used on the first page:

1.3 MB (54%) of JavaScript was not used on the page load. Let's look at the requests again:

Because the JavaScript resources are render-blocking, the rest of the page requests such as images and SVGs didn't load until the JavaScript finished downloading. If we can reduce the size of the JavaScript bundles, the rest of the page can continue rendering earlier.

Alternatively, we can async or defer the scripts if they are not required to render the first paint. These attributes will tell the browser it can continue rendering the HTML while it loads these scripts in the background. Here is a great article on Efficiently load third-party JavaScript that details how these attributes work.

Possible Improvement - Preconnect the hero banner

The main image is highlighted in green (Row 46). That thin line at the start of the request is the connection setup, which costed 400ms. This happened because of the new domain request (It looks like it sits behind an image optimization server). Sephora can shave some time off the request if they moved it to the same domain, or preconnect to this other domain like so:

<link
  rel="preconnect"
  href="https://image-optimizer-reg.production.sephora-asia.net" />
<link
  rel="dns-prefetch"
  href="https://image-optimizer-reg.production.sephora-asia.net" />

This would allow the connection setup to happen earlier while the browser was working on other parts of the rendering.

Circles.Life

URL: https://www.circles.life

This one was fun to examine - we can see in the video strip above that the areas we should tackle is the layout shift and the background image.

Possible Improvement - Optimise images for the web

Let's look at the request waterfall:

This section of the requests stood out the most. The images on this page can do with some optimization. 21.5 MB of images was loaded on the landing page. If you're looking for the right tool, squoosh.app is the way to go! Let's try it on the main image that appear above-the-fold:

Original: 300kb

Optimised: 150kb (50%)

I'm not a designer so the optimised image might not be ideal to the designer of this image, but they can tweak the settings to find an acceptable level of quality for this image.

This was the only image visible to the user on page load (above-the-fold). The other 20MB worth of images are found below-the-fold or hidden from the user entirely. This means Circles.Life can defer these off-screen images until they are in the viewport. This can be done using loading="lazy" on the <img />. Circles.Life can also use a lazy-load WordPress plugin too.

Possible Improvement - Reduce render-blocking scripts and stylesheets

A <script> tag that is in the <head> without a defer or async attribute is a render-blocking script. This is mostly the resources in the waterfall request that appears before the first render.

If any of these scripts are not critical code for first render, they should be marked with async or defer attributes. Any code not used on this page should be removed. If they are required and are located on a different server, we can prepare the browser for what is coming with <link rel="preload">.

Same goes with stylesheets - if a <link rel="stylesheet"> does not have disabled or media attribute that matches the user's device, it is considered render-blocking. Identify the critical styling required for first render and keep it in the head. Then load the rest afterwards.

Possible Improvement - Avoid render blocking fonts

The site loads a handful of Google Fonts that we can optimise. We can start by pre-connecting the connection setup to Google. This tells the browser to prepare for the download of the font before it is requested:

<link rel="preconnect" href="https://fonts.gstatic.com" />

A stylesheet is required to load the Google fonts. We can avoid it from being render-blocking by switching rel="stylesheet" to rel="preload":

<link
  rel="preload"
  as="style"
  href="https://fonts.googleapis.com/css2?family=Open+Sans:300,300i,400,400i,600,600i,700,700i,800,800i" />

This technique can be used with any fonts. Harry goes in depth in The Fastest Google Fonts.

Summary

The Core Web Vitals aim to measure user experience. The metrics are insightful and improving the scores will have a great result on your users. Pairing the information Page Speed Insights provides with the performance test results from WebPageTest, developers have the data they need to analyse possible improvements they can make to their websites.

By learning from the websites above, the possible improvements that we found:

Preconnect early
Optimise images for the web
Reduce HTML Size
Reduce render-blocking font files, scripts and stylesheets
Remove unused JavaScript and CSS

I want to know more!

Thank You

Jake Archibald for his amazing lessons on performance testing websites.
Treo.sh for the scoring technique.

Proxying Ackee through Netlify

Wed, 29 Jun 2022 00:00:00 GMT

Proxying the requests to Ackee through Netlify comes with some advantages:

It bypasses the need to configure CORS headers - Because Ackee is self-hosted on a domain that is different to your website, during the installation you will be asked to configure CORS headers for Ackee to accept requests from other domains. With proxy rewrites, the browser will be making a request to Ackee through the same domain so we can skip configuring CORS headers.
It makes it difficult for ad-blockers to detect the tracker - We can rewrite the path to the tracker to not include keywords that can be blocked.

Netlify Redirects can redirect requests to external services and this is how we will be setting up our proxy rewrites.

Adding the rewrite rules

Netlify Redirects rules are configured in a file called _redirects. Create the file if you do not have one already. Here are the rules to use:

/script.js https://your-ackee-domain.com/tracker.js 200
/api https://your-ackee-domain.com/api 200

What we have done is proxying these paths to an external path on another domain:

https://yourdomain.com/script.js -> https://your-ackee-domain.com/tracker.js
https://yourdomain.com/api -> https://your-ackee-domain.com/api

Update the path in your script tag

You will need to update the Ackee script to reference the new path:

<script
  async
  src="/script.js"
  data-ackee-server="https://yourdomain.com"
  data-ackee-domain-id="0000-0000-0000-0000-0000"></script>

Verify the changes

Verify the proxy is working by seeing your website making requests to /script.js and /api and that they respond with status 200.

Improving Shopify page performance using Next.js

Tue, 13 Apr 2021 00:00:00 GMT

With Google announcing that from May 2021 onwards websites will have their rankings impacted by their Core Web Vitals Audit scores, this is a perfect time for a Shopify-based online store to take the lead against their competitors by improving their SEO and their page performance speeds.

One way to improve page speed performance is to migrate to a JAMStack architecture - static sites have the benefits of a strong SEO performance boost which is key to an online e-commerce store.

Go Bare is a popular Australian based skin care company hosted on Shopify. They have plans to take on the world globally and so they are going to need a website with strong SEO and fast page load speeds to improve their Google ranking.

We will use Lighthouse to measure the Lab Data (because the Chrome User Experience Report does not have sufficient real-world speed data for the new website we are building). Here is the score for the existing website hosted on Shopify:

Areas of improvement include:

Removing unused CSS and JavaScript
Eliminate render-blocking resources
Reducing the impact of third-party code.

These are very common to see on e-commerce websites that allow their owners to purchase custom made UI themes and widgets that do not consider performance in their designs. We are going to look at how we can improve these areas by migrating to a static website designed with performance in mind.

Improving the performance scores

We are going to use Next.js and their Commerce Framework. Out of the box, it has a slick look-and-feel and includes the UI components we need without having to build much of it from scratch.

At the time of migrating to the new website, the Next.js Commerce framework was relatively new and so a Shopify Provider was required for the integration with the Shopify APIs.

Shopify provides developers access to their APIs - which will allow us to hook our own Front-End UI to the Shopify backend. These APIs allow us to:

Create a cart on entry to the site
Add products to the cart
Checkout by redirecting the user to the Shopify payment page (which is entirely hosted on Shopify's end).

Shopify redirecting to their own payment page is an awesome feature to the Shopify APIs because it allows us developers to not worry about building payment pages and the security involved in building one.

Along the way, some changes were made to the UI to improve the lighthouse scores in terms of accessbility and best practices.

The Result

It speaks for itself. Here is the final Lab Data scores after migrating the Front-End stack to a static website:

Next steps for GoBare is to start reporting on real user's scores and wait for Chrome UX Report to have enough Field Data for us to revisit the site's performance.

You can check out the website at gobare.vercel.app and compare the experience to the original website at gobare.com.au.

How did Next.js improve the performance?

Pre-rendering - Each page is generated in advance during the build process. The output is static HTML files with minimal client-side JavaScript to render the pages. The static files are then cached into a CDN.
Image Optimization - Next.js optimizes images on demand and works with images hosted on external sources (in our use-case, they are hosted on Shopify). They are also lazy-loaded and are only loaded once they are in the user's view.
Code Splitting - Each page will be code split into its own bundle during the build process and will only include what is only required for that page to render. Smaller bundles means less code to execute, which will result in quicker page load speeds. This also includes the CSS.

These 3 key items helped Go Bare improve their performance scores - removed unused CSS and Javascript, eliminated render-blocking resources and reduced the impact on third-party code.

Adding Dark Mode to your Tailwind CSS website

Mon, 30 Nov 2020 00:00:00 GMT

Tailwind CSS v2.0 introduces Dark mode support and with minimal JS and inline SVG, you can allow your users to manually toggle Dark Mode. We are going to walk through what is required to build the same one from petermekhaeil.com.

Set darkMode to class in your config:

// tailwind.config.js
module.exports = {
  darkMode: 'class'
};

What we want to do is toggle the dark class on the <html> element. When this class appears on your tree, any child elements below it with the dark: will be applied.

Let's start with a base HTML page:

<html>
  <body class="bg-white text-black dark:bg-black dark:text-white">
    <h1>My Website</h1>
  </body>
</html>

Let's add the UI switch using SVGs from Heroicons. We will be using the Moon and Sun SVGs. They also have IDs attached #toggle-dark and #toggle-light. You'll also noticed they are hidden using the hidden class. This is because we would like to avoid any flicker while the app decides which SVG to show (more on this later).

<html>
  <body class="bg-white text-black dark:bg-black dark:text-white">
    <h1>My Website</h1>
    <!-- Moon SVG from Heroicons -->
    <svg
      xmlns="http://www.w3.org/2000/svg"
      fill="none"
      viewBox="0 0 24 24"
      stroke="currentColor"
      class="hidden h-6 w-6 cursor-pointer"
      id="toggle-dark">
      <path
        stroke-linecap="round"
        stroke-linejoin="round"
        stroke-width="2"
        d="M20.354 15.354A9 9 0 018.646 3.646 9.003 9.003 0 0012 21a9.003 9.003 0 008.354-5.646z" />
    </svg>
    <!-- Sun SVG from Heroicons -->
    <svg
      xmlns="http://www.w3.org/2000/svg"
      fill="none"
      viewBox="0 0 24 24"
      stroke="currentColor"
      class="hidden h-6 w-6 cursor-pointer"
      id="toggle-light">
      <path
        stroke-linecap="round"
        stroke-linejoin="round"
        stroke-width="2"
        d="M12 3v1m0 16v1m9-9h-1M4 12H3m15.364 6.364l-.707-.707M6.343 6.343l-.707-.707m12.728 0l-.707.707M6.343 17.657l-.707.707M16 12a4 4 0 11-8 0 4 4 0 018 0z" />
    </svg>
  </body>
</html>

We will check if the user has dark mode enabled in their browser. If enabled, then toggle the correct SVG to appear and add the dark class to <html>:

var userPrefersDark = window.matchMedia('(prefers-color-scheme: dark)');
var toggleDark = document.getElementById('toggle-dark');
var toggleLight = document.getElementById('toggle-light');
var htmlElem = document.querySelector('html');

if (userPrefersDark.matches)) {
  htmlElem.classList.add('dark');
  toggleDark.classList.add('visible');
  toggleLight.classList.remove('hidden');
} else {
  toggleLight.classList.add('visible');
  toggleDark.classList.remove('hidden');
}

Let's now add some event handlers to the SVGs to toggle dark mode on/off:

toggleLight.addEventListener('click', function () {
  localStorage.setItem('theme', 'light');
  htmlElem.classList.remove('dark');
  toggleDark.classList.add('visible');
  toggleDark.classList.remove('hidden');
  toggleLight.classList.add('hidden');
  toggleLight.classList.remove('visible');
});

toggleDark.addEventListener('click', function () {
  localStorage.setItem('theme', 'dark');
  htmlElem.classList.add('dark');
  toggleLight.classList.add('visible');
  toggleLight.classList.remove('hidden');
  toggleDark.classList.add('hidden');
  toggleDark.classList.remove('visible');
});

One last thing we need to do is store the users preference - we want to do this otherwise when they navigate from one page to another, the setting will reset. We will use localStorage to store the theme. Replace the above JS blocks with this final JS:

var theme = localStorage.getItem('theme');
var userPrefersDark = window.matchMedia('(prefers-color-scheme: dark)');
var toggleDark = document.getElementById('toggle-dark');
var toggleLight = document.getElementById('toggle-light');
var htmlElem = document.querySelector('html');

if (theme === 'dark' || (!theme && userPrefersDark.matches)) {
  htmlElem.classList.add('dark');
  toggleDark.classList.add('visible');
  toggleLight.classList.remove('hidden');
} else {
  toggleLight.classList.add('visible');
  toggleDark.classList.remove('hidden');
}

toggleLight.addEventListener('click', function () {
  localStorage.setItem('theme', 'light');
  htmlElem.classList.remove('dark');
  toggleDark.classList.add('visible');
  toggleDark.classList.remove('hidden');
  toggleLight.classList.add('hidden');
  toggleLight.classList.remove('visible');
});

toggleDark.addEventListener('click', function () {
  localStorage.setItem('theme', 'dark');
  htmlElem.classList.add('dark');
  toggleLight.classList.add('visible');
  toggleLight.classList.remove('hidden');
  toggleDark.classList.add('hidden');
  toggleDark.classList.remove('visible');
});

You can view the source code to see it all put together.

@tailwindcss/typography

If you use @tailwindcss/typography, you'll need to add some configs to get dark mode working.

Add a dark:prose-dark class. This will only work when placed next to prose.

<article class="prose dark:prose-dark"></article>
  <h1>Cannot believe adding Dark Mode is this simple!</h1>
</article>

Extend your configuration to add a dark theme:

// tailwind.config.js
module.exports = {
  darkMode: 'class'
  theme: {
    extend: {
      typography: (theme) => ({
        DEFAULT: {
          css: {
            // ...
          }
        },
        dark: {
          css: {
            color: theme('colors.gray.200')
          }
        }
      })
    }
  },
  variants: {
    typography: ['responsive', 'dark']
  },
  plugins: [require('@tailwindcss/typography')]
};

If you've previously extended your theme for Tailwind CSS 1.x, for Tailwind CSS 2.0 you'll need to update default theme key to DEFAULT.

You will then need to extend the rest of your styles. Use this blog's config as an example.

Typescript tips by Matt Pocock

Thu, 01 Sep 2022 00:00:00 GMT

import { Tweet } from 'astro-embed';

Matt Pocock posted a collection of videos on TypeScripts tips that I recommend everyone to watch. These are my notes of each tip that he shared.

Tip #1: Derive a union type from an object

Notes

Derive a union type from an object using dynamic keys. No need to create a union type and specifying each object key manually.

export const fruitCounts = {
  apple: 1,
  pear: 4,
  banana: 26
};

type FruitCounts = typeof fruitCounts;

type SingleFruitCount = {
  [K in keyof FruitCounts]: {
    [K2 in K]: number;
  };
}[keyof FruitCounts];

const singleFruitCount: SingleFruitCount = {
  apple: 2
};

Tip #2: Transform a union to another union using the `in` operator

Notes

Transform { type: 'user' } to { type: 'user', userId: string }
Record supports template literal types.

export type Entity =
  | {
      type: 'user';
    }
  | {
      type: 'post';
    }
  | {
      type: 'comment';
    };

type EntityWithId = {
  [EntityType in Entity['type']]: {
    type: EntityType;
  } & Record<`${EntityType}Id`, string>;
}[Entity['type']];

const resultComment: EntityWithId = {
  type: 'comment',
  commentId: '123'
};

const resultPost: EntityWithId = {
  type: 'post',
  postId: '123'
};

Tip #3: String interpolation

Notes

TS Playground
Uses ts-toolbelt to split strings and merge objects.

import { String, Union } from 'ts-toolbelt';

const query = `/home?a=foo&b=wow`;

type Query = typeof query;

type SecondQueryPart = String.Split<Query, '?'>[1];

type QueryElements = String.Split<SecondQueryPart, '&'>;

type QueryParams = {
  [QueryElement in QueryElements[number]]: {
    [Key in String.Split<QueryElement, '='>[0]]: String.Split<
      QueryElement,
      '='
    >[1];
  };
}[QueryElements[number]];

const obj: Union.Merge<QueryParams> = {
  a: 'foo',
  b: 'wow'
};

Tip #4: Function overloads

Notes

TS Playground
Add type signatures to a compose function.

function compose<Input, FirstArg>(
  func: (input: Input) => FirstArg
): (input: Input) => FirstArg;

function compose<Input, FirstArg, SecondArg>(
  func: (input: Input) => FirstArg,
  func2: (input: FirstArg) => SecondArg
): (input: Input) => SecondArg;

function compose<Input, FirstArg, SecondArg, ThirdArg>(
  func: (input: Input) => FirstArg,
  func2: (input: FirstArg) => SecondArg,
  func3: (input: SecondArg) => ThirdArg
): (input: Input) => ThirdArg;

function compose(...args: any[]) {
  // Implement later
  return {} as any;
}

const addOne = (a: number) => {
  return a + 1;
};

const numToString = (a: number) => {
  return a.toString();
};

const stringToNum = (a: string) => {
  return parseInt(a);
};

// This will work because the return types match the input type
// of the next function.
const addOneToString = compose(addOne, numToString, stringToNum);

// This will NOT work because return type of `numToString` does
// not match the input type of `addOne`.
const stringToNumber = compose(numToString, addOne);

Tip #5: Using `extends` to narrow the value of a generic

Notes

Narrow the value of a generic using extends.

export const getDeepValue = <
  Obj,
  FirstKey extends keyof Obj,
  SecondKey extends keyof Obj[FirstKey]
>(
  obj: Obj,
  firstKey: FirstKey,
  secondKey: SecondKey
): Obj[FirstKey][SecondKey] => {
  return {} as any;
};

const obj = {
  foo: {
    a: true,
    b: 2
  },
  bar: {
    c: 'cool',
    d: 2
  }
};

const result = getDeepValue(obj, 'bar', 'c');

Tip #6: Extract types using `infer`

Notes

Extract props from React components using infer.

import React from 'react';

const MyComponent = (props: { enabled: boolean }) => {
  return null;
};

class MyOtherComponent extends React.Component<{ enabled: boolean }> {}

type PropsFrom<TComponent> =
  TComponent extends React.FC<infer Props>
    ? Props
    : TComponent extends React.ComponentClass<infer Props>
      ? Props
      : never;

const props: PropsFrom<typeof MyComponent> = {
  enabled: true
};

const otherProps: PropsFrom<typeof MyOtherComponent> = {
  enabled: true
};

Tip #7: Using generics and `keyof` to type `Object.keys`

export const myObject = {
  a: 1,
  b: 2,
  c: 3
};

const objectKeys = <Obj>(obj: Obj): (keyof Obj)[] => {
  return Object.keys(obj) as (keyof Obj)[];
};

objectKeys(myObject).forEach((key) => {
  console.log(myObject[key]);
});

Tip #8: Using generics in React props

interface TableProps<TItem> {
  items: TItem[];
  renderItem: (item: TItem) => React.ReactNode;
}

export function Table<TItem>(props: TableProps<TItem>) {
  return null;
}

const Component = () => {
  return (
    <Table
      items={[
        {
          id: '1',
          name: 'Peter'
        }
      ]}
      renderItem={(item) => <div>{item.name}</div>}
    />
  );
};

Tip #9: Generics can be 'curried' through functions

export const makeKeyRemover =
  <Key extends string>(keys: Key[]) =>
  <Obj>(obj: Obj): Omit<Obj, Key> => {
    return {} as any;
  };

const keyRemover = makeKeyRemover(['a', 'b']);

const newObject = keyRemover({ a: 1, b: 2, c: 3 });

// Only `c` is available:
newObject.c;
// ^? (property) c: number

Tip #10: Throw error messages for type checks

Notes

Return an error message as a string type.

type CheckForBadArgs<Arg> = Arg extends any[]
  ? 'You cannot compare two arrays using deepEqualCompare'
  : Arg;

export const deepEqualCompare = <Arg>(
  a: CheckForBadArgs<Arg>,
  b: CheckForBadArgs<Arg>
): boolean => {
  if (Array.isArray(a) || Array.isArray(b)) {
    throw new Error('You cannot compare two arrays using deepEqualCompare');
  }

  return a === b;
};

deepEqualCompare(1, 1);
// ^? const deepEqualCompare: <number>(a: number, b: number) => boolean

// Below will throw error:
// Argument of type 'never[]' is not assignable to parameter
// of type '"You cannot compare two arrays using deepEqualCompare"'.
deepEqualCompare([], []);

Tip #11: Deep partials

Notes

Recursively partial down an object to make each key optional.
Useful for mocking an entity in a test file.

export type DeepPartial<Thing> = Thing extends Function
  ? Thing
  : Thing extends Array<infer InferredArrayMember>
    ? DeepPartialArray<InferredArrayMember>
    : Thing extends object
      ? DeepPartialObject<Thing>
      : Thing | undefined;

interface DeepPartialArray<Thing> extends Array<DeepPartial<Thing>> {}

type DeepPartialObject<Thing> = {
  [Key in keyof Thing]?: DeepPartial<Thing[Key]>;
};

interface Post {
  id: string;
  comments: { value: string }[];
  meta: {
    name: string;
    description: string;
  };
}

const post: DeepPartial<Post> = {
  id: '1',
  meta: {
    description: '123'
  }
};

Tip #12: Loose autocomplete

Notes

Autocomplete while allowing arbitrary values.

type IconSize = LooseAutocomplete<'sm' | 'xs'>;

type LooseAutocomplete<T extends string> = T | Omit<String, T>;

interface IconProps {
  size: IconSize;
}

export const Icon = (props: IconProps) => {
  return <></>;
};

const Comp1 = () => {
  return (
    <>
      <Icon size="xs"></Icon>
    </>
  );
};

Tip #13: Grab types from modules

Notes

Create type from another module.
Map over values to create a union.

// constants.ts
export const ADD_TODO = 'ADD_TODO';
export const REMOVE_TODO = 'REMOVE_TODO';
export const EDIT_TODO = 'EDIT_TODO';

// types.ts
export type ActionModule = typeof import('./constants');

export type Action = ActionModule[keyof ActionModule];
// ^? "ADD_TODO" | "REMOVE_TODO" | "EDIT_TODO"

Tip #14: Globals in TypeScript

Notes

Globals can cross module boundaries

// types.ts
declare global {
  interface GlobalReducerEvent {}
}

export type GlobalReducer<TState> = {
  state: TState;
  event: {
    [EventType in keyof GlobalReducerEvent]: {
      type: EventType;
    } & GlobalReducerEvent[EventType];
  }[keyof GlobalReducerEvent]
} => TState;

// todoReducer.ts
import { GlobalReducer } from './types';

declare global {
  interface GlobalReducerEvent {
    ADD_TODO: {
      text: string;
    };
  }
}

export const todosReducer: GlobalReducer<{
  todos: { id: string }[]
}> = (state, event) => {
  return state;
};


// userReducer.ts
import { GlobalReducer } from './types';

declare global {
  interface GlobalReducerEvent {
    LOG_IN: {};
  }
}

export const userReducer: GlobalReducer<{ id: string }> = (state, event) => {
  // GlobalReducer has the globals from across all reducers:
  // event: { type: 'LOG_IN'; } | ({ type: 'ADD_TODO' } & { text: string })
  return state;
};

Tip #15: Use Generics to dynamically specify the number and types of function arguments

Notes

Uses Extract and infer to specify if a type is optional or not.
Give names to args_0 and args_1 using named tuple.

export type Event =
  | { type: 'LOG_IN'; payload: { userId: string } }
  | { type: 'SIGN_OUT' };

const sendEvent = <Type extends Event['type']>(
  ...args: Extract<Event, { type: Type }> extends { payload: infer TPayload }
    ? // Named tuple
      [type: Type, payload: TPayload]
    : [type: Type]
) => {};

sendEvent('SIGN_OUT');
sendEvent('LOG_IN', { userId: '123' });

Using FaunaDB and Netlify Functions for Analytics

Sun, 06 Dec 2020 00:00:00 GMT

As I continue to build this blog, I want to add some analytics to get an idea of my viewers and what they are interested in reading. Using FaunaDB and Netlify Functions, we are going to build a basic API that will allow us to track the page hits.

TL;DR

You can use Netlify Functions to talk to a database such as FaunaDB. In the below example, we use tracking page hits as a use-case to save into the database. You can found the source code to the Netlify Function here.

The Setup

Front End

We want to keep it as minimal as possible. We can achieve this without using JavaScript by implementing a "Tracking Pixel" which is a <img/> that will be placed on each page. This approach allows us to talk one-way to the server without expecting any data in return. This image src will request our Netlify function which will respond with an transparent image. The Netlify Function will store the page hits into the database and then respond to the client with the transparent pixel.

Back End

This blog doesn't sit on a server (woohoo!). It's a static website built on Eleventy and served from Netlify. Our solution will involve using Netlify Functions which are serverless functions that you can deploy alongside your static website. Behind the scenes, Netlify Functions run on AWS Lambda and the beautiful thing about this is that you don't need to worry about using AWS. Lambda functions are fully managed and auto-scale. AWS and Netlify will take care of setting everything up for you, all we need to do is write the API function and deploy it.

Database

We going to use FaunaDB, a serverless database that is well-documented, can be set up in a couple minutes and works well with serverless functions. This is where we are going to store the page URLs and their page hits.

Everything together should look like this:

Putting it together

FaunaDB

Sign up for an account. The Free account is enough for this tutorial.
Create a new Database and name it after your project.
Create a new collection hits. We will use this to store the page hits.
We now need to create a new Index. In FaunaDB, you use the index to query your documents. (a) Set the Source Collection to hits (b) Set Index Name to hits_by_pathname (c) Set Terms to data.pathname.
Generate an API key under Security. We will use this to query our database from within our serverless function.

Netlify Function

We need to write an API that will:

Query the database for the current page hit for the requested page.
Increase this count and store it back into the database.
Respond to the client with a transparent image.

We are going to use the faunadb package. We will need this as dependency to the serverless function (it won't be used on the client side).

npm install faunadb

Create a file ./netlify/functions/tracker.js. Below is the code we will use. I've added comments to walk through what the function does:

const faunadb = require('faunadb');

exports.handler = async (event) => {
  const { headers } = event;
  const q = faunadb.query;

  // Connect to our database.
  const client = new faunadb.Client({
    // This is the Fauna API Key we created.
    // It's stored in Netlify Environment Variables.
    secret: process.env.FAUNA_SECRET_KEY
  });

  // We will use the referer to know which page we want to track.
  const referer = headers.referer;
  const { pathname } = new URL(referer);

  try {
    await client.query(
      // Bind variables to be in the expression (second parameter)
      q.Let(
        {
          // Match the document by the pathname index
          match: q.Match(q.Index('hits_by_pathname'), pathname)
        },
        // Conditionally evaluate expressions
        q.If(
          // IF the document exists
          q.Exists(q.Var('match')),
          // THEN update the document with an updated page hit.
          q.Update(q.Select('ref', q.Get(q.Var('match'))), {
            data: {
              hits: q.Add(
                // Increment the previous hits by 1
                q.Select(['data', 'hits'], q.Get(q.Var('match'))),
                1
              )
            }
          }),
          // ELSE create the document and set the page hit to 1
          q.Create(q.Collection('hits'), {
            data: { pathname, hits: 1 }
          })
        )
      )
    );
  } catch (error) {
    console.error(error);
  }

  // We respond with a transparent image
  return {
    statusCode: 200,
    body: 'R0lGODlhAQABAJAAAP8AAAAAACH5BAUQAAAALAAAAAABAAEAAAICBAEAOw==',
    headers: { 'content-type': 'image/gif' },
    isBase64Encoded: true
  };
};

The Fauna Query Language provides a collection of built-in functions that we used in this function. We started with Let that allowed us to create the variable match. The expression used an If which takes 3 parameters ( cond_expr, true_expr, false_expr ). For the condition, we want to check if the document exists using Exists. If it exists, we referenced it using Select and Update. We used Add to add 1 to the previous count. If the document did not exist, we created it with Create.

Build Environment Variables

We need to add the FaunaDB API Key into Netlify's Environment Variables. It's referenced in the above code using process.env.FAUNA_SECRET_KEY.

Insert the image

Place the <img/> on your template. Here is how I did it for my template:

{% raw %}

{% if env.environment == "production" %}
<img src="/.netlify/functions/tracker" title="" />
{% endif %}

{% endraw %}

Testing

Testing is a large topic on it's own. Read up on Netlify Dev to get started on the Netlify CLI which will let you test your serverless function locally. I recommend you to test your functions before committing and deploying.

Wrapping it up

Serverless has a large collection of use-cases other than connecting to a database - such as sending out emails and processing payments. With Netlify Functions we didn't need to worry about setting up any cloud infrastructure or configurations, Netlify took care of that for us. FaunaDB being serverless, it also worked very well with our use-case. Both Netlify Functions and FaunaDB have usage-based pricing models, so you only pay for what you consume. Give both a try - you can go one step further and build yourself a portal that queries your new database and graph out your page hits.

What I have learnt as an engineering manager

Tue, 24 Nov 2020 00:00:00 GMT

Taking care of people is hard. Mentors will warn you about this, but you’ll only really know how hard it is when you experience it. Regardless of the difficulty, it’s very fulfilling. There is a strong sense of satisfaction in your duties. And that is because people’s life’s and careers were involved and impacted.
You’re either in it 100% or you’re not in it at all. You cannot do half-baked job taking care of people and their careers. Their career is their top priority so it should be yours too. Model your own roles and responsibilities so it balances people first.
You will have very difficult conversations. Like really difficult ones. As a manager, you will need to confront them and you will learn how to handle them. Do not avoid giving critical feedback because people need to hear your feedback for their own self-growth.
Feedback is critical. There is different types of feedback that you can provide. You can use the Situation-Behavior-Impact (SBI) Feedback Model to provide constructive feedback to your peers.
Don’t be afraid to get personal in your 1:1s. Start the conversations as you would when you go for coffee with them. Ask them how is life treating them, or what they have planned for the weekend. And remember the conversations you’ve had so you can continue the flow in the next 1:1s. Sometimes these sessions shouldn't be about work and perhaps your team member wants to talk or take a break from the work hustle. This is how relationships are built.
It's not a solo job. Look out for the team members that will help you build and support the team. Do not think that you need to do everything yourself. A successful team is one that functions without you getting involved.
"Let it go". Wish someone told me these words during my first few months. The transition from an individual contributor to people manager isn’t straight forward. You’ll naturally want to write code and built features because you were doing it for so many years. It's part of your blood. You'll now need to remember you've changed profession. Plan your delegation. Your hands will be tied up with a lot of new responsibilities, so start early and free up your time because it’s going to get a lot busier for you.
Stay Technical. In saying the above, you'll still need to stay technical. Your new team wants to know you're technical so they can connect with you. You'll need to work out a balance between management and tech. Keep in touch with the industry. You'll also be learning from your team too.
"One Of Us". Work on letting your new team know you are one of them. Create an environment of openness and trust amongst your team. Work on letting them know you will always be there for them. They will support you when times get rough.
Management is a change of profession. Becoming an engineering manager is a different career path and you'll be starting from scratch. You're now a junior again. You will do a poor job at the start. Read Charity Major's The Engineer/Manager Pendulum.
Don’t be afraid to take on the management path. You’ll have the full support from your new team, existing managers and business stakeholders. When you connect with them they will become your support model throughout your new challenges.
You can always return to being an individual contributor. Do not think because you’ve became an engineering manager that you can’t step back to the other path. Remember it’s not a promotion upwards but another path into a different career. When you're a manager, you pick up skills you don't experience when you're an individual contributor: How to have difficult conversations, how to resolve conflicts, how the business works, how to listen, how to communicate, how to provide feedback. These skills are powerful to have and bringing them back to an individual contributor role can be an advantage to your career growth. It was only until I learnt that being a manager is a different career and not a promotion, that I realised it okay to switch and return to building apps. With the added advantage of taking new skills with me - valuable skills I didn't know existed if I didn't become an engineering manager.
You have to manage yourself if you want to manage others. This would be my biggest lesson. I needed to work on my own self-growth. I needed to be more aware of who I am. How I handled situations in life, how I reacted to emotions and events, finding what drives me in life and in my career. The more I got to know who I am, the more I was able to manage and understand the life's of others that I needed to manage in the work place.

Peter Mekhaeil

3 benefits interviews bring you

Learn about what you know

Learn about what you do not know yet

Learn to negotiate

Each experience will be unique

Accelerate your delivery with modern tools

Use a fast package manager

Migrate to a fast development tool

Use a build system

AI Native Documentation

Render Markdown for Agents

AI Prompts

Ask AI

Copy Page as Markdown

Markdown URL Support

llms.txt

MCP Servers

Be strong like your code

Daily Maintenance

H20 yourself

Take breaks

Take the stairs

Stand while working

Cut out the snacks

Avoid desk lunches

Working Out

Get your blood flowing

Create a workout schedule

Join a Club

Measure your activities

Stretching

Building a Today I Learned Habit

Why TIL?

Inspired by "Learn in Public"

Turning a Habit into a System

Broadening the Scope

How I organize mine

Sharing and Collaborating

Why You Should Start a TIL List

Building my personal AI Assistant

What Tatl Can Do

Visualising the Wiki

The Stack

What I learned

Get your own

Page Speed Performance of Formula 1 Websites

How Scores are Measured

Performance Score

Field Data Scores

Team Breakdown

Racing Point

Williams

Time strips

Racing Point Timestrip

Williams Timestrip

Read More

How does 'F1 Page Speed Insights' site work?

UppubDate: 2020-12-19

How I landed my first job as a software engineer

Data Fetching in Next.js

Static Site Generation vs Server-side Rendering

Static Rendering

Server-side Rendering

Use Case: E-commerce

Product Catalog Page: Static generation

Product Detail Page: Static generation with dynamic routes

Shopping Cart: Static generation + client-side fetching

Conclusion

How to build an npx starter template

Source code examples

How to get started with improving site performance

Know your application

Know your HTML

Know your tools

Google Lighthouse

PageSpeed Insights

WebPageTest

Where to go from here?

Jamstack vs Traditional Web