Forem: Jorge

NextJs, Docker and IP Geolocation

Jorge — Sat, 09 Nov 2024 20:20:33 +0000

These days, I've been working on a solution that would allow us to geolocate users through their IP address, with our NextJs project hosted on AWS ECS in a Docker container.

With the primary focus on geolocating users through their IP address, other challenges emerged, which I will enumerate.

1. AVOIDING THIRD-PARTY CALLS

This point was important because, although there is a wide catalog of services (many free of charge) that offer IP geolocation, I didn't want to depend on a third-party call if possible.

During my research, I found several services that allow you to download a binary file with the ".mmdb" extension, which is the actual database we can use to geolocate IPs.

After completing the investigation I opted for Maxmind. They have many options through which you can download the binary database but I decided to use the geoipupdate automation they offer in their documentation. This allows you to automate the process of downloading and updating the .mmdb file.

2. PROTECTING LOGIC FROM CLIENT-SIDE

Another key aspect was to leverage Next.js's server-side capabilities to avoid exposing logic on the client side. In current versions, this can be done by either generating a "route handler" or using a "server action". For versions prior to 13, we would need to create our own "API route".

To obtain our users' IP on the server side, we only need the req.headers['x-forwarded-for'] header provided by Next.js. Once we capture their IP, we'll search for its origin in our file using the mmdb-lib node package.

3. PERIODIC AUTOMATIC DATABASE SYNCHRONIZATION

The Maxmind geoipupdate integration was extremely helpful for this purpose. This integration automatically manages the download and update of the file with minimal configuration, requiring only your credentials to be provided.

The main problem I encountered was that within a node:alpine Docker container, I couldn't execute cron jobs with a user other than root. I resolved this by using supercronic, a tool optimized for running your cron jobs inside Docker images. Additionally, it's worth nothing that this tool facilitates the visualization of logs about how the process targeted by the crontab has progressed.

Once this was resolved, I managed to keep a cron job running in the background within the Docker container where my Next.js project is deployed. This cron job periodically checks and updates my binary database file stored within the container's own file system.

FINAL NOTES

In order to have a guide where part of this process can be visualized, I have generated a pre-configured template. In it, we can verify the functionality and observe the minimum necessary configuration:

Visit my template on Github

Big O Notation and Algorithms in JavaScript

Jorge — Sun, 22 Sep 2024 18:28:47 +0000

Introduction to Big O Notation

Big O notation shows the number of operations an algorithm will perform, its complexity, and how quickly it will grow. It will never show the execution time of the algorithm.

These are the six main types of complexity we find in Big O notation:

Constant O(1): The number of executions will always be the same regardless of the input size "n". It is the best complexity since the size of the input data does not affect it.

Logarithmic O(log n): The number of executions increases logarithmically in proportion to the input size "n". Typically, the executions involve dividing the input data into smaller parts.

Linear O(n): The number of executions increases linearly with the input size "n". The executions will be equal to the input size, so the larger the input, the more executions will be required.

Exponential O(2^n): In this case, the number of executions doubles in relation to the input size "n". If with an input X we get 20 executions, with double that input we will get 400 executions. While not the worst, it is recommended to avoid this complexity, especially for large datasets.

Quadratic O(n^2): In this case, the number of executions increases quadratically with the input size "n". This occurs when there are nested loops. It is one of the worst complexities, along with factorial complexity.

Factorial O(n!): In this case, the number of executions increases factorially with the input size "n". Along with quadratic complexity, it is one of the worst and becomes nearly impossible to handle with large amounts of data.

Let's look at a couple of examples of search algorithms in JavaScript where we can measure two of the listed complexities:

1. Linear Search

Linear search goes through the array element by element until it finds the desired value or reaches the end of the array.

The complexity of this algorithm is O(n), or linear. It increases in proportion to the size of the array, meaning the larger the array, the more executions will be required.

In this code example, we return the index of the element when it matches the value we are searching for, and -1 when the value is not found.

function linearSearch(array, value) {

    for (let i = 0; i < array.length; i++) {
        if (array[i] === value) return i
    }

    return -1
}

Some JavaScript array methods that use linear search:

indexOf
lastIndexOf
includes
find
findIndex
some
every

2. Binary Search

First, it's important to note that this search algorithm can only be performed on sorted arrays.

What happens here is that the array is divided into two halves, then the value we're searching for is compared to determine which half it belongs to. The algorithm iterates with the same operation over the relevant half until it finds the value.

The complexity of this algorithm is O(log n), or logarithmic. In the following code example, at each step, the algorithm halves the search space until it finds the desired value or determines that it is not present. We return the index where the value is found, or -1 if the value is not in the array.

function binarySearch(array, value) {
    let start = 0;
    let end = array.length - 1;
    let middle = Math.floor((start + end) / 2);

    while(array[middle] !== value && start <= end) {
        if(value < array[middle]) end = middle - 1;
        else start = middle + 1;

        middle = Math.floor((start + end) / 2);
    }

    return array[middle] === value ? middle : -1;
}

In Conclusion

Big O notation is a standardized way of measuring the efficiency of different algorithms, focusing on predicting their behavior as the input size grows.

It's important to emphasize the need to dive deeper into these concepts, especially if we aim for excellence when handling large amounts of data.

Resources:

Image of the chart taken from FreeCodeCamp.org

Web Components Introduction

Jorge — Sun, 05 Nov 2023 20:55:21 +0000

What is a web component?

When we talk about a WebComponents, we are talking about a set of Web APIS, which together with different technologies (HTML, CSS and JavaScript) and always natively under web standards, allow you to create elements with a specific purpose in a fully customizable way, reusable and extendable.

Important features of Web Components

1. Custom Elements
2. HTML Templates
3. Shadow DOM
4. ES Modules
5. CSS Scopes & Parts

Custom Elements

They are a set of Web APIS that allow you to define custom HTML elements. Just as the HTML5 standard defines that official HTML tags must consist of a single word, custom elements must consist of at least two words separated by a hyphen.

HTML Templates

They allow you to create code fragments isolated from the document, its content will be inert and will not be processed or rendered until we clone its content

Shadow DOM

It allows you to attach hidden DOMs within the regular DOM, making it possible to encapsulate and isolate elements from the rest of the page.

ES Modules

It´s a native feature that allows the import and export of data fragments between different JavaScript files.

CSS Scopes & Parts

Although CSS works globally by default, we have specific pseudoclasses and pseudoelements in addition to the “CSS Parts” to expose parts of our component to the outside and style them.

Advantages of web components

They follow web standards so they work in any current browser.
Its implementation is native so we do not depend on third-party frameworks or libraries.
They are reusable, extensible and allow us to create fully encapsulated elements.
Currently you can implement them in almost all the most popular Frameworks. Check it

Links

These are some of the documentation in Spanish and English that I consider to be a reference.

Two React apps in the same S3 Bucket.

Jorge — Fri, 10 Mar 2023 11:29:43 +0000

These days ago, I had to search for information and investigate whether two React applications could coexist in the same S3 bucket, without using any other AWS service except the S3 bucket.

I will say that this is not a good practice and only in certain cases like the one that has been presented to me would it be a solution.

The idea is to be able to jump between the two applications once both have been deployed to the bucket. To do this, the first step would be to create a folder structure that facilitates understanding as much as possible.

./react-apps
    /original-app #### Original react app
    /nested-app #### Nested react app

For both projects ( original-app and nested-app) we will use Vite + React. So inside the "/react-apps" folder :

npm create vite@latest original-app -- --template react
npm create vite@latest nested-app -- --template react

Within each project we will find the file "vite.config.js" which we have to adjust in both cases. First we'll go with the configuration file of the "original-app" project:

import react from '@vitejs/plugin-react-swc'
import { defineConfig } from 'vite'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  base: '/',
  build: {
    outDir: '../dist',
    emptyOutDir: true,
  },
})

Basically we are indicating where to build the project and not to show any warning when doing it outside the root directory. We will build both projects in our root directory "/react-apps".

In "nested-app" our configuration file should look like this:

import react from '@vitejs/plugin-react-swc'
import { defineConfig } from 'vite'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  base: '/nested-app/',
  build: {
    outDir: '../dist/nested-app',
    emptyOutDir: true,
  },
})

Here are two differences:

The first is that we are indicating that "/nested-app/" will be the public route where the application will serve us both in development and in production.
The second is that we are telling it to build the project in a subdirectory of the "original-app" build.

Once we have the configuration files as we have seen, the next step would be to install React Router in both projects.

npm install react-router-dom localforage match-sorter sort-by

We will need to use the "HashRouter" component so that the two applications can coexist and we can go from one to the other once they are in our bucket or we are serving the static ones through "npm serve" . You can read the official documentation to understand how works this component.

To understand the behavior at a basic level, let's take a look at the "App.jsx" components of both the "original-app" and "nested-app" applications.

In both applications we have configured two routes:

Home page => "/"
Page about => "/about"

This would be the component of our "original-app" project:

// Path: react-apps/original-app/App.jsx

import { HashRouter, Route, Routes } from 'react-router-dom'

const App = () => {
    return (
        <HashRouter basename={'/'}>
        <Routes>
          <Route
            path="/"
            element={
              <div>
                <a href="/nested-app/#/about">About Nested App</a>
                <a href="/#/about">About Original App</a>
              </div>
            }
          />
          <Route 
            path="/about/" 
            element={
                <div>
                    <a href="/nested-app/#/">Home Nested App</a>
                    <a href="/#/">Home Original App</a>
                </div>
            } 
          />
        </Routes>
      </HashRouter>
    )
}

export default App

And this would be the component of our "nested-app" project:

// Path: react-apps/nested-app/App.jsx

import { HashRouter, Route, Routes } from 'react-router-dom'

const App = () => {
    return (
        <HashRouter basename={'/'}>
        <Routes>
          <Route 
            path="/" 
            element={
            <div>
                <a href="/nested-app/#/about">About Nested App</a>
                <a href="/#/about">About Original App</a>
            </div>
            } 
          />
          <Route
            path="/about/"
            element={
              <div>
                <a href="/#/">Home Original App</a>
                <a href="/nested-app/#/">Home Nested App</a>
              </div>
            }
          />
        </Routes>
      </HashRouter>
    )
}

export default App

Right now we could move between the two routes of both applications. Jumping from one application to another with the only peculiarity that the "HashRouter" component works by adding "Hash" to the routes. You could share information between the two applications either through the URL or through the "SessionStorage" or "LocalStorage".

Once we have all this structure we can execute the build of "original-app" and then the build of "nested-app".

# Path: react-apps/original-app
npm run build

# Path: react-apps/nested-app
npm run build

The "/dist" folder will be generated in our root directory and we should see something like this:

./react-apps
   /original-app #### Original react app
   /nested-app #### Nested react app
   /dist #### Folder with both builds

Inside of "/dist" folder:

.dist/
   index.html #### Index of original-app
   /assets #### Assets of original-app
   /nested-app #### Folder with nested-app
     index.html #### Index of nested-app
     /assets #### Assets of nested-app

Now we could upload the contents of the "/dist" folder and have the two applications coexist within the same S3 bucket. We could also serve our statics by running the "serve" command from the "/original-app" folder which would be our root application.

# Path: ./react-apps/original-app
npm run serve

Finally, just remember that this is not a good practice and that the React Router documentation itself currently advises against the use of the "HashRouter" component. But for certain cases, it could be a temporary solution to a problem since with this it would not be necessary to use AWS "CloudFront", just the S3 bucket.

Thanks to my co-worker Víctor 🙌 and the community of Daniel Primo 💜 who helped me with this experiment.

Greetings 👋