Forem: Jaime

NER: Gemini vs Spacy vs Compromise

Jaime — Wed, 18 Mar 2026 16:10:25 +0000

TLDR

For NER, if accuracy is critical, go with an LLM — even an old one like gemma-3-27b-it will outperform tools or small models trained for this task. But by using an LLM you are exposing your data, making an HTTP request, and most likely incurring a cost. If accuracy is not critical and you want to stay in Javascript, compromise is a good package for NER. If you want an even better package and it's OK not using Javascript, then try Spacy.

Intro

Thanks to AI it feels like we are entering into Web 4 — now it's not just about having a static website (Web 1), or letting the user save their data (Web 2), or decentralization (Web 3, although the majority of companies still own our data); but about adding "AI" to your application. What does that mean? Are all applications supposed to be like ChatGPT?

While I don't think adding an LLM just for the sake of it is beneficial, I do think that playing with LLMs helps to learn about them, giving us an understanding of how, when, and why to use them.

I maintain the website chicagomusiccompass, which shows music events in Chicago. All events have a title, so I want to extract artist names from the title. This sounds like a good task for an LLM, right?

I found out about Named Entity Recognition (NER), which is a technique to extract entities from a string. So I'll try three different NER tools and compare their results.

Gemini

As a developer, Gemini has become my first option mainly because they offer almost-free LLM tiers. They might not be the newest, but they're a great starting point. As a developer could go with OpenAI or Anthropic, but they don't offer free tiers. Ollama is a truly free alternative, but this time I'll stay with Gemini.

NER with Gemini is about the prompt:

from google import genai

client = genai.Client(api_key="your_api_key")
title = "Amber Mark Presents: The Pretty Idea Tour"

PROMPT_TEMPLATE = """Extract the person's name from this event title.
Return ONLY the name, nothing else. If no person found, return empty string.

Examples:
"Saxophonist Jarrard Harris Quintet" → "Jarrard Harris"
"Jazz Night at the Blue Room" → ""
"DJ Khaled Live Concert" → "DJ Khaled"
"Annual Wine Festival" → ""

Title: "{title}"
→"""

artist = client.models.generate_content(
    model="models/gemma-3-27b-it",
    contents=PROMPT_TEMPLATE.format(title=title)
)
artist = artist.text.strip().strip('"')

print(artist)

Output:

Amber Mark

I'm using the model gemma-3-27b-it (Google hosts Gemma models on the Gemini API platform), which was released in early 2025. There are newer models, but this one offers a decent number of free requests.

Notice that here I'm using an LLM to perform NER through the prompt. An LLM is trained for multiple purposes, and NER is one thing that LLMs are good at.

Spacy

Spacy is a Natural Language Processing (NLP) library, and one of the things it's trained for is NER. It's also free and open-source — kudos to the team behind it. Gemini is proprietary and accessed through an API with rate limiting and commercial terms; at some point, if you start using it heavily, you will need to pay. Not so with Spacy, which offers a Python package you can install in your project and use freely.

import spacy
nlp = spacy.load("en_core_web_sm") # language model
title = "Amber Mark Presents: The Pretty Idea Tour"
doc = nlp(title)
ent = next(filter(lambda ent: ent.label_ == "PERSON", doc.ents), None)
artist = ent.text

print(artist)

Output:

Mark Presents

Note: next(filter(lambda ent: ent.label_ == "PERSON", doc.ents), None) is the Python way to get the first entry where label_ is "PERSON".

As you can see, the output is similar to Gemini's — but is it good? That depends on your project. The upside is that processing happens locally, with no HTTP requests, meaning your data is not exposed and there's no extra cost.

compromise

I tried three npm packages (compromise, @nlpjs/ner, and node-nlp) and out of the three I found that compromise provides results similar to Spacy. The Python community is larger in terms of data science packages; however, for a Javascript architecture (a website), it makes sense to go with an npm package.

const compromise = require("compromise");

const title = "Amber Mark Presents: The Pretty Idea Tour";
const doc = compromise(title);
const people = doc.people().out("array");
const artist = people && people.length > 0 ? people[0] : "";

console.log(artist);

Output:

Amber Mark Presents:

As you can see, the output includes ":". This is because compromise doesn't actually understand the text — it just runs a set of rules and uses weights to decide what counts as a person. Since "Presents" can be a last name, it gets included as part of the person's name, and the colon comes along for the ride.

Conclusion

I ran the snippets against a list of 1,000 records. Gemini was able to extract a name 66% of the time, Spacy 36%, and compromise 45%. Gemini, even with an old model, not only covered more records but also provided cleaner results. Spacy and compromise provided similar results, and even though Spacy covered fewer records, in some cases the output was cleaner — for instance, Mark Presents vs. Amber Mark Presents:. In both cases it's actually wrong, compared to Gemini's output of Amber Mark.

The older LLM (gemma-3-27b-it) outperformed the smaller models (Spacy and compromise) even though they were trained specifically for this task.

For my purposes, compromise is more than enough. I like staying in Javascript and NER extraction accuracy is not critical for me. If accuracy were a factor, I would go with an LLM.

Finally, all I did was use NER to adjust the styling on the title:

Moving from Nextjs to Qwik

Jaime — Mon, 12 Jan 2026 19:00:00 +0000

Whenever I’m working on a web application, Next.js is my go-to framework. I like it and I’m used to it, but I’ve been hearing a lot about Qwik and decided to give it a shot.

In my previous post, Exploring the Art Institute API and Gemini, I built the app using Next.js. Since it’s a new project, I thought it would be a good exercise to redo it using Qwik instead.

You can still access the previous version, and to make it a bit more interesting, I’m using Lighthouse to compare the two versions:

Both codebases render a static site, which is generated daily using a cron job and a deploy hook.

Network

Let’s start by looking at the Network tab:

Left is Next.js and right is Qwik

This is very interesting because, in summary, Qwik sends fewer bytes to the browser, and fewer bytes translate into faster rendering as well, even though both apps show basically the same UI.

	Next.js	Qwik
Transferred	285 kB	118 kB
Resources	649 kB	172 kB
DomContentLoaded	92 ms	96 ms
Load	368 ms	124 ms

kB transferred is the data sent from the server (CDN) to the browser, which is zipped.
kB resources is the total size once unzipped.

As we can see, the Qwik project sends less data. This is a big win for Qwik.

DomContentLoaded is the event fired when the HTML is parsed and the DOM is built. At this point, JavaScript is executed and images and stylesheets start loading.
Load is the event fired when everything is ready. The browser doesn’t need to download anything else (images, styles, etc.), and the page is fully rendered.

Notice that while DomContentLoaded happens at almost the same time, Load happens much faster for Qwik. This is just how the framework works. In the case of Next.js, since the app is larger, it takes a bit longer to completely render the page.

Note: I checked the “Disable cache” checkbox to always download files from the origin (CDN).

Also keep in mind that these values change on every load. Things like browser cache, internet connectivity, and server response times are different every time. That’s why, when testing these values, a load test is a better approach. Loading the page N times gives you a better average. A single run can be influenced by chance. Still, these numbers are a great benchmark for any website.

Lighthouse

Performance

Right from the start, Qwik gets a perfect score of 100 across the board, while Next.js gets a slightly lower score. This is interesting because it’s not about the application code, but about the framework itself.

Sure, a Next.js application can also reach 100, but that usually requires extra work, which isn’t necessary when using Qwik.

Metrics

Based on the results from the Network tab, it makes sense that these values are lower for Qwik. In simple terms: same UI, fewer bytes, faster rendering.

Diagnostics

Here we can see Lighthouse pointing out that Next.js has some unused JavaScript. This doesn’t happen with Qwik, confirming that Qwik generates a leaner build.

Coding

This is my first time using Qwik, and I didn’t want to use AI agents to convert the code. I spent some time reading the Qwik documentation, and that was enough to build this simple app. Here are some findings:

Components

In Next.js, a function is a component, with no extra syntax needed:

export default function Home() {
  return <div>Home Page Component</div>;
}

With Qwik, you need to use the component$ function:

export default component$(() => {
  return <div>Home Page Component</div>;
});

Not a big deal. The syntax changes a bit, but it’s easy enough to follow.

State variables and clicks

In Next.js, we use useState along with "use client"; because state lives on the client. Similarly, onClick handlers only run on the client.

"use client";

import { useState } from "react";

export default function Home() {
  const [greeting, setGreeting] = useState("hello world");

  return <div onClick={() => setGreeting("hello from click")}>{greeting}</div>;
}

Qwik uses useSignal for "signal variables" and onClick$ for click handlers:

import { component$, useSignal } from "@builder.io/qwik";

export default component$(() => {
  const greetingSignal = useSignal("hello world");

  return (
    <div onClick$={() => (greetingSignal.value = "hello from click")}>
      {greetingSignal}
    </div>
  );
});

Assigning a new value to greetingSignal.value = ... is equivalent to calling setGreeting(...), and it triggers a re-render.

Fetching data

In both cases, data is fetched on the server. Remember, the page is generated daily, meaning the server generates the HTML, which is then cached in the CDN and served to users. Once per day, the server fetches a JSON file.

Next.js:

export default async function Home() {
  const quiz = await fetch(`https://domain.com/name.json`).then((res) =>
    res.json()
  );

  return <Quiz quiz={quiz} />;
}

Since there’s no "use client"; directive, this code runs only on the server.

Qwik:

import { routeLoader$ } from "@builder.io/qwik-city";

export const useQuiz = routeLoader$(async () => {
  const response = await fetch(`https://domain.com/name.json`).then((res) =>
    res.json()
  );
  return response;
});

export default component$(() => {
  const quiz = useQuiz();

  return <Quiz quiz={quiz} />;
});

With Qwik, routeLoader$ defines server-side logic, and the component consumes it as a hook.

Summary

Qwik is clearly a leaner framework than Next.js, and the syntax differences are minimal. Both frameworks share the same core concepts: components, state/signals, data fetching, and more.

One big advantage of Next.js is the size of its community.

At the time of writing:

	Next.js	Qwik
GitHub stars	137k	21.9k
GitHub watchers	1.5k	135
GitHub pull requests	1.2k	43
NPM weekly downloads	15.5 million	16.3 thousand

It’s easy to see that the Next.js community is much larger, which means better ecosystem support, more documentation, and more tooling.

For my personal projects, I’ll definitely keep using Qwik to get more familiar with it. In a professional environment, I’ll stick with Next.js. Just because a framework does something better doesn’t justify the cost of refactoring existing code. Even with AI agents helping, refactoring still involves testing, monitoring, and maintenance. Shaving off a fraction of a second usually isn’t worth the investment—unless you’re in the business of speed, like e-commerce, streaming, or other high-traffic services. Even then, there are often alternatives besides switching frameworks.

Finally, now that a lot of code is written by AI agents, I don’t think the framework choice matters. What really matters is keeping things like reusability, scalability, performance, and design patterns in mind.

It’s not about the framework, it’s about the solution.

That’s it—happy coding.

One Artwork, Seven Questions: Exploring the Art Institute API and Gemini

Jaime — Thu, 01 Jan 2026 19:00:00 +0000

New year, new project. As a fan of the Art Institute of Chicago, I just realized they have a public RESTful API and decided to build a simple web app: one piece of art a day and seven questions to learn more about the artwork.

This is how I built it:

1. Artist list

First, I asked GPT to provide a list of famous artists found at the Art Institute of Chicago. I’ll keep the list private so as not to spoil the artists you’ll find in the app.

2. Artwork

Second, I hit the /search endpoint to request one artwork from artist X. The endpoint is part of an Elasticsearch service, meaning it offers good tooling around filters. Here’s my query:

const query = {
  query: {
    bool: {
      must: [
        { term: { is_public_domain: true } },
        { term: { "artist_title.keyword": artist } },
        {
          match: {
            medium_display: { query: "Oil on canvas", fuzziness: "AUTO" },
          },
        },
      ],
    },
  },
};

There are three filters:

a) Public domain. This is very important to avoid copyright issues.

b) The artist’s name needs to match. There are a lot of artists and a lot of great works, but for now I’m interested in specific names.

c) I like oil on canvas, so I’m filtering by it, although this is more of a personal choice.

3. Quiz

Now that I have an artist’s name and one of their artworks (which could actually be found at the museum), the next step is to use AI to generate the questions. Here’s the prompt I’m using:

  Generate 7 quiz questions about the following artwork: ${artist} - ${artwork};
  use the following example questions as a guide: ${JSON.stringify(exampleQuestions)};
  the questions should be a mix of easy, intermediate, hard, and expert difficulty levels;
  each question should have 3 options labeled A, B, and C;
  provide the correct answer for each question;
  return the result as a JSON array of question objects with the following structure: { difficulty: string, question_number: number, question_text: string, options: { A: string, B: string, C: string }, correct_answer: string (A, B, or C) };
  only return the JSON array without any additional text;
  the questions should only be about the artwork

Then I pass the prompt to library @google/genai

import { GoogleGenAI } from "@google/genai";
const ai = new GoogleGenAI({});
const response = await ai.models.generateContent({
  model: "gemini-2.5-flash",
  contents: prompt,
});
const cleanJson = response.text.replace(/^```
{% endraw %}
json|
{% raw %}
```$/g, "").trim();
const questions = JSON.parse(cleanJson);

A couple of things to mention here:

a) You need a GEMINI_API_KEY; get one from Google.

b) I’m using the model gemini-2.5-flash, but it has some rate limitations. Not bad considering it’s free, but if you need to make more requests, you can try another model like gemma-3-12b-it, which allows more requests. Each model is trained differently, and at least for this simple case, I didn’t notice any significant difference.

c) One last thing: the agent usually returns something like this:

``json [
  {
    "image": "...",
    "quiz_title": "...",
    "questions": []
  }
}
``

So I had to remove the json prefix and then parse the rest of the string, which was the array of questions I was expecting.

4. Web app

Finally, I’m going with Next.js plus Copilot to build the UI. I wrote a bunch of prompts, but the idea was to:

Display the image found in the JSON
Show one question at a time
Keep score of correct answers
Once the quiz is finished, show a short summary

And that’s it. Please visit the quiz app and check out the codebase.

Happy 2026 coding!

Another ETL: Night Lift Tickets

Jaime — Mon, 22 Dec 2025 19:00:00 +0000

I live in Chicago, and one thing I like about the winter is having the chance to go snowboarding. I’m not very good at it, but I enjoy it. Usually, I would open multiple websites until I find a place to go. So every time I find myself doing a repetitive manual task—in this case, opening multiple websites with similar content for the same purpose—my brain goes directly to ETL.

And yes, there are already some catalog websites that show different hills around, but not the way I want. In my case, I’m interested in night lift tickets, because they have the best price, and I want to see the places on a map to find out how far they are from my place.

I wrote a couple of ETLs; they all have the same structure: Extract, Transform, and Load. In this case, Extract and Load are basically the same for all ETLs, which is why I put those functions in a common.js file, while the only custom part lives in Transform, which helps extract the price from the HTML using a CSS selector.

For this part, the HTML is passed to cheerio, which is a nice package that enables something similar to jQuery, making it easier to find elements in the HTML. Take a look at the following line:

const price = $($(".seasoncontainer.liftcontainer.clsDaynight.clsNight li")[2]);

Of course, if the CSS classes change on the site, then the scraper won’t work. This is one of the challenges of using this approach in ETLs. In production, you would have an alert to help you know whenever the price can’t be extracted. Or now, you could use AI—maybe Gemini—and try to extract the price using a model.

I went with a CSS selector because these sites rarely change their code.

const cheerio = require("cheerio");

const { extract, load, loggerInfo } = require("./common");

async function transform(html) {
  const $ = cheerio.load(html);

  const price = $(
    $(".seasoncontainer.liftcontainer.clsDaynight.clsNight li")[2]
  )
    .find("p")
    .text()
    .replace("$", "");

  return {
    price: parseInt(price),
  };
}

async function main() {
  const place = {
    id: "cascademountain",
    website: "https://www.cascademountain.com",
    name: "Cascade Mountain",
    lat: 43.502728,
    lng: -89.515996,
    gmaps: "https://maps.app.goo.gl/YWdnQvZiJZwPhj79A",
    url: `https://www.cascademountain.com/lift-tickets/`,
  };
  loggerInfo("etl start", { id: place.id });

  const html = await extract(place.url);
  const data = await transform(html);
  await load(place, data);

  loggerInfo("etl done", { id: place.id });
}

main().then(() => {});

The only dynamic property is price; the others are hardcoded. The thought is that prices change over time, but a business is either running or closed. The hardcoded values could be extracted using, maybe, Google Maps APIs, but considering that the number of places is limited, hardcoding them for now is fine. If my site gets real traffic, then I would consider writing a script to use Google Maps APIs and programmatically get a more comprehensive list of ski places.

The extract function simply makes a fetch request to the URL passed. There’s a variation in the codebase that uses puppeteer, because some sites don’t like scrapers.

async function extract(url) {
  loggerInfo("extracting", { url });

  const response = await fetch(url);
  const html = await response.text();
  return html;
}

The load function only saves the data in a json file. For now, a file is enough. At some point, this should be a database; I would go with DynamoDB because it’s cheap.

async function load(place, extraData) {
  const data = { ...place, ...extraData };
  loggerInfo("load", data);

  const filename = `public/sites/${data.id}.json`;
  await fs.writeFile(filename, JSON.stringify(data, null, 2));

  loggerInfo("saved", { filename });
}

loggerInfo is nothing more than a wrapper around console.log, which for now is enough. But in a production-like application, you could plug in something like New Relic or any other logging service.

const loggerInfo = (...args) => {
  console.log(...args);
};

Alright, so that’s the ETL. Now that I have the information, the rest is to build a website to show the places. I usually go with Next.js and then use Copilot to build it, so the prompt looks like this:

On this Next.js project, build a page with the following requirements:
- Only one page.
- The page should show a map using Google Maps.
- The map should show a marker for each place found in `all-places.json`, displaying the price.
- The page should have Google Analytics.
- The page should let the user click a marker and open a small card with the place information: name, link to Google Maps, and link to the `url` found in the JSON.
- The UI should be simple and use inline styles.

Something like that is a good starter. Of course, after that there would be some adjustments—some will be taken care of by it, and some by them.

And that’s it. Please visit the site and let me know what you think:

goofy

codebase

Happy coding.

P.S. Yes, I’m goofy.

Shai Hulud Scanner

Jaime — Sat, 29 Nov 2025 05:00:00 +0000

This week I spent some time looking for infected npm packages. Initially, the warning was to not install any package or run any AI agent, so I went ahead and created this Node.js script.

const scanForShaiHulud = (content) => {
  if (!content) return;

  const report = {
    total: 0,
    warning: [],
    infected: [],
  };

  Object.keys(content.packages).forEach((packageName) => {
    if (!packageName) {
      return;
    }

    let cleanedName = packageName.replace("node_modules/", "");
    if (cleanedName.includes("/node_modules/")) {
      cleanedName = cleanedName.split("/node_modules/")[1];
    }

    report.total += 1;

    if (infectedPackages[cleanedName]) {
      if (
        infectedPackages[cleanedName].includes(
          content.packages[packageName].version
        )
      ) {
        report.infected.push({
          name: cleanedName,
          version: content.packages[packageName].version,
          affectedVersions: infectedPackages[cleanedName],
        });
      } else {
        report.warning.push({
          name: cleanedName,
          version: content.packages[packageName].version,
          affectedVersions: infectedPackages[cleanedName],
        });
      }
    }
  });

  return report;
};

const fileContent = fs.readFileSync("./package-lock.json", "utf-8");
const parsedContent = JSON.parse(fileContent);
const report = scanForShaiHulud(parsedContent);
console.log(report);

Before this week, I knew that package-lock.json declared all the specific versions installed, but I hadn’t really spent time understanding the structure. Now I know that package-lock.json stores, in the key .packages, a map of all the packages installed in the repository—either as dependencies of the project or dependencies of dependencies. The point is that .packages holds a map with all the packages installed, so it can be used to check if any of the infected packages reported by wiz-sec-public matches the version.

The helper is pretty simple: it iterates over every single key found in .packages and checks it against the list passed.

At the end, the report shows if there’s any:

warning: package reported by Wiz as infected, but not the same version
infected: package reported by Wiz as infected, with a matching version

In the case of infected, you must remove that package; otherwise, whatever secrets are stored in your project locally could be exposed.

In the case of warning, I would do the same—remove the package—just to be safe. But if the version is lower than the one reported, in theory you shouldn’t be in trouble.

Feel free to download the shai-hulud-scanner to your Node.js project. Once you run it, you should see a report like this:

Hopefully everything is clear; otherwise take immediate action.

Additionally, you can visit this Shai-Hulud Scanner and upload a package-lock.json file. The same scanner function will run, and you can see the results in the browser.

Note: This post is meant for package-lock.json. If you are using yarn or pnpm, this won’t work because those package managers use different lock files. In any case, you should be able to adjust the logic a bit and make it work.

Luckily, we didn’t find any threats, proving that the Wiz list is comprehensive. I’m a big fan of open source—I believe in the power of community—but as with everything, there are risks too. Someone will always try to break the rules, which in some way pushes us to be more aware and spend more time on security. After this week, I’ve seen numerous packages for detecting this kind of threat, and that’s one of the perks of open source: code written by the people, for the people.

Happy coding.

Setting a Reverse Proxy with Nginx

Jaime — Mon, 27 Oct 2025 18:00:00 +0000

Last week, I needed to run a POC and wanted to use a reverse proxy so that the URLs looked clean during the demo. The demo was running locally, and I didn’t really need the reverse proxy — but since it was simple to set up, why not? So I’m leaving here the steps I followed.

1. Install `nginx`

I already had nginx installed, and I’m on macOS. If you don’t have it installed, you can use brew.

brew install nginx

2. `demo.conf`

I created a demo.conf file in this directory:

/opt/homebrew/etc/nginx/servers/demo.conf

That’s usually where Homebrew installs packages, and any file named *.conf will be read automatically by Nginx.

Nginx allows you to define a reverse proxy, which is a way to configure a server — in my case, demo.local — and then, based on the path, redirect the request to one location or another. For example, when I open http://demo.local, the request is served from http://127.0.0.1:3000/, which is a simple Next.js application. And whenever I open http://demo.local/coupons, the request is served from https://coupons.garitacenter.com/.

Notice the transparency: without knowing that there’s a reverse proxy, it would be hard to guess that we’re interacting with two different applications.

Here’s the Nginx configuration to route the requests:

# /opt/homebrew/etc/nginx/servers/demo.conf
server {
    listen 80;
    server_name demo.local;

    location /coupons {
        proxy_pass https://coupons.garitacenter.com/;
        proxy_set_header Host coupons.garitacenter.com;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_server_name on;
    }

    location / {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

As you can see, it listens on port 80 and assigns the server_name to demo.local. Then, based on the path (/coupons vs /), it redirects the request to one place or another.

Any change made to this file requires Nginx to be restarted.

brew services restart nginx

3. Update `hosts`

Additionally, I needed to update my hosts configuration file so that demo.local points to my localhost.

# /etc/hosts
127.0.0.1       demo.local

Changes here are picked up automatically by the machine, so as soon as the file is modified, you can start using demo.local.

In the following image, notice how http://demo.local/nginx-reverse-proxy and http://localhost:3000/nginx-reverse-proxy render the same content.

Now let’s take a look at the other location:

Browsers nowadays, by default, try to use https, which means the above instructions might work in incognito mode, but in a regular session you might see a “Your connection is not private” message.

Certificates

4. Install `mkcert`

brew install mkcert nss

5. Create certificates

mkcert -install

mkcert -cert-file /opt/homebrew/etc/nginx/certs/demo.local.pem -key-file /opt/homebrew/etc/nginx/certs/demo.local-key.pem demo.local localhost 127.0.0.1

Note: If you need to use sudo to create the certificates, make sure to change the owner of the files to your regular user afterwards.

ls -la /opt/homebrew/etc/nginx/certs/

-rw-------@  1 myuser  admin  1708 Oct 19 14:26 demo.local-key.pem
-rw-r--r--@  1 myuser  admin  1562 Oct 19 14:26 demo.local.pem

6. Update `demo.conf`

server {
    listen 80;
    server_name local.media.patientpoint.io;

    # Redirect HTTP to HTTPS
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl;
    server_name demo.local;

    ssl_certificate /opt/homebrew/etc/nginx/certs/demo.local.pem;
    ssl_certificate_key /opt/homebrew/etc/nginx/certs/demo.local-key.pem;

    location /coupons {
        proxy_pass https://coupons.garitacenter.com/;
        proxy_set_header Host coupons.garitacenter.com;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_ssl_server_name on;
    }

    location / {
        proxy_pass http://127.0.0.1:3000/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

7. Restart Nginx

brew services restart nginx

You should see output like this:

$ brew services restart nginx

Stopping `nginx`... (might take a while)
==> Successfully stopped `nginx` (label: homebrew.mxcl.nginx)
==> Successfully started `nginx` (label: homebrew.mxcl.nginx)

If everything went well, you can now try the URL again, and the browser shouldn’t complain about security:

How to debug

If you face any issues, you can check the Nginx logs:

Error logs:

tail -f /opt/homebrew/var/log/nginx/error.log

Access logs:

tail -f /opt/homebrew/var/log/nginx/access.log

These two files should give a good indication of what’s going on. Sometimes it’s a permission issue (e.g., the certificates are owned by admin), or they might not be found because of a wrong path, or the request might be missing some headers. In any case, when facing an error, these two logs are where you’ll find the root cause.

Summary

This is a simple example of how to use nginx as a reverse proxy on a local machine. Now, two different web applications can be accessed through a custom URL, and based on the path — either root / or /coupons — the responses come from different servers.

Although this setup is running locally, the concept applies in production. In many cases, a proxy will sit in front of our services. Of course, in production you would put more effort into security, caching, and possibly work with a vendor like AWS, but the concept remains the same.

Nextjs Todo Application Using Mysql and Terraform

Jaime — Mon, 29 Sep 2025 18:00:00 +0000

Hi, here’s another Todo application in React. Nothing exceptional compared to other examples, but I’ll focus more on hosting the database in AWS and using Terraform for deployment.

Take a look at the Demo and Codebase.

Front-End Architecture

The application can perform six main functions:

Add Todos
Edit a Single Todo
Delete a Single Todo
Get all Todos
Delete all Todos

As a good practice for client applications, all user interactions are first stored in the browser — in this case, in a React state variable — and then synced with the database in the background.

The downside of this approach is the risk of a race condition. For example, if the user closes the browser before the todo is saved in the database, the information will be lost. The upside is that the user doesn’t need to wait for backend confirmation, which makes the app feel more responsive. And since users typically don’t close the app immediately, this trade-off works fine for most cases.

For this demo, the goal is not to cover 100% of scenarios but to show the overall approach.

Snippets

In the codebase you will find things like this:

const newTodos = textareaValue
  .split("\n")
  .filter((line) => line.trim() !== "")
  .map((line, index) => ({
    id: Date.now() + index,
    text: line.trim().toLocaleLowerCase(),
    done: false,
  }));

setTodos(newTodos);

await addTodosToDB(newTodos);

Notice how the React state variable todos is updated. This triggers a change in the UI, allowing the user to see the new todos in the list. Meanwhile, in the background, await addTodosToDB(newTodos) is executed to save the todos in the database.

Let’s take a look at the function addTodosToDB:

"use server";

...

export async function addTodosToDB(
  todos: { id: number, text: string, done: boolean }[]
) {
  const values = todos.map((todo) => [todo.id, todo.text, todo.done, LIST]);
  await db.query("INSERT INTO todos (id, text, done, list) VALUES ?", [values]);
}

Here, you’ll notice "use server"; at the top of the file. This tells Next.js that the file should be executed on the server as a server action.

Since the code runs on the server, it’s fine to interact directly with the database—for example, with a raw MySQL insert query.

In a production application, you’ll usually want to use an ORM when working with a database. ORM packages typically provide features such as migrations, validation, schemas, and more.

I won’t go into the rest of the code since it’s fairly self-explanatory. Also, most of it was generated with the help of an AI agent. Here are some of the prompts I used:

Create a react component for a todo list application that allows users to add, edit, delete, and mark todos as done. The todos should be fetched from a database, and changes should be synced back to the database. Include a textarea for bulk adding todos and a reset button to clear the list.

Add functionality to a todo list component where pressing 'enter' adds a new todo, 'shift + enter' allows multiline input, and 'escape' clears the textarea. Include buttons for toggling the 'done' state, editing todos inline, and deleting todos. Ensure the UI updates dynamically and is synced with a backend database. Style the component with inline styles for a clean and modern look.

Terraform (Database)

This is the part I’m most interested in. As a web developer, it’s pretty easy to build a web application—especially now with AI agents—but deploying it is not always as straightforward. There are some cool services that let you host applications for free, and I definitely recommend them. However, in most work environments you’ll run into AWS, especially for databases.

The following steps will create a MySQL database in AWS and add a network so the database can be accessed from the application.

Here’s what you’ll need:

An AWS account (credit card required)
Access Keys, which consist of a Key ID and a Secret Access Key

Terraform installed

These first three steps might take a bit of time, but once you have them, the next step is:

AWS Profile

Not required, but it’s a good way to manage your credentials in your local environment.

$ aws configure --profile todo-profile

AWS Access Key ID [****************]: ****************
AWS Secret Access Key [****************]: ****************
Default region name [None]:
Default output format [None]:

Environment Variables

You’ll need to export the following variables in your terminal:

export TF_VAR_mysql_database="*****"
export TF_VAR_mysql_user=*****
export TF_VAR_mysql_pwd="*****"

Note: The values are whatever string you want.

In the Terraform rds file, these variables are used like this:

db_name                 = var.mysql_database  # Pull from environment variable
username                = var.mysql_user
password                = var.mysql_pwd

Terraform automatically picks up any environment variable that’s prefixed with TF_VAR_ and will map these to the corresponding variables defined in your variables.tf file.

Init

$ terraform init

Initializing the backend...
Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Reusing previous version of hashicorp/null from the dependency lock file
- Using previously-installed hashicorp/aws v6.13.0
- Using previously-installed hashicorp/null v3.2.4

Terraform has been successfully initialized!

...

Plan

$ terraform plan

data.aws_availability_zones.available: Reading...
data.aws_availability_zones.available: Read complete after 0s [id=us-east-1]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_db_instance.todo_db will be created
  + resource "aws_db_instance" "todo_db" {
      + address                               = (known after apply)
      + allocated_storage                     = 20
...

Plan: 12 to add, 0 to change, 0 to destroy.

Apply

terraform apply
data.aws_availability_zones.available: Reading...

...

Plan: 12 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

aws_vpc.todo_vpc: Creating...
aws_vpc.todo_vpc: Still creating... [10s elapsed]
aws_vpc.todo_vpc: Creation complete after 11s [id=vpc-095daafd54946d1c0]

...

null_resource.init_db (local-exec): host: *****

...

Apply complete! Resources: 12 added, 0 changed, 0 destroyed.

Notice the line above that shows the host URL:

null_resource.init_db (local-exec): host: *****

This is important because the application will need it. You can also use it to connect directly to your database.

Just type your password when prompted, and you should be inside AWS.

mysql -h [host] -P 3306 -u [user] -p
Enter password:
Welcome to the MySQL monitor.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| todo_database      |
+--------------------+

mysql> use todo_database;
Database changed

mysql> show tables;
+-------------------------+
| Tables_in_todo_database |
+-------------------------+
| todos                   |
+-------------------------+

Perfect! You can also view your MySQL database in the AWS UI.

Webapp Database Credentials

This is how the application receives its credentials:

const db = mysql.createPool({
  host: process.env.TF_VAR_mysql_host,
  user: process.env.TF_VAR_mysql_user,
  password: process.env.TF_VAR_mysql_pwd,
  database: process.env.TF_VAR_mysql_database,
});

I added one extra variable, TF_VAR_mysql_host, whose value you get after applying the Terraform scripts.

Costs

Using AWS is usually not free. Here’s the cost of running this small database for almost a month:

The Virtual Private Cloud (VPC) provides access via HTTP to the database, which is necessary for connecting the web application to it.

One nice thing about using Terraform is that you can remove everything from AWS just by running:

$ terraform destroy

data.aws_availability_zones.available: Reading...
...

Plan: 0 to add, 0 to change, 12 to destroy.

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

null_resource.init_db: Destroying... [id=5959882105264964999]
...

Destroy complete! Resources: 12 destroyed.

By destroying everything, you stop AWS from charging you—especially if it’s just for testing. When working for a company, it’s also a good practice to remove unused resources to reduce costs.

Final Thoughts

As a web developer, at some point you’ll likely need a database. In a work environment, this usually means setting one up in AWS. Feel free to experiment with the demo: the Next.js application has both a client side and a server side. The server side (server actions) is integrated directly with the MySQL database hosted in AWS.

NextAuth.js: An easy way to add authentication to your Next.js project

Jaime — Mon, 09 Jun 2025 19:25:51 +0000

Recently, I needed to add session management to a Next.js project and came across NextAuth.js. It’s a pretty solid library that simplifies login, logout, and session handling.

Here are the steps I followed:

1. API Auth Route Handler

First, create the following file:

api/auth/[...nextauth]/route.ts

And add this content: (you can customize it based on your provider and config needs)

import NextAuth from "next-auth";
import CredentialsProvider from "next-auth/providers/credentials";

type UserToken = { id: string; name: string; email: string };

const handler = NextAuth({
  providers: [
    CredentialsProvider({
      name: "Credentials",
      credentials: {
        username: { label: "Username", type: "text", placeholder: "admin" },
        password: {
          label: "Password",
          type: "password",
          placeholder: "1234",
        },
      },
      async authorize(credentials, req) {
        return { id: "1", name: "Admin", email: "admin@example.com" };
      },
    }),
  ],
  secret: process.env.NEXTAUTH_SECRET,
  callbacks: {
    async jwt({ token, user }) {
      if (user) {
        token.user = user;
      }
      return token;
    },
    async session({ session, token }) {
      session.user = token.user as UserToken;
      return session;
    },
  },
});

export { handler as GET, handler as POST };

This is the main configuration file, and it defines a few key things:

Provider

NextAuth.js supports multiple providers. For this simple demo, I’m using Credentials, which is super handy when you already have a login system in place. It basically lets you plug directly into your existing auth service.

authorize

This function is where you hook into your internal login service. If it returns an object, NextAuth.js treats it as a successful login and creates a session. If you return null, it means login failed.

Note: providers is an array—so you can support multiple login methods, like Credentials (custom login), Google, GitHub, etc.

This callback attaches the user data returned by authorize to the token. You can include whatever you want inside the token here. That token will later be used to build the session.

session

This is where the session is created using the token. You’ll see how the user info gets added to the session object. This is what your app can access using the useSession() hook on the client side.

For this demo, I’m not calling any real auth service. Just passing a user and password is enough to simulate a session. But in a real-world scenario, you’d call your actual login API inside authorize, and then return the user object (or null on failure).

2. UI Updates

Now that the provider setup is done, the next step is to implement the UI components. In this case, I only have two components:

Page

A very simple page that uses 'use client' (required for client-side hooks like useSession) and wraps everything in SessionProvider:

"use client";

import { SessionProvider } from "next-auth/react";

import LoginButton from "./login-btn";

export default function Page() {
  return (
    <SessionProvider>
      <LoginButton />
    </SessionProvider>
  );
}

Note: The LoginButton component uses useSession, so it needs to be inside a SessionProvider.

LoginButton

A very simple LoginButton component that uses useSession to either show a Sign In or Sign Out button depending on the session state:

import { useSession, signIn, signOut } from "next-auth/react";

export default function Component() {
  const { data: session } = useSession();

  if (session) {
    return (
      <div>
        <p>
          Signed in as <strong>{session.user.name}</strong>
        </p>
        <button onClick={() => signOut()}>Sign out</button>
      </div>
    );
  }

  return (
    <div>
      <p>Not signed in</p>
      <button onClick={() => signIn()}>Sign in</button>
    </div>
  );
}

And that’s it—you’ve got a simple login system in place using NextAuth.js

Demo

Make sure to check out the Website and take a look at the Codebase.

Thanks for reading!

How JavaScript helped me find a Car

Jaime — Mon, 12 May 2025 17:00:00 +0000

I'm looking for a Jetta, and of course, I want to make sure I get the best option. Instead of manually checking car dealers' websites, I'm writing ETLs to collect car data, save it as JSON, and use a Next.js app to display the results.

Architecture

I'm going to write one ETL (Extract, Transform, Load) per website (source).

Extract

This step involves opening the website and retrieving the data. Sometimes it's in HTML, sometimes in JSON.

Transform

I'm interested in the following properties:

title
price
year
link
vin
mileage

Each website may have a different structure, but the goal is to extract these values.

Load

For this demo, I'm keeping it simple by saving a JSON file per site. In a real-world setup, the data would be stored in a database.

Aggregator

This script will combine all the JSON files into a single one, simulating what a database would do in a real example.

Next.js

A basic web app to display the data in a table-like format with simple filters.

Example

Let's take a look at the following dealer's website:

Notice how the website displays the properties I'm interested in. Fortunately, at the time of writing, this site returns a JSON response, which makes it easy to traverse and extract car data. The ETL looks like this:

const fs = require("fs");

const extract = async (url) => {
  const response = await fetch(url);

  return await response.json();
};

const transform = (data) => {
  return data.DisplayCards.map((VehicleCard) => {
    return {
      title: VehicleCard.VehicleName,
      price: VehicleCard.VehicleInternetPrice,
      year: VehicleCard.VehicleYear,
      link: VehicleCard.VehicleDetailUrl,
      vin: VehicleCard.VehicleVin,
      mileage: VehicleCard.Mileage,
    };
  });
};

const load = (cars, name) => {
  fs.writeFileSync(`./_sites/${name}.json`, JSON.stringify(cars));
};

const main = async () => {
  const site = {
    url: "https://www.vwoaklawn.com/api/vhcliaa/vehicle-pages/cosmos/srp/vehicles/25795/2631261?st=Price+asc&Make=Volkswagen&mileagerange=0-50000&host=www.vwoaklawn.com&baseFilter=dHlwZT0ndSc=&displayCardsShown=NaN",
  };

  const data = await extract(site.url);

  const cars = transform(data);

  load(cars, "vwoaklawn");
};

Site_A.json

After running the ETL, I’ll get a JSON file like this:

[
    {
        "title": "Volkswagen Jetta 1.4T SE",
        "price": 19640,
        "year": 2021,
        "link": "https://www.cityvwofchicago.com/inventory/certified-used-2021-volkswagen-jetta-1-4t-se-fwd-4d-sedan-3vwc57bu4mm003393/",
        "vin": "3VWC57BU4MM003393",
        "mileage": 27203
    },
    ...
]

Aggregator

This helper combines all the Site_N.json files into a single cars.json file, which will be used by the web application.

Next.js

A simple web app that displays cars.json. The page looks like this:

Demo

Make sure to check out the Website and take a look at the Codebase.

So now, I know which Jetta to get 🤓

Thanks for reading!

Disclaimer: I'm not sponsored in any way—just genuinely trying to find the best 🚗.

How to Connect Your Next.js React Application to Redis

Jaime — Mon, 21 Apr 2025 17:00:00 +0000

Recently, I had to add Redis to a React application running on Next.js using server actions. Here are the important pieces.

1. Select an npm package

I went with ioredis. At the time of writing, it had 7 million downloads, and after opening their repo, the last commit was from two days ago. This means the project is active.

npm i ioredis

2. Initialize a redis client

const redis = new Redis(process.env.REDIS_CONNECTION_STRING);

If another team takes care of the infrastructure they will provide a "connection string", that looks something like this:

rediss://[user]:[password]@[host]:[port]

For this demo I'm using Aiven, they offer a 1GB free account, which is more than enough for a POC or prototype.

3. Read from Redis

In the previous step, if all went well: valid credentials, Redis server running, correct configurations; a Redis client instance should have been created. This means reading is as easy as running the following lines:

export async function readFromRedis() {
  try {
    const value = await redis.get("name");
    return value;
  } catch (error) {
    console.error("Error reading from Redis:", error);
    return "";
  }
}

Note: In my case, name is the key I'll use to save data into Redis.

4. Write to Redis

export async function writeToRedis(name: string): Promise<void> {
  try {
    await redis.set("name", name);
  } catch (error) {
    console.error("Error writing to Redis:", error);
  }
}

Notice how the key is name

5. Ensure helpers are run on the server

Is important to run these helpers in the server so the credentials are not exposed in the browser. Make sure to use "use server";. Take a look at the example.

Notice how I'm using an environment variable to store the Redis connection string: process.env.REDIS_CONNECTION_STRING. This information is sensitive and shouldn't be exposed in the browser.

This adds an extra jump from the browser to your server to the Redis server, but it is a secure way. There's an alternative to securely connect from the browser, but I would probably still go with a server function.

6. Finally, plug the methods into your React application.

const [inputValue, setInputValue] = useState("");
const [name, setName] = useState("");

const handleButtonClick = async () => {
  await writeToRedis(inputValue);
  setInputValue("");
  await fetchName();
};

const fetchName = async () => {
  const nameFromRedis = await readFromRedis();
  setName(nameFromRedis);
};

useEffect(() => {
  fetchName();
}, []);

Take a look at the full component.

Demo

Make sure to take a look at the demo page

Conclusion

Adding Redis is pretty straightforward, especially if you have a team that takes care of the infrastructure. If not, you might need to spend a bit of time with AWS or any other provider, making sure you set up the Redis server properly and follow secure guidelines.

Once the Redis server is set up, plugging it into your React application is just about selecting an npm package that works for you. These packages do the heavy lifting and provide helpers to write and read, which is what you will need most of the time.

Thanks for reading.

How to Set Up a Node.js Web Server on Raspberry Pi

Jaime — Mon, 20 Jan 2025 18:00:00 +0000

A couple of years ago, I bought a Raspberry Pi Model B+, and I finally decided to set up a web server on it.

This might sound obvious, but I now understand that a Raspberry Pi is essentially a mini PC, which means it requires an operating system (OS) to function. This is different from other boards, like Arduino, where you can just run your program without needing to install an OS.

Here are the steps to set up a Node.js web server on a Raspberry Pi from scratch:

1. Install `Raspberry Pi Imager`

Imager will help you install Raspberry Pi OS onto a microSD card.

While there are other OS options like Debian, Ubuntu, etc., Raspberry Pi recommends using the official Raspberry Pi OS for the best experience with their boards.

2. Install `Raspberry Pi OS`

Open Raspberry Pi Imager and select:

Raspberry Pi Device: Select your model.
Operating System: Choose the recommended option.
Storage: Select your microSD card.

I went with the default settings, and once it finished, it showed this message:

3. Insert the microSD card: Place it into your Raspberry Pi board.

Along with the microSD card, connect any other peripherals, such as:

Mouse
Keyboard
Monitor
Ethernet cable
Power cable (it's recommended to plug this in last).

It's recommended to plug in the power cable last. Notice that the microSD card is inserted on the opposite side of the board.

Once Raspberry Pi OS boots up, you'll see the desktop welcome message, which should look something like this:

Finally, you'll see the desktop environment, which looks like this:

This means your Raspberry Pi OS is ready to use.

Install Updates

Once your board is turned on, it will take some time (in my case, about 2 minutes) to boot up and display the desktop UI. Once it's ready, open the terminal and run the following commands:

Update your system packages

sudo apt-get update -y

Update installed packages

sudo apt-get dist-upgrade -y

Install `Nodejs`

sudo apt-get install nodejs -y

Let's install npm as well

sudo apt-get install npm -y

$ node -v
v18.19.0

$ npm -v
9.2.0

Install `Express`

Express is an npm package that lets you easily run a web server. I used their generator and stuck with the default options.

npx express-generator

Say yes to the default settings

Install npm packages

npm install

Run the Server

npm start

By default, the web server runs on PORT 3000. To access it from another machine, you just need the Raspberry Pi's IP address. For instance, my Raspberry Pi's IP is 192.168.100.239, but yours will likely be different.

Open the Web Server on Another Machine

Go to your regular machine, open the browser, and paste the IP and PORT (e.g., http://192.168.1.239:3000) in the address bar. You should see something like this:

http://192.168.100.239:3000/

If everything is set up correctly, your Express app will now be accessible from any device on the same network.

In my case, since I'm using the Raspberry Pi B+ board, the RAM and CPU aren't as powerful, so it took a bit of time to run each command. It’s normal for lower-spec devices like this to take longer for tasks like installing dependencies or starting the server.

Conclusion

The Raspberry Pi is essentially a mini PC, offering seamless integration with IoT devices. You can connect sensors or just about any electronic gadget to the board.

While the Model B+ isn't the most powerful option, there are more advanced boards available now, and it's safe to assume the Raspberry Pi team will keep enhancing their devices in the future.

Extra

Initially, I wanted to run Next.js on the Raspberry Pi, but I encountered the following error:

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
Aborted

So, I ultimately decided to switch to Express. Remember, this is an older board with limited resources. Modern boards should have more power. The cool part is that, since it runs a Linux OS, you can install pretty much any package.

React 19: New API use(promise)

Jaime — Mon, 13 Jan 2025 18:00:00 +0000

In this post, I’ll demo how to read a value from a promise using use.

Snippet

Let’s check out the following code:

import { Suspense } from "react";

export default function Page() {
  const messagePromise = fetchMessages();

  return (
    <Suspense fallback={<p>⌛ waiting for messages...</p>}>
      <Message messagePromise={messagePromise} />
    </Suspense>
  );
}

A couple of things to note:

<Suspense /> is being used, which basically displays the fallback, in this case: ⌛ waiting for messages..., until the promise is resolved.
messagePromise is a promise passed as a prop to <Message />.

Now, let’s take a look at fetchMessages:

async function fetchMessages() {
  return [
    {
      id: 1,
      text: "message 1",
    },
    {
      id: 2,
      text: "message 2",
    },
  ];
}

As you can see, it’s a very simple function. In a real world example, this could be a fetch request, but for simplicity, the function just returns an array. By using async, JavaScript automatically knows that the function returns a promise.

Finally, let’s check out the <Message> component:

function Message({ messagePromise }) {
  const comments = use(messagePromise);

  return comments.map((comment) => <p key={comment.id}>{comment.text}</p>);
}

This is where it gets interesting. The <Message> component receives messagePromise as a prop, which, as we mentioned, is a promise.

Usually, you’d use await with a promise, but in React 19, you can now use use to achieve basically the same result.

One key difference between await and use is that await blocks rendering until the promise is resolved, whereas use doesn’t block rendering.

Here’s how the component looks before the promise is resolved:

And once the promise is resolved:

Conclusion

use works similarly to await, and if the application is running on a server using SSR, the result is exactly the same: the server will return the same HTML response in both cases.

However, if the code runs on the client, rendering behaves a bit differently. await blocks rendering until the promise is resolved, while use allows the component to re-render once the promise is resolved.

Forem: Jaime

NER: Gemini vs Spacy vs Compromise

TLDR

Intro

Gemini

Spacy

compromise

Conclusion

Moving from Nextjs to Qwik

Network

Lighthouse

Performance

Metrics

Diagnostics

Coding

Components

State variables and clicks

Fetching data

Summary

One Artwork, Seven Questions: Exploring the Art Institute API and Gemini

1. Artist list

2. Artwork

3. Quiz

4. Web app

Another ETL: Night Lift Tickets

Shai Hulud Scanner

Setting a Reverse Proxy with Nginx

1. Install nginx

2. demo.conf

3. Update hosts

Certificates

4. Install mkcert

5. Create certificates

6. Update demo.conf

7. Restart Nginx

How to debug

Summary

Nextjs Todo Application Using Mysql and Terraform

Front-End Architecture

Snippets

Terraform (Database)

Webapp Database Credentials

Costs

Final Thoughts

NextAuth.js: An easy way to add authentication to your Next.js project

1. API Auth Route Handler

2. UI Updates

Demo

How JavaScript helped me find a Car

Architecture

Extract

Transform

Load

Aggregator

Next.js

Example

Site_A.json

Aggregator

Next.js

Demo

How to Connect Your Next.js React Application to Redis

Demo

Conclusion

How to Set Up a Node.js Web Server on Raspberry Pi

1. Install Raspberry Pi Imager

2. Install Raspberry Pi OS

3. Insert the microSD card: Place it into your Raspberry Pi board.

Install Updates

Install Nodejs

Install Express

Install npm packages

Run the Server

Open the Web Server on Another Machine

Conclusion

Extra

React 19: New API use(promise)

Links

Snippet

Conclusion

1. Install `nginx`

2. `demo.conf`

3. Update `hosts`

4. Install `mkcert`

6. Update `demo.conf`

1. Install `Raspberry Pi Imager`

2. Install `Raspberry Pi OS`

Install `Nodejs`

Install `Express`