Setting up everything

First, we need to set up Firebase. If you haven't already done so, go to the Firebase console and create a new project.

Once you have created a new project, you will need to install the Firebase CLI. You can do this by running the following command in your terminal:

npm install -g firebase-tools

After the Firebase CLI is installed, log in to your Firebase account by running the following command.

firebase login

Then, you need to set up Firebase Hosting. To do that just type the following and follow the steps which will automatically take care of setting up the GitHub Action.

firebase init hosting

This command configure your accounts by creating a service account in firebase with the necessary perfmisions to deploy to firebase hosting and also encrypts that service account's JSON key and configure a GitHub secret with it. Finally, it creates two GitHub workflows files. And just like that, you will have everything ready to start deploying every time you push to your repository.

The GitHub Actions

By running the previous steps, you will end up with a .github/workflows folder with two files. The firebase-hosting-merge.yaml is used when you merge to main and looks like the following.

name: Deploy to Firebase Hosting on merge
'on':
  push:
    branches:
      - main
jobs:
  build_and_deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          cache: npm
      - run: npm ci && npm run build
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          firebaseServiceAccount: '${{ secrets.FIREBASE_SERVICE_ACCOUNT }}'
          channelId: live
          projectId: { your-project-id }

It has four steps: the repository checkout, the Node.js setup (with the npm cache, which speeds up npm ci quite a bit), then npm ci && npm run build to install all the dependencies and build the site (plus a few other scripts), and finally the FirebaseExtended/action-hosting-deploy@v0 action, which deploys the site to the live channel. @v0 is not a typo: it's the action's current major version. Note that all the secrets were created by the firebase init hosting command.

Regarding the build script, I mentioned that it performs other tasks as well. The following is part of my package.json that shows the tasks that are being run.

  "scripts": {
    "copyimages": "tsx ./scripts/copy-imgs.ts",
    "prebuild": "npm run copyimages",
    "build": "next build",
    "postbuild": "next-sitemap"
  },

You can see that I use the pre and post scripts to run other stuff: npm run build runs npm run copyimages before and next-sitemap after. Since Next.js 14 there is no next export command; you set output: 'export' in next.config.js and next build writes the static site to the out folder, which is what Firebase Hosting serves ("public": "out" in firebase.json). The copy images scripts it's a simple script that just copy the images from the posts folder to the public folder and next-sitemap as you can guess, creates a sitemap.xml.

Going back to the workflows, the other yaml file named firebase-hosting-pull-request.yaml is very similar but targets the pull request targeting your main branch and the only real difference is that it doesn't have the channelId: live configuration which means that it will create a preview channel in Firebase Hosting and comment the preview URL on the pull request. Preview channels expire after 7 days by default; you can change that with the expires input (for example expires: 30d).

You can find more information on this GitHub action in the marketplace site.

Conclusion

In this tutorial, we have walked through the process of setting up a GitHub Actions workflow to deploy an static site to Firebase. GitHub Actions makes it easy to automate the deployment process, freeing up time for other tasks. With this knowledge, you can deploy your static sites to Firebase quickly and easily, ensuring that your site is always up-to-date. Not only that, but you can also have preview deployments which is a super powerfull tool to test everything.

Of course, this tutorial only scratches the surface of what is possible with GitHub Actions. You can use GitHub Actions to automate a wide variety of tasks, from running tests to deploying to multiple environments. With a little creativity, you can automate almost any task in your development workflow.

So why not give GitHub Actions a try? It may just save you hours of manual work and streamline your development process. Happy coding!

The best example I have and why I started to play around with it, it's this blog as I'm using it to process from markdown to html adding code snippets, calculate the reading time and creating a short description in the middle.

In this post, I will share a quick review and also show what I'm doing for my personal blog with it.

What is Unified.js?

At its core, Unified.js is a parsing library that makes it possible to work with natural language data in a standardized format. This is achieved by transforming raw text into an abstract syntax tree (AST), which is a structured representation of the text's meaning and structure. With this AST, you can easily manipulate the data and extract meaningful information.

For example, let's say you have a blog post written in markdown. With Unified.js, you can parse the markdown text into an AST, then extract the headings, links, and other important information. This information can then be used to create a table of contents, generate a summary, or any other number of useful applications.

To parse natural language data with Unified.js, you simply need to pass the text to the unified() function, along with a parser that corresponds to the format of the data. For example, to parse a markdown file, you would use the remark-parse parser (remarkParse).

Here's a code sample that demonstrates how to parse a markdown file with Unified.js:

import { unified } from 'unified';
import remarkParse from 'remark-parse';

const markdownText = '# Hello, World!\n\nThis is a sample markdown file.';

const ast = unified().use(remarkParse).parse(markdownText);

In this example, we first import the unified and remark-parse modules, which provide the core functionality for parsing markdown data. Then, we pass the markdown text to the unified() function, and use the remark-parse parser (remarkParse) to parse the data into an AST.

require('unified') doesn't work anymore

Since unified 10 (and the remark/rehype plugins released with it), the whole ecosystem is ESM-only and unified is a named export. That's why the classic const unified = require('unified') fails, either with ERR_REQUIRE_ESM or with unified is not a function. You have two options:

// ESM ("type": "module" in package.json, or a .mjs file)
import { unified } from 'unified';

// CommonJS on Node.js 22.12+ / 20.19+, where require() can load ESM
const { unified } = require('unified');

On older Node.js versions in a CommonJS project, use a dynamic await import('unified') or pin unified@9, the last CommonJS release.

Transforming Natural Language Data

Once you've parsed natural language data into an AST, you can then use Unified.js to transform this data in a variety of ways. With its flexible architecture, you can create custom transformations that manipulate the AST and extract information in a way that is tailored to your specific needs.

For example, let's say you have a large collection of customer reviews, and you want to extract the sentiment of each review. With Unified.js, you can create a custom transformation that analyzes the sentiment of each review and categorizes it as positive, negative, or neutral.

Here's a code sample that demonstrates how to perform sentiment analysis with Unified.js:

import { unified } from 'unified';
import remarkParse from 'remark-parse';
import { toString } from 'mdast-util-to-string';
import Sentiment from 'sentiment';

const sentiment = new Sentiment();
const markdownText =
  '# Customer Reviews\n\nI loved this product!\n\nI hated this product.';

const ast = unified().use(remarkParse).parse(markdownText);

for (const node of ast.children) {
  if (node.type !== 'paragraph') continue;
  const text = toString(node);
  const { score } = sentiment.analyze(text);
  if (score > 0) {
    console.log(`Positive review: ${text}`);
  } else if (score < 0) {
    console.log(`Negative review: ${text}`);
  } else {
    console.log(`Neutral review: ${text}`);
  }
}

In this example, we use the sentiment module to perform sentiment analysis on each paragraph node in the AST (mdast-util-to-string gets the plain text of the paragraph, even when it has links or emphasis inside). The analyze() method returns a score that indicates the sentiment of the text, with positive scores indicating positive sentiment, negative scores indicating negative sentiment, and scores close to zero indicating neutral sentiment.

My own personal experience

As I mentioned before, I'm using it for this blog to process the markdown files and generate what you are reading. The following is the full pipeline.

import { unified } from "unified";
import remarkParse from "remark-parse";
import rehypeInferReadingTimeMeta from "rehype-infer-reading-time-meta";
import remarkGfm from "remark-gfm";
import remarkRehype from "remark-rehype";
import rehypeRaw from "rehype-raw";
import rehypeInferDescriptionMeta from "rehype-infer-description-meta";
import rehypeShiki from "@shikijs/rehype";
import rehypeStringify from "rehype-stringify";
import transformImgSrc from "./remark-transformImgSrc";

export default async function markdownToHtml(slug: string, markdown: string) {
  const result = await unified()
    .use(remarkParse)
    .use(remarkGfm)
    .use(transformImgSrc, { slug })
    .use(remarkRehype, { allowDangerousHtml: true })
    .use(rehypeRaw)
    .use(rehypeShiki, { theme: "github-dark-high-contrast" })
    .use(rehypeInferReadingTimeMeta)
    .use(rehypeInferDescriptionMeta)
    .use(rehypeStringify)
    .process(markdown);
  return { content: result.toString(), meta: result.data.meta } as {
    content: string;
    meta: Metadata;
  };
}

Note that I'm using a lot of transformations, even some custom ones (i.e., transformImgSrc which replace all the images urls paths to move them inside next.js' public folder). You can see the transformImgSrc code below. I'm using the visit function to simplify the navigation in the AST and just finding all the childs of type image and then replacing the image path.

import { visit } from 'unist-util-visit';

const imgDirInsidePublic = 'assets';

export default function transformImgSrc({ slug }) {
  return (tree, _file) => {
    visit(tree, 'paragraph', node => {
      const image = node.children.find(child => child.type === 'image');

      if (image) {
        const fileName = image.url.replace('./', '');
        image.url = `/${imgDirInsidePublic}/${slug}/${fileName}`;
      }
    });
  };
}

Another interesting transformation are the support of GitHub markdown by using remark-gfm and the reading time calculation with rehype-infer-reading-time-meta. As mentioned before and as you can see, I'm also highlighting code snippets at build time with Shiki (@shikijs/rehype). So a lot of power with a few dependencies and chained calls.

Conclusion

The benefits of using Unified.js are many, but some of the most notable include:

• Flexibility: Unified.js is incredibly flexible and can be used with a wide range of data formats, including markdown, HTML, and even plain text. This makes it a versatile tool for a variety of applications.

• Ease of Use: Despite its power, Unified.js is surprisingly easy to use. Its API is intuitive and straightforward, making it accessible to developers of all skill levels.

• High-Performance: Unified.js is built to handle large amounts of data, and its performance is unparalleled. It can handle even the largest of datasets with ease, making it ideal for use in high-traffic applications.

• Extensibility: Unified.js is highly extensible, and its modular design makes it easy to add custom functionality. Whether you need to add support for a new data format or create a custom transformation, Unified.js has you covered.

Unified.js is a powerful and flexible library that makes it possible to work with natural language data in a standardized format. With its ease of use, high performance, and extensibility, it's no wonder that Unified.js has become a popular choice among developers. So why not give it a try? You might just be surprised at what you can build!

After that, I started using medium, to focus on writing instead of all the mantaining and other stuff but that didn't keep for long as medium started to add too many changes and walls. So, I went back to maintain my own site and created a blog in gatsby.js which works great for a while.

A few months ago, when I was trying to write some new content, I realized that I haven't updated the dependencies for quite some time and the site started to fail on running locally as well as on deploying (as this was an static site, it was build on every push to the repository using Azure DevOps Pipelines). I tried to see what dependency was causing issues but after some time I decided that the best was to migrate once again. I was using a very old version of gatbsy with too many custom things to migrate to a new one and I wasn't very happy with the results either.

The base stack

I started investigating what would be the best and created some spikes. After a time, I thought that the best would be to use something more simpler, which I was already using in the everyday, so it could be easier to build as well as maintain. That is when I decided to use next.js as the base stack. As I already had all my blog posts in markdown and I wanted to keep the static site approach, so I choose the blog-starter example as base which already has Tailwind and Typescript support and uses remark for procesing the markdown posts.

As the base example is a bit too simple, I started playing around with it and added things like comments support using disqus (which was what I used in the past). Additionally, I updated the styles a bit to give it a personal touch and added some extra things like analytics and such. I also updated the markdown processing pipeline to support code snippets and other smaller improvements. I will be writing a follow up post on some of those things but if you want any particular information just add a comment or ping me on my social networks (you can always find me as nbellocam).

The infrastructure

For building and deploying the site I wanted to move to GitHub Actions which is (very similar to Azure Pipelines) because my repository was on GitHub. My idea behind this migration was to remove tools and again simplify everything a bit.

Regarding the deployment, I was previously using firebase sites and it always worked fine for me, so I choose to keep using it. For the traffic I have and my general needs it works perfectly and it's free which is a great win. There are many great alternatives nowadays, but, as I mentioned before, I was already using that platform and it was simpler to keep using it as I already have my domain configured there. Additionally, I keep using cloudflare to cache the content.

Some extra considerations

When migrating sites from a stack or platform to another, you always need to consider not only the visible costs but also all the hidden things like the work you will need to do to keep everything working as before. For example, one important thing for a blog site is to keep all the routes, sitemaps and SEO information as before. If you don't plan to do that, you will end up starting all over again with the search engines which in general is very hard. In my case, I updated the base template to use the paths I used to have and also generated a sitemap which wasn't available on the original example.

Final thoughts

All this migration took time and effort which I could have used to create more content or other things, but it's also great way to keep learning new things and play around with new stuff. Even when it can be hard, it's good to dedicate some time to things like this and also invest in yourself to make your life a bit simpler and happier in the long term.

I will be adding some extra posts about what I found most interesting during thisprocess as I did in the past, but you can ask me for any particular thing.

In this post we will see what is a middleware for next.js and how you can solve this issue with it.

Next.js middleware

First, let me set some context. I wrote this for Next.js 12.3 and the Pages Router's built-in i18n routing (i18n in next.config.js). The code below uses the current NextRequest APIs; with the App Router there's no built-in i18n routing, so you'd do the redirect yourself using the same language detection.

Now, what is a middleware? Middleware allows you to execute code before the request is processed. Based on the request information you can perform different actions which is a super useful tool for lots of scenarios such a authentication, A/B Testing, localized pages and more.

The basics are simple. Just create a middleware.ts file in the root of your project with the following stucture and it will be call on every request.

import { NextRequest } from 'next/server';

export function middleware(req: NextRequest) {
  console.log(req.nextUrl);
  return undefined;
}

As this will be call on everything, you might want to apply the logic only to a certain patters for that you can analyze the pathname of the request. For example you could ignore all the request that target the _next folder or the api and also files as you can see in the following example.

import { NextRequest } from 'next/server';

export function middleware(req: NextRequest) {
  const pathname = req.nextUrl.pathname;
  const shouldHandleLocale = !(
    pathname.startsWith('/_next') ||
    pathname.startsWith('/api/') ||
    pathname.includes('.', pathname.lastIndexOf('/'))
  );

  if (shouldHandleLocale) {
    console.log(req.nextUrl);
  }

  return undefined;
}

Handling locales

First, let's get the user's default locale. To get this, we will take advantage of the accept-language header which looks like this: en-US,en;q=0.9,es;q=0.8. We will need to parse it and check if we are supporting those locales. The following code does that, ordering the locales by priority and then filtering them.

const LOCALES = ['es', 'en'];

const getBrowserLanguage = (req: NextRequest) => {
  // e.g. "en-US,en;q=0.9,es;q=0.8" -> [{ code: 'en', q: 1 }, { code: 'en', q: 0.9 }, ...]
  const header = req.headers.get('accept-language') ?? '';
  return header
    .split(',')
    .map(part => {
      const [tag, ...params] = part.trim().split(';');
      const q = params.find(p => p.trim().startsWith('q='));
      return {
        code: tag.trim().substring(0, 2).toLowerCase(),
        // No q means 1 (highest priority), per the HTTP spec.
        q: q ? Number.parseFloat(q.trim().slice(2)) : 1,
      };
    })
    .filter(lang => lang.q > 0) // q=0 means "not acceptable"
    .sort((a, b) => b.q - a.q)
    .find(lang => LOCALES.includes(lang.code))?.code;
};

Now, for the following approach, you will need to define a default locale to detect that we need to process it and then the other locales that you are supporting, so in your configuration, set the following.

  "defaultLocale": "default",
  "locales": ["default", "en", "es"],

Then, we will update our middleware to redirect to the detected locale if the locale was the default one. For doing this, we need to clone the url, and update the locale with the language that we detect. It's important to have a fallback as the headers approach could fail depending on the client's browser. Finally, we will perform a call to NextResponse.redirect(url); with the updated url.

import { NextRequest, NextResponse } from 'next/server';

const DEFAULT_LANGUAGE = 'es';

export function middleware(req: NextRequest) {
  const pathname = req.nextUrl.pathname;
  const shouldHandleLocale = !(
    pathname.startsWith('/_next') ||
    pathname.startsWith('/api/') ||
    pathname.includes('.', pathname.lastIndexOf('/'))
  );

  if (shouldHandleLocale && req.nextUrl.locale === 'default') {
    const url = req.nextUrl.clone();

    const language =
      req.cookies.get('NEXT_LOCALE')?.value ??
      getBrowserLanguage(req) ??
      DEFAULT_LANGUAGE;
    url.locale = language;
    return NextResponse.redirect(url);
  }

  return undefined;
}

Final thoughts

This approach works fine for most of the scenarios but you might even need more things to consider. For example, in my case I had to check that the request could be on an iframe and apply a similar approach to keep the same locale as in the parent window, for that you could play around with the sec-fetch-dest header to see if the request is running on an iframe and also the referer header to see the parent's url. Additionally, in some cases I ended up with double locale in the path (i.e., /en/es/) so I had to add some logic to correct those navigations.

Middlewares are a great tool to handling this kind of cases but you need to consider that the logic you add in there will be executed for everything which might add some performance issues.

It's is a collaborative effort by Google, Microsoft, Mozilla, and other major players in the tech industry to make the web a more capable and user-friendly platform. The project was launched in 2019 with the goal of bringing native app-like experiences to the web platform.

The name "Fugu" comes from the Japanese word for pufferfish, which is known for its ability to inflate itself and expand its capabilities. The name is fitting because Project Fugu aims to do just that for the web platform. Additionally, it said that that kind of fish are toxic if they are not well prepared which is similar to what can happend with these kind of features where security and privacy are super important topics to consider while developing them.

For information of this team inside chromium you can visit their team site and you can also take a look at the developer-friendly landing page of the project. Additionally, you can visit the Fugu API Tracker which gives you a full list of new capabilities added by this project. You can also find this article where they explain the process and the ideas behind this project.

Let's explore some of the APIs that are part of Project Fugu and see how they can be used to create more powerful web applications.

Web Share API

The Web Share API allows web apps to easily share content with other apps on the user's device. This feature was previously only available to native apps, but now web apps can use it as well. Here's an example of how to use the Web Share API:

if (navigator.share) {
  navigator
    .share({
      title: 'Example Page',
      text: 'Check out this cool page!',
      url: window.location.href,
    })
    .then(() => console.log('Shared successfully'))
    .catch(error => console.log('Error sharing:', error));
} else {
  console.log('Web Share API not supported');
}

Device Capabilities API

One of the limitations of web applications compared to native applications is access to device capabilities. The Device Capabilities API is designed to address this limitation by providing a way for web applications to determine what capabilities are available on the device.

Here's an example of how the Device Capabilities API can be used to determine if the device has a camera:

if ('mediaDevices' in navigator && 'getUserMedia' in navigator.mediaDevices) {
  const devices = await navigator.mediaDevices.enumerateDevices();
  const cameras = devices.filter(device => device.kind === 'videoinput');
  if (cameras.length > 0) {
    // The device has a camera
  } else {
    // The device does not have a camera
  }
} else {
  // The browser does not support the Device Capabilities API
}

In this example, we check if the browser supports the Device Capabilities API by checking if navigator.mediaDevices and navigator.mediaDevices.getUserMedia are available. If they are, we enumerate the devices on the device using navigator.mediaDevices.enumerateDevices() and filter for devices with kind set to 'videoinput', which corresponds to cameras. If there are any cameras, we know that the device has a camera.

Contacts API

Another limitation of web applications is access to the user's contacts. The Contacts API is designed to address this limitation by providing a way for web applications to access the user's contacts with their permission.

Here's an example of how the Contacts API can be used to display the user's contacts:

const permissions = await navigator.permissions.query({ name: 'contacts' });
if (permissions.state === 'granted') {
  const contacts = await navigator.contacts.select(['name', 'email']);
  // Display the contacts
} else {
  // The user has not granted permission to access their contacts
}

In this example, we check if the user has granted permission to access their contacts using navigator.permissions.query({name: 'contacts'}). If permission is granted, we can use navigator.contacts.select() to select the contacts we want to display. In this case, we're selecting the contact's name and email.

File System Access API

The File System Access API is designed to address another limitation of web applications: limited access to the user's file system. With the File System Access API, web applications can request access to the user's file system and perform operations such as reading and writing files.

Here's an example of how the File System Access API can be used to read a file:

const [fileHandle] = await window.showOpenFilePicker();
const file = await fileHandle.getFile();
const text = await file.text();
console.log(text);

In this example, we use window.showOpenFilePicker() to display a file picker dialog and allow the user to select a file. Once a file is selected, we use the getFile() method on the file handle to get the file, and then the text() method to read the contents of the file as text.

Conclusion

Project Fugu is an exciting initiative that is bringing native app-like experiences to the web platform. By adding new features and APIs, web apps can now do things that were previously only possible with native apps. As these new capabilities become more widely available, you can expect to see a new generation of web apps that are more powerful and user-friendly than ever before.

Creating the Smart contrat

To create a DApp, you'll need to set up your development environment. There are development framework for Ethereum such as Truffle, Hardhat or Foundry which are very powerful and easy to use, but I want to focus on the consuming that DApp, so we will be using Remix to simplify things a bit.

Remix is a Web Ide that supports creating and deploying solidity's smart contracts in Ethereum. The best is that it provides a few simple examples to start with and you can also compile them and get their ABI (Application Binary Interface) which we will need to call the smart contract from our site.

We can create a simple smart contract like the following which stores and retrive a string.

pragma solidity ^0.8.0;

contract SimpleStorage {
  string private data;

  function setData(string memory _data) public {
    data = _data;
  }

  function getData() public view returns (string memory) {
    return data;
  }
}

The ABI for that smart contract will look like the following.

[
  {
    "inputs": [],
    "name": "getData",
    "outputs": [
      {
        "internalType": "string",
        "name": "",
        "type": "string"
      }
    ],
    "stateMutability": "view",
    "type": "function"
  },
  {
    "inputs": [
      {
        "internalType": "string",
        "name": "_data",
        "type": "string"
      }
    ],
    "name": "setData",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  }
]

Creating the project structure

Now that we have our Smart Contract, let's focus on the rest of the app. First, let's start creating a new empty project with npm init -y.

Next, we need to install the following dependencies:

• web3.js: A JavaScript library for interacting with the Ethereum blockchain.
• remixd: A tool for connecting Remix with a local folder.
• http-server: A simple web server for serving our DApp.

Run the following command to install these dependencies:

npm install web3 remixd http-server --save-dev

Compiling the smart contract

Now, we need to compile the smart contract into bytecode that can be deployed to the Ethereum blockchain. Let's use Remix by starting the remixd daemon by running the following command in your terminal:

remixd -s ~/path/to/your/project

This command will start a daemon that connects Remix with your project directory.

Next, open your web browser and navigate to https://remix.ethereum.org/. Remix should automatically connect to your local folder. If not, click the "Connect to Localhost" button and select the "Shared Folder" option. Then, navigate to your project directory and click "Connect".

Once you've connected to Remix, create a new file called "SimpleStorage.sol" and paste the code from our smart contract. Then, select the "Solidity Compiler" tab in the left-hand menu and click the "Compile SimpleStorage.sol" button. This will compile your smart contract into bytecode that can be deployed to the blockchain.

Now that we've compiled our smart contract, we need to deploy it to the Ethereum blockchain. For this example, we'll be deploying the contract to a local blockchain using Ganache.

To get started, install Ganache from the official website. Once installed, open Ganache and start a new blockchain.

Next, we need to update our JavaScript code to include the address of the deployed smart contract. Open a new file called "app.js" in your project directory and paste the following code:

const Web3 = require('web3');
const web3 = new Web3(new Web3.providers.HttpProvider('http://localhost:7545'));

const abi = [
  {
    inputs: [],
    name: 'getData',
    outputs: [
      {
        internalType: 'string',
        name: '',
        type: 'string',
      },
    ],
    stateMutability: 'view',
    type: 'function',
  },
  {
    inputs: [
      {
        internalType: 'string',
        name: '_data',
        type: 'string',
      },
    ],
    name: 'setData',
    outputs: [],
    stateMutability: 'nonpayable',
    type: 'function',
  },
];

const contractAddress = 'YOUR_CONTRACT_ADDRESS_HERE';

const simpleStorageContract = new web3.eth.Contract(abi, contractAddress);

simpleStorageContract.methods
  .setData('Hello, world!')
  .send({ from: 'YOUR_ACCOUNT_ADDRESS_HERE' })
  .then(() => {
    console.log('Data set successfully!');
    return simpleStorageContract.methods.getData().call();
  })
  .then(data => {
    console.log(`Data retrieved: ${data}`);
  })
  .catch(err => {
    console.error(err);
  });

This code creates a new instance of the Web3 library and sets the provider to a local Ganache blockchain. It also includes the ABI (Application Binary Interface) for our "SimpleStorage" contract, which defines the functions and data types of our contract.

Replace YOUR_CONTRACT_ADDRESS_HERE with the address of your deployed smart contract, and replace YOUR_ACCOUNT_ADDRESS_HERE with the address of your Ganache account.

This code also includes two functions: setData and getData. The setData function sets a string value on our smart contract using the send method, which requires a from address. The getData function retrieves the current value of the data variable using the call method.

Serving the DApp

Finally, we need to serve our DApp to users. We'll be using the http-server package to serve our DApp. Open a new file called server.js in your project directory and paste the following code:

const http = require('http');
const { URL } = require('url');
const httpServer = require('http-server');
const WebSocket = require('ws');
const remixd = require('remixd');

// Start Remixd daemon
remixd.start('http://localhost:65520', '/', process.cwd());

// Start HTTP server
const server = httpServer.createServer({ root: __dirname });
server.listen(8080, () => {
  console.log('Server running on port 8080!');
});

// Start WebSocket server
const wss = new WebSocket.Server({ port: 8081 });
wss.on('connection', ws => {
  const url = new URL(
    ws.upgradeReq.url,
    `http://${ws.upgradeReq.headers.host}`
  );
  const path = url.pathname;
  const fileManager = remixd.getFileManager();

  fileManager.setWebSocket(ws, path);
});

This code starts a Remixd daemon that connects to your project directory, starts an HTTP server on port 8080, and starts a WebSocket server on port 8081. The WebSocket server is used to communicate between Remix and our DApp.

To serve our DApp, open your terminal and run the following command:

node server.js

Once the server is running, open your web browser and navigate to http://localhost:8080. You should see a blank web page.

Now that we have a server running, let's add some HTML and JavaScript to our DApp. Create a new file called "index.html" in your project directory and paste the following code:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Simple Storage DApp</title>
  </head>
  <body>
    <h1>Simple Storage DApp</h1>
    <form>
      <label for="data">Data:</label>
      <input type="text" id="data" name="data" />
      <button type="button" id="setDataButton">Set Data</button>
    </form>
    <p id="dataOutput"></p>
    <script src="./index.js"></script>
  </body>
</html>

This code creates a simple HTML form with a text input and a button. It also includes a script tag that references a new JavaScript file called index.js.

Create a new file called index.js in your project directory and paste the following code:

const setDataButton = document.getElementById('setDataButton');
const dataInput = document.getElementById('data');
const dataOutput = document.getElementById('dataOutput');

setDataButton.addEventListener('click', async () => {
  const data = dataInput.value;
  await simpleStorageContract.methods
    .setData(data)
    .send({ from: 'YOUR_ACCOUNT_ADDRESS_HERE' });
  const retrievedData = await simpleStorageContract.methods.getData().call();
  dataOutput.innerHTML = `Data retrieved: ${retrievedData}`;
});

This code adds an event listener to the "Set Data" button that retrieves the value of the text input, sets the value on the smart contract, retrieves the updated value, and displays it on the page.

Replace YOUR_ACCOUNT_ADDRESS_HERE with the address of your Ganache account.

Time to test your Dapp

Now that we have a server running and our HTML and JavaScript files are in place, let's test our DApp!

Open your terminal and navigate to your project directory. Run the following command to start the http-server.

http-server

Open a new terminal window and navigate to your project directory. Run the following command to start the WebSocket server:

node server.js

Open your web browser and navigate to http://localhost:8080. You should see the "Simple Storage DApp" title, a text input, and a Set Data button.

Enter a string value in the text input and click the Set Data button. You should see the message Data retrieved: [YOUR STRING VALUE] displayed on the page.

Congratulations, you've created your first DApp with JavaScript and Remix! This is just the beginning of what's possible with decentralized applications. Keep exploring and experimenting to unlock the full potential of blockchain technology.

In this post, we'll take a look at some of the key considerations for service worker caching, and some tips for developing a strategy that will help you optimize the performance of your web app.

Understanding Service Worker Caching

Before diving into specific caching strategies, let's take a moment to understand what service worker caching is and why it's important.

A service worker is a script that runs in the background of your web app and provides offline capabilities, background sync, and other features. One of its key features is the ability to cache network requests and serve cached responses instead of making a network request. This is particularly useful when a user visits your web app and their device is offline or has a slow network connection.

Service worker caching can be used to cache a wide range of content, including images, CSS files, JavaScript files, and even API responses. By caching this content, you can ensure that your web app loads quickly, even when the network is slow or offline.

Factors to Consider When Developing a Service Worker Caching Strategy

There are several factors that you should consider when developing a service worker caching strategy. These include:

• The size of your cache: The larger your cache, the longer it will take for the browser to download it, so you need to strike a balance between the size of your cache and the speed at which your web app loads.

• The frequency of updates: If your content changes frequently, you may want to consider using a cache with a shorter lifespan or implementing a strategy that ensures that your users are always using the most up-to-date version of your content.

• Network conditions: Different network conditions can affect the performance of your web app, so it's important to consider how your caching strategy will handle slow or offline network conditions.

• User behavior: The way that users interact with your web app can also affect your caching strategy. For example, if your users tend to visit the same pages frequently, you may want to prioritize caching those pages over others.

• The nature of the content: Not all the content needs to be cached and what's more, some of it may be wrong to cache it. For example if you have real-time information or a time-depending content you probably don't want to cache it.

Strategies for Service Worker Caching

Now that we've discussed some of the factors that you should consider when developing a service worker caching strategy, let's take a look at some specific strategies that you can use to optimize the performance of your web app.

Cache-First Strategy

The cache-first strategy is one of the most commonly used caching strategies for service workers. With this strategy, the service worker first looks for a response in the cache and serves it if it's available. If the response isn't in the cache, the service worker will make a network request for the content and cache the response for future use.

This strategy is effective for content that doesn't change frequently, such as images or CSS files, as it ensures that your users will always have a fast and reliable way to access this content, even when the network is slow or offline.

A possible implementation would be something like the following.

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open(cacheName).then(cache => {
      return cache.match(event.request).then(cacheResponse => {
        if (cacheResponse) {
          return cacheResponse;
        }

        return fetch(event.request).then(networkResponse => {
          // Only cache successful responses (not 404s or 500s).
          if (networkResponse.ok) {
            cache.put(event.request, networkResponse.clone());
          }
          return networkResponse;
        });
      });
    })
  );
});

Network-First Strategy

The network-first strategy is the opposite of the cache-first strategy. With this strategy, the service worker first makes a network request for the content and serves the response if it's available. If the network request fails, the service worker will then look for the response in the cache and serve it if it's available.

This strategy is effective for content that changes frequently and needs to be up-to-date, such as API responses. By prioritizing the network request, you ensure that your users always have access to the latest version of the content.

However, it's important to note that this strategy may result in slower page load times if the network request is slow or fails, as the service worker will need to wait for the network request to complete before serving the cached content.

A possible implementation would be something like the following. Note that this implementation is similar to the last one but in this case we are first fetching and if it works we added to the cache, while if the fetch fail (e.g., the user is offline), it will try to get the request from cache.

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open(cacheName).then(cache => {
      return fetch(event.request)
        .then(networkResponse => {
          if (networkResponse.ok) {
            cache.put(event.request, networkResponse.clone());
          }
          return networkResponse;
        })
        .catch(() => {
          return cache.match(event.request);
        });
    })
  );
});

Stale-While-Revalidate (Cache and Network) Strategy

The cache and network strategy, usually called stale-while-revalidate, combines elements of the cache-first and network-first strategies. With this strategy, the service worker first looks for the response in the cache and serves it if it's available. At the same time, it also makes a network request for the content and updates the cache with the latest version of the content if it's available.

This strategy ensures that your users have access to the latest version of the content, while also providing a fast and reliable way to access the content if the network is slow or offline.

A possible implementation looks like this. The user gets the cached copy right away (if there is one), and the fresh response replaces it in the cache for the next visit.

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open(cacheName).then(cache => {
      return cache.match(event.request).then(cacheResponse => {
        const networkFetch = fetch(event.request).then(networkResponse => {
          if (networkResponse.ok) {
            cache.put(event.request, networkResponse.clone());
          }
          return networkResponse;
        });
        // Keep the service worker alive until the cache is updated.
        event.waitUntil(networkFetch.catch(() => {}));
        return cacheResponse || networkFetch;
      });
    })
  );
});

It's a good fit for things like avatars or non-critical API data, where showing a slightly old version is fine. If you'd rather not write these handlers by hand, Workbox ships all of these strategies (CacheFirst, NetworkFirst, StaleWhileRevalidate) ready to use.

Other Strategies

As you can imaging, there are plenty of other strategies specially because you could perform different strategies for different endpoinds or files.

For example, you could check if the request method and only intercept the request if it's a GET or you could respond with a network first approch if you are dealing with an API call and a caching first approach if not. The following code show something like this (consider the fetchAndCache as a network first approach).

self.addEventListener('fetch', event => {
  if (event.request.method !== 'GET') return;

  if (event.request.url.includes('/api/')) {
    event.respondWith(fetchAndCache(event.request));
    return; // respondWith can only be called once per event
  }

  event.respondWith(
    caches
      .match(event.request)
      .then(response => response || fetchAndCache(event.request))
  );
});

Conclusion

Service worker caching is an essential component of optimizing the performance of your web app. By understanding the factors that you should consider when developing a caching strategy, and by using the right strategy for each request, you can ensure that your web app loads quickly and reliably for your users, even when the network is slow or offline.

What are Service Workers?

A service worker is a JavaScript file that it's executed in the background of a web page. It's separated from the main browser thread and it works in a full asyncronows way so you will not be able to use DOM APIs or syncronous APIs such as localstorage. It acts as a proxy between the web page and the network, intercepting network requests and controlling the behavior of the page in response to network events.

The most notable feature of service workers is their ability to provide offline functionality. With a service worker, you can cache assets and make them available to your users even when they're offline. This can greatly improve the user experience, especially on slow or unreliable networks.

Why are Service Workers Important?

Service Workers offer several key benefits to web developers and users. Firstly, they allow for offline functionality, meaning that users can still access your web application even when they are not connected to the internet. This is particularly important for web applications that are used in areas with poor or unreliable network coverage, such as remote locations or on airplanes.

Additionally, Service Workers can be used to improve the performance of web applications. For example, by caching resources, Service Workers can reduce the amount of data that needs to be downloaded each time the user visits the website, resulting in faster load times.

Finally, Service Workers allow for push notifications and background sync capabilities, which can be used to deliver timely and relevant information to users, even when they are not actively using the web application.

How Service Workers Work

Service workers are registered by your web application, after which they are installed and activated in the background. Once activated, they can listen for network events and respond to them.

Here's a simple example of how a service worker might work:

1. The user visits your web page.
2. The browser checks to see if there's a service worker registered for the page.
3. If there is, the browser downloads and installs the service worker in the background.
4. The service worker is activated and starts listening for network events.
5. The user tries to access a resource that requires a network connection.
6. The service worker intercepts the network request and checks to see if the requested resource is available in its cache.
7. If it is, the service worker returns the cached resource to the page, bypassing the network entirely.
8. If it's not, the service worker makes the network request on behalf of the page, and caches the response for future use.

Implementing Service Workers

To implement service workers in your own web applications, you'll need to write a JavaScript file that acts as the service worker. You'll then need to register this file in your main JavaScript code, which will activate the service worker in the background.

Here's an example of how you might register a service worker in your main JavaScript file:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function () {
    navigator.serviceWorker
      .register('/service-worker.js')
      .then(function (registration) {
        console.log('Service worker registered: ', registration.scope);
      })
      .catch(function (error) {
        console.log('Service worker registration failed: ', error);
      });
  });
}

Note that we first check if the serviceWorker feature is available in the browser, if so, then we register it. If not, the site should work without problems but you will not have the advantages of that the service worker provides.

Once the service worker is registered, you'll need to write the code that listens for network events and caches resources. There are many libraries and frameworks available that can help with this, such as Workbox, but it's also possible to write this code from scratch using the Service Worker API.

Here's an example of a simple service worker that caches all assets:

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('v1').then(cache => {
      return cache.addAll([
        '/',
        '/index.html',
        '/style.css',
        '/script.js',
        '/image.jpg',
      ]);
    })
  );
});

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(response => {
      if (response) {
        return response;
      }

      return fetch(event.request).then(response => {
        let responseClone = response.clone();
        caches.open('v1').then(cache => {
          cache.put(event.request, responseClone);
        });

        return response;
      });
    })
  );
});

In this example, the install event is listened to, which occurs when the service worker is installed. The service worker caches all assets listed in the cache.addAll method.

The fetch event is also listened to, which occurs whenever a network request is made. The service worker intercepts the request and checks if it's available in its cache. If it is, the cached version is returned. If not, the service worker makes the network request, caches the response, and returns it to the page.

Conclusion

Service workers are a powerful tool for improving the performance and offline functionality of web applications. With their ability to intercept network requests and cache resources, they can greatly enhance the user experience. While there is a learning curve to implementing service workers, the benefits are well worth the effort. Try implementing them in your own web applications and see the results for yourself!

This is a topic I really enjoy and on will I worked a considerable amount of time. I gave talks and workshops as well as created tooling. In this article, we'll explore what PWAs are, why they're important, and how to get started with building your own.

What are Progressive Web Apps?

PWAs are web applications that take advantage of modern web technologies to provide a native app-like experience to users. They are built with web technologies like HTML, CSS, and JavaScript and run in a browser, but they can also be installed on a user's device, just like a native app.

PWAs are designed to be fast, reliable, and accessible, even when a user is offline. They should load instantly, regardless of network speed, and provide a smooth and seamless experience. The user experience is the key of all this and we will be focusing on improving it at the best we can.

The Benefits of PWAs

1. Fast and reliable: PWAs are designed to load quickly, even on slow networks, and provide a seamless experience, regardless of network speed. One of the key aspect that facilitate this is that PWA take advantage of the service worker to cache data and resources, which can also enable us to making them available offline.

2. Installable: PWAs can be installed on a user's device, just like a native app. This makes it easy for users to access the app from their home screen, without having to open a browser and navigate to the website. This is one of the most interesting benefits and it's simple to get it as you only need to have a the site behind https, a Web Manifest, and a service worker.

3. Cross-platform: PWAs are built with web technologies and run in a browser, making them platform-independent. This means that a single PWA can run on multiple devices, including desktops, laptops, smartphones, and tablets. Having all those platforms at hand, enables you to reach more people than only targeting a subset of those with a native application which is a great win when deciding which tools to use.

4. Discoverable: PWAs can be discovered through search engines, just like any other website. This makes it easy for users to find and install the app, without having to go through an app store. Not only that, you have the possibility to add your PWA in the native app stores using things like PWA Builder and reach even more people.

5. Lower development costs: PWAs can be developed and maintained with web technologies, which are typically more cost-effective than native app development. This means that it is possible to build a high-quality app at a lower cost. Having a single code source can be very helpful as you don't need to have different teams to build each app and you can write a feature once and take advantage of it everywhere.

Getting Started with PWAs

Building a PWA is straightforward and can be done using any modern web development stack. The basics are the same as any web development, define the user experience and design the app, build it using your prefered web development stack (make sure to use modern tools and frameworks to ensure that the app is fast, reliable, and accessible). Once it's ready, test it, optimize it, publish it and promote it.

This seems to be the usual cycle, right? So what's the special thing when building a PWA? You will add the Web App manifest and the service worker. For the Service worker you can use tools such as Workbox which provide you with tools to make that without effort.

Additionally, you can take advantage of the new Web APIs under what is known as Project Fugu, which enables you to add native features such as push notifications, access to usb ports or bluetooth devices.

A talk in spanish

I talked about PWAs in several conferences but always in spanish. Anyway, if you want to see one of them, you can see the following one.

Final thoughts

Building PWAs is a great way to bring the best of both web and native apps to your users. Whether you're building a simple web app or a complex native app, PWAs are a powerful tool for delivering a high-quality user experience.

Progressive Web Apps are not always the future but the present of web development, providing fast, reliable, and accessible apps that can be installed on a user's device, just like a native app. With the benefits of lower development costs and cross-platform compatibility, PWAs are a great investment for businesses and developers alike.

To ensure the success of your PWA, it's important to focus on user experience, performance, and accessibility. This means using modern tools and frameworks, testing on multiple devices and platforms, and constantly iterating to improve the app.

PWAs are the next step in the evolution of web development, and their potential for providing a native-like user experience on the web is limitless. So if you're looking to build a high-quality app that is accessible, fast, and reliable, consider building a PWA.

What is Progressive Enhancement?

Progressive enhancement is a web development strategy that prioritizes the delivery of core functionality to all users, and then adds additional features and enhancements for those with more advanced browsers and devices. The basic idea is to start with a solid foundation and build up, ensuring that everyone can access the content and information they need, regardless of the technology they're using.

Why is Progressive Enhancement important?

There are several reasons why progressive enhancement is critical for web development:

• Accessibility: By providing core functionality to all users, progressive enhancement ensures that everyone, regardless of their abilities or disabilities, can access and use the website.
• User Experience: Progressive enhancement can enhance the user experience by providing a more responsive and tailored experience, based on the capabilities of the user's device and network.
• Future-proofing: By building a foundation that works for everyone, and then adding enhancements for those with more advanced technology, progressive enhancement ensures that your website will continue to work as technology evolves.

How to Implement Progressive Enhancement

Implementing progressive enhancement involves several steps, including:

1. Determine the core functionality: The first step is to identify the core functionality of your website, such as the ability to read and navigate content, fill out forms, and access information. This should be available to all users, regardless of their technology.

2. Use HTML as the foundation: HTML is the backbone of the web and provides the core structure and content of your website. By using well-structured HTML, you can ensure that the content and information is accessible to all users.

3. Use CSS for styling: CSS is used to add style and visual design to your website. When used in conjunction with HTML, it can enhance the look and feel of your website, providing a more tailored experience for users with advanced browsers.

4. Use JavaScript for interactivity: JavaScript is used to add interactivity to your website, such as drop-down menus, animations, and dynamic content. When used in conjunction with HTML and CSS, it can enhance the user experience for those with advanced browsers.

5. Test and validate: Finally, it's important to test and validate your website to ensure that it works as intended on a variety of devices and browsers, and that the core functionality is available to all users.

An example

The following is an example I like a lot about this, only based on HTML. It's a simple email input which have a lot of powerfull stuff on the back.

<input type="email" name="email" id="email" ​ required aria-required="true" />​

First, for older browsers, it will work as an standard text input, which will fulfill the core objective of getting the email from the user. If the browser is a bit newer, it will support the required tag, which will say to the user that they need to to add the information before submitting it. Additionally, if you are on mobile, you will probably get the special keyboard for email input (the one that has the @ and the .com handly) which will improve your user's experience. Finally, the aria-required="true" tag will help people using readers and such having a better experience as well. A simple but powerful example on how you can focus on the objective and then improve your users experice by adding a few tags.

Conclusion

Progressive enhancement is a key strategy for web development, providing a better experience for all users and future-proofing your website. It's a key aspect to consider in general and a core aspect in things like Progresive Web Apps. By starting with a solid foundation and adding enhancements for those with more advanced technology, you can ensure that your website is accessible and usable for everyone. So if you're looking to enhance your web development skills, consider embracing progressive enhancement and build a better web for all.