DEV Community: CertosinoLab

Building AI Prompt Lab with Java 21, Spring Boot and React 19

CertosinoLab — Sun, 16 Aug 2026 23:20:00 +0000

AI Prompt Lab is a full-stack application I built around a simple idea: managing reusable AI prompts should feel like working with any other structured application asset, rather than keeping them scattered across notes, text files or chat histories.

The project combines Java 21, Spring Boot, React 19, TypeScript, PostgreSQL and OpenRouter in a compact architecture that covers the main concerns of a modern web application: authentication, authorization, persistence, external API integration and management of sensitive configuration.

I deliberately kept the system relatively simple. The goal was not to introduce architectural patterns for their own sake, but to build a clean application where each technology has a clear responsibility.

The project

AI Prompt Lab provides an authenticated workspace where users can create, update, organize and reuse prompts for generative AI models.

Each user has an independent prompt collection and can configure an OpenRouter account to interact with different language models through the application.

At a high level, the application provides:

user authentication;
role-based authorization;
personal prompt management;
OpenRouter configuration;
AI chat functionality;
encrypted storage of external API credentials;
administrative user management.

From an architectural point of view, this makes the project more interesting than a conventional CRUD application while still remaining small enough to keep the overall design easy to reason about.

Technology stack

The repository is divided into two independent applications:

backend/
frontend/

Backend

Java 21
Spring Boot
Spring Web
Spring Data JPA
Spring Security
PostgreSQL
Flyway
OpenRouter API

Frontend

React 19
TypeScript
Vite
React Router
React Context

The stack is intentionally conventional.

There is no microservice decomposition, no external state management library on the frontend and no additional infrastructure that the application does not currently require.

For this scope, keeping the system as a modular monolith provides a much better balance between maintainability, deployment complexity and development speed.

Backend architecture

The Spring Boot application follows a traditional layered structure:

controller
service
repository
model
config

The separation is straightforward.

Controllers define the HTTP API, services contain application logic, repositories encapsulate persistence, and configuration components handle cross-cutting concerns such as security and encryption.

I prefer this approach for an application of this size because the control flow remains explicit. A request enters through a controller, moves through the service layer and reaches the persistence layer without introducing unnecessary indirection.

Prompt management

Prompt management is the central domain of the application.

Authenticated users can create, edit, delete and retrieve prompts associated with their account.

The backend also supports sorting directly at the repository level, keeping data-oriented operations close to the persistence layer instead of reimplementing them in the client.

The result is a small REST API with predictable resource-oriented operations and a clean separation between client-side presentation and server-side data access.

Authentication and authorization

Authentication is handled entirely by Spring Security.

Passwords are persisted using BCrypt hashing, while authenticated sessions are represented by a server-issued token stored in an HTTP-only cookie.

The browser sends the cookie automatically with subsequent requests, and a custom Spring Security filter restores the authenticated user before the request reaches the application layer.

The flow is essentially:

Login request
      |
      v
Credential verification
      |
      v
Session token creation
      |
      v
HTTP-only cookie
      |
      v
Spring Security filter
      |
      v
Authenticated request

Authorization is enforced on the backend rather than being delegated to the user interface.

The application distinguishes between regular users and administrators, and administrative endpoints are protected through Spring Security.

The frontend can therefore use roles to adapt navigation and presentation, while the server remains the authoritative boundary for access control.

PostgreSQL and schema management

PostgreSQL provides the persistence layer, with Spring Data JPA handling repository access and entity mapping.

Schema evolution is managed through Flyway migrations.

I prefer keeping database changes explicit and versioned alongside the application rather than depending on automatic schema mutation at runtime.

This gives the database the same kind of traceability as the rest of the codebase:

V1__init_database.sql
V2__future_change.sql
V3__another_change.sql

It also makes the application easier to move between environments because schema creation and evolution are part of a repeatable process rather than a manual deployment step.

OpenRouter integration

AI requests are handled by the backend rather than being sent directly from React to the external provider.

The frontend sends the conversation to the Spring Boot API, the backend loads the current user's AI configuration and then performs the request to OpenRouter.

React
  |
  v
Spring Boot API
  |
  v
User AI configuration
  |
  v
OpenRouter
  |
  v
Language model
  |
  v
Response returned to React

This boundary keeps provider-specific behavior outside the frontend and gives the backend control over authentication headers, request construction and external API communication.

It also leaves room for future extensions.

OpenRouter could eventually become one implementation behind a generic AI provider interface without requiring significant changes to the UI.

Handling external API credentials

Allowing users to configure OpenRouter introduces a security requirement that is not present in a basic CRUD flow: third-party credentials have to be persisted without treating them as ordinary application data.

The project encrypts API keys before storing them in PostgreSQL using AES in GCM mode.

The backend decrypts the value only when it needs to issue a request to the external provider.

Conceptually:

OpenRouter API key
       |
       v
AES-GCM encryption
       |
       v
Encrypted database value
       |
       v
Backend decryption
       |
       v
External API request

Keeping this responsibility on the server also prevents provider credentials from becoming part of the React application configuration.

The React frontend

The frontend is implemented with React 19 and TypeScript and built with Vite.

The source tree is organized around a small set of responsibilities:

components/
pages/
context/
services/
types/

React Router handles navigation, while React Context is used for the authenticated user state.

For the current size of the application, Context is sufficient. Introducing a larger state management solution would add an additional abstraction without solving a concrete problem.

Most application state remains local to the page or component that owns it, while only genuinely shared state is lifted into the authentication context.

A dedicated API layer

HTTP communication is centralized in a dedicated frontend service instead of being spread across individual components.

That layer exposes operations for:

authentication;
prompt CRUD operations;
AI configuration;
chat requests;
administrative user management.

This keeps React components focused on rendering and interaction while request construction, credentials and common response handling remain in one place.

It also creates a useful boundary if the backend API changes later: most HTTP-level changes can be isolated inside the service layer rather than propagated across the entire UI.

The chat flow

The chat page is where most parts of the system converge.

A user can work with a saved prompt, provide additional context and send a conversation to the configured language model.

React manages the interaction and conversation state, Spring Boot performs the authenticated server-side operation, PostgreSQL provides the user-specific configuration, and OpenRouter handles the model request.

The resulting flow is:

Prompt
  +
User message
  |
  v
React chat interface
  |
  v
Spring Boot
  |
  v
OpenRouter
  |
  v
AI model response
  |
  v
React chat interface

This is probably the part of the project that best represents the overall architecture because it crosses every major boundary of the application without coupling those layers together.

Why I kept the architecture simple

One of the main design decisions behind AI Prompt Lab was to avoid solving problems the application does not have.

The backend is a single Spring Boot application because there is currently no domain or operational requirement that would justify distributing the system across multiple services.

The frontend does not use Redux because authentication is the only significant global state and React Context already covers that requirement.

The data model remains relational because the application's entities and ownership relationships map naturally to PostgreSQL.

This is a principle I tend to apply regardless of the technology stack: introduce abstraction when it removes meaningful complexity, not simply because the abstraction exists.

A relatively small system with explicit boundaries is often easier to evolve than an over-engineered system whose infrastructure is more complex than its domain.

Possible extensions

The current architecture leaves several natural directions for future development.

Prompt categories and tags

Prompts could be grouped by domain, purpose or workflow, making larger collections easier to manage.

Prompt versioning

Instead of replacing prompt content on every update, previous versions could be preserved and compared.

Streaming responses

The chat API could move from request-response communication to Server-Sent Events or another streaming mechanism so generated content appears progressively in the UI.

Multiple AI providers

An internal provider abstraction could support OpenRouter, OpenAI, Anthropic or locally hosted models behind a common application interface.

Conversation persistence

Chat sessions could be stored and reopened instead of existing only for the duration of the current frontend session.

Usage metrics

The backend could collect token usage, request latency and estimated cost per model, turning the application into a more complete prompt experimentation environment.

Conclusion

AI Prompt Lab is a compact full-stack application that brings together several concerns that usually appear in real-world systems: persistence, authentication, authorization, secret handling, external HTTP integrations and a typed frontend.

The backend uses Java 21 and Spring Boot to provide the application and security layer, PostgreSQL manages persistent state, React 19 and TypeScript provide the user interface, and OpenRouter connects the application to different language models.

The project is intentionally not built around architectural novelty.

Its design is based on keeping responsibilities explicit and introducing complexity only where the requirements justify it.

For me, that is what makes the project interesting: frontend, backend, persistence, security and AI integration are treated as parts of the same system, while each layer remains responsible for a clearly defined concern.

Source Code

The complete source code is available on GitHub:

Java21_React19_AIPromptLab on GitHub

Originally published on CertosinoLab.

Next.js + NestJS: Useful Architecture or Unnecessary Complexity?

CertosinoLab — Thu, 13 Aug 2026 12:06:48 +0000

Next.js and NestJS are often compared as if you have to choose one.

But that comparison is slightly misleading.

Next.js is primarily a React framework that can also handle server-side logic, API endpoints, authentication, database access, and other backend tasks.

NestJS, on the other hand, is a dedicated backend framework built around modules, dependency injection, controllers, services, queues, WebSockets, microservices, and structured application architecture.

So the more interesting question isn't:

Next.js or NestJS?

It's:

When does a Next.js application actually need a separate NestJS backend?

For many applications, the answer is: it doesn't.

Start with Next.js alone

Imagine you're building a small SaaS application.

You have:

a React frontend
authentication
a database
a few API endpoints
payments
some server-side business logic

Next.js can already handle this architecture quite well.

For example, an API endpoint can live directly inside the application:

export async function GET() {
  const users = await db.user.findMany();

  return Response.json(users);
}

Your architecture stays simple:

Browser
   ↓
Next.js
   ↓
Database

There is only one application to deploy, monitor and maintain.

For small and medium-sized projects, this simplicity is a major advantage.

Adding NestJS at this stage might simply create another network boundary:

Browser
   ↓
Next.js
   ↓
NestJS
   ↓
Database

Now you have two applications, two deployment processes and an HTTP call between code that could have lived in the same process.

That isn't automatically an improvement.

So when does NestJS start to make sense?

The answer usually has less to do with the number of API endpoints and more to do with backend complexity.

Suppose your application starts doing more than serving requests from your Next.js frontend.

You now have:

Next.js frontend
        ↓
      API
   ↙    ↓    ↘
Mobile  Jobs  Integrations
 App          External clients

At this point, your backend is becoming a product of its own.

That's where NestJS becomes much more interesting.

Case 1: Multiple clients use the same backend

If Next.js is the only consumer of your server-side logic, keeping everything inside Next.js can be perfectly reasonable.

But imagine that later you introduce:

an iOS app
an Android app
an internal admin tool
a public API

Now the backend shouldn't really belong to the Next.js application anymore.

A dedicated NestJS API gives all clients the same backend:

        NestJS API
       /    |     \\
      /     |      \\
 Next.js  Mobile   Admin

The frontend becomes just one consumer among many.

That separation now has a clear architectural reason.

Case 2: Background jobs become important

Some tasks don't belong naturally inside a normal request-response cycle.

For example:

Generate 10,000 invoices
Process uploaded videos
Send 50,000 emails
Import a large CSV
Synchronize external systems

These jobs may need queues, retries, workers, scheduling and monitoring.

A dedicated backend architecture starts to become useful.

Instead of trying to keep everything tied to your web frontend:

Next.js
   ↓
Request
   ↓
Long-running task

you can move the work behind your API:

Next.js
   ↓
NestJS
   ↓
Queue
   ↓
Worker

The backend can evolve independently from the frontend.

Case 3: Your business logic is getting complicated

Consider an endpoint that originally looked like this:

POST /orders

At first it might simply insert an order into the database.

Later it needs to:

Validate inventory
Calculate discounts
Reserve stock
Create payment
Send notifications
Update analytics
Publish an event

You can absolutely organize all of this inside Next.js.

The question is whether the backend is becoming large enough that a framework specifically designed around services, modules and dependency injection starts providing real value.

NestJS encourages structures such as:

OrdersModule
 ├── OrdersController
 ├── OrdersService
 ├── InventoryService
 ├── PaymentService
 └── OrdersRepository

For a complex domain, that structure can become useful.

For five simple CRUD endpoints, it may be unnecessary ceremony.

Case 4: The backend must scale independently

Imagine your Next.js application receives normal web traffic, but your API performs CPU-intensive or high-volume workloads.

If everything is deployed as one application, frontend and backend scaling are coupled.

With separate applications:

Next.js
Frontend instances: 3

NestJS
API instances: 10

Workers
Instances: 20

each part can scale according to its own workload.

Again, this is valuable only when you actually have the problem.

Separating applications because they might need independent scaling someday usually means paying the complexity cost before receiving the benefit.

The hidden cost of adding NestJS

A separate backend isn't free.

You introduce:

another application
another deployment
another set of environment variables
network communication
authentication between systems
CORS considerations
duplicated types unless you share them
additional logging and monitoring
another place where failures can happen

A function call:

getUser(id)

may become:

await fetch(`${API_URL}/users/${id}`);

That architectural boundary should give you something valuable in return.

If it doesn't, it probably shouldn't exist yet.

A simple rule

I like to think about it this way.

Use Next.js alone when your backend mostly exists to support your Next.js application.

Consider Next.js + NestJS when your backend starts becoming an independent system.

For example:

Small website
→ Next.js

Typical SaaS
→ Probably Next.js

SaaS with complex domain logic
→ Maybe Next.js + NestJS

Web + mobile + public API
→ NestJS becomes much more interesting

Queues + workers + integrations
→ Dedicated backend starts making sense

Microservices / multiple backend teams
→ NestJS can be a natural fit

Final thought

Next.js becoming capable of backend development doesn't make NestJS unnecessary.

And NestJS being a powerful backend framework doesn't mean every Next.js application needs it.

The key question is whether you actually need the architectural boundary.

If your entire system can comfortably live inside one Next.js application, keeping it there may be the better engineering decision.

When the backend develops its own clients, workloads, scaling requirements and domain complexity, extracting it into something like NestJS starts to make much more sense.

Don't add a second framework because the architecture looks more professional.

Add it when the complexity it solves becomes greater than the complexity it introduces.

C# 15 Finally Gets Labeled `break` and `continue`

CertosinoLab — Tue, 11 Aug 2026 22:03:04 +0000

Nested loops are easy to write.

Getting out of them cleanly isn't always as easy.

Consider a simple grid search:

for (int row = 0; row < grid.Height; row++)
{
    for (int column = 0; column < grid.Width; column++)
    {
        if (grid[row, column].IsGoal)
        {
            // How do we exit both loops?
        }
    }
}

A normal break isn't enough:

break;

It only exits the innermost loop.

Until now, C# developers typically solved this with a Boolean flag, an early return, or occasionally goto.

C# 15 adds another option:

labeled break and continue.

The problem with a normal `break`

Suppose we're looking for a value inside a matrix:

bool found = false;

for (int row = 0; row < matrix.Length; row++)
{
    for (int col = 0; col < matrix[row].Length; col++)
    {
        if (matrix[row][col] == target)
        {
            found = true;
            break;
        }
    }

    if (found)
        break;
}

It works.

But notice what found is doing.

It isn't really application state.

It exists only to propagate a break from one loop to another.

With more deeply nested loops, this pattern becomes increasingly awkward.

C# 15: name the loop

C# 15 lets us place a label directly on the loop:

outer: for (int row = 0; row < matrix.Length; row++)
{
    for (int col = 0; col < matrix[row].Length; col++)
    {
        if (matrix[row][col] == target)
        {
            break outer;
        }
    }
}

That's the important new syntax:

outer: for (...)

and:

break outer;

Instead of breaking only the inner loop, C# knows that we want to exit the loop labeled outer.

Execution continues immediately after that loop.

The Boolean flag disappears completely.

It also works with `continue`

The same idea applies to continue.

Imagine processing a collection of orders.

If any item in an order is invalid, we want to abandon that order and immediately move to the next one.

Without labeled continue, we might need another flag:

foreach (var order in orders)
{
    bool invalid = false;

    foreach (var item in order.Items)
    {
        if (!item.IsValid)
        {
            invalid = true;
            break;
        }

        Process(item);
    }

    if (invalid)
        continue;

    Complete(order);
}

In C# 15:

ordersLoop: foreach (var order in orders)
{
    foreach (var item in order.Items)
    {
        if (!item.IsValid)
        {
            continue ordersLoop;
        }

        Process(item);
    }

    Complete(order);
}

When this executes:

continue ordersLoop;

C# immediately starts the next iteration of the labeled outer loop.

There is no temporary flag and no additional condition after the inner loop.

Microsoft's documentation specifically describes labeled jumps as a replacement for Boolean flags and some goto patterns used to escape nested control flow.

What about `goto`?

C# could already escape nested loops using goto:

for (...)
{
    for (...)
    {
        if (found)
            goto Finished;
    }
}

Finished:
Console.WriteLine("Done");

That works, and goto isn't inherently evil.

But labeled break communicates the intent more precisely:

search: for (...)
{
    for (...)
    {
        if (found)
            break search;
    }
}

We're not saying:

Jump to this arbitrary position.

We're saying:

Stop this specific loop.

That's a useful distinction.

C# 15 even introduces analyzer support through IDE0410, which can identify some Boolean-flag and goto patterns that can be replaced with labeled jumps.

`break` and `continue` aren't identical

There is one small distinction worth remembering.

A labeled break can target an enclosing:

for
foreach
while
do
switch

A labeled continue can only target an enclosing loop, because continuing a switch doesn't make sense.

And existing code doesn't change.

This:

break;

still exits the nearest applicable construct.

This:

continue;

still continues the nearest loop.

You only get the new behavior when you explicitly provide a label.

Should you start labeling every loop?

Probably not.

Most loops don't need it.

And if you have five levels of nested control flow, extracting some logic into another method may still produce cleaner code.

But there are legitimate cases where nested loops are the simplest representation of the problem:

scanning matrices
traversing multidimensional data
processing batches and their items
parsing nested structures
searching combinations

In those situations, labeled jumps can remove bookkeeping variables without forcing you to restructure otherwise straightforward code.

Trying it today

C# 15 is currently available through the .NET 11 preview SDK and Visual Studio 2026 Insiders.

The feature itself is surprisingly small.

Before:

bool stop = false;

// loops...

if (stop)
    break;

Now:

outer: for (...)
{
    for (...)
    {
        break outer;
    }
}

Sometimes language improvements aren't about enabling something completely new.

They're about letting the code say more clearly what you already wanted it to do.

And labeled break and continue are a nice example of exactly that.

Lazy Load Angular Services with `injectAsync()

CertosinoLab — Tue, 11 Aug 2026 09:00:39 +0000

Angular has always made it easy to lazy-load routes and components.

But what about services?

Imagine your application has an export feature that depends on a large library for generating spreadsheets or PDFs.

Only a small percentage of users click Export, but the code behind that feature may still end up being part of the initial JavaScript bundle.

Angular 22 introduces a simple solution:

injectAsync().

It allows you to load a service only when you actually need it. The API is stable since Angular 22.

The usual approach

Suppose we have a service responsible for exporting reports:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root'
})
export class ReportExporter {
  export() {
    // Generate spreadsheet, PDF, etc.
  }
}

Normally, we could inject it into a component:

import { Component, inject } from '@angular/core';
import { ReportExporter } from './report-exporter';

@Component({
  selector: 'app-report',
  template: `
    <button (click)="export()">
      Export
    </button>
  `
})
export class ReportComponent {
  private exporter = inject(ReportExporter);

  export() {
    this.exporter.export();
  }
}

Simple and perfectly fine.

But if ReportExporter depends on a large library and the export feature is rarely used, we might prefer not to include that code in the initial load.

This is where injectAsync() becomes useful.

Enter `injectAsync()`

Instead of importing the service normally, we can load it dynamically:

import {
  Component,
  injectAsync
} from '@angular/core';

@Component({
  selector: 'app-report',
  template: `
    <button (click)="export()">
      Export
    </button>
  `
})
export class ReportComponent {
  private exporter = injectAsync(
    () =>
      import('./report-exporter')
        .then(m => m.ReportExporter)
  );

  async export() {
    const exporter = await this.exporter();

    exporter.export();
  }
}

The important part is this:

private exporter = injectAsync(
  () =>
    import('./report-exporter')
      .then(m => m.ReportExporter)
);

injectAsync() doesn't immediately return the service.

Instead, it returns a function that resolves to the service when called:

const exporter = await this.exporter();

The first call triggers the dynamic import.

Angular's bundler can therefore place the service in a separate JavaScript chunk instead of loading it with the initial application bundle. Subsequent calls reuse the same promise, so the chunk isn't downloaded again.

Conceptually, the loading process becomes:

Application starts
       ↓
Report page loads
       ↓
Exporter is NOT loaded
       ↓
User clicks Export
       ↓
Exporter chunk is downloaded
       ↓
Service is resolved through Angular DI
       ↓
Export runs

For features that most users never activate, this can be a useful performance optimization.

Your service must be auto-provided

There is one important requirement.

For lazy injection to work, Angular needs to know how to create the service automatically.

You can use:

@Injectable({
  providedIn: 'root'
})
export class ReportExporter {
  // ...
}

or Angular's newer @Service() decorator:

import { Service } from '@angular/core';

@Service()
export class ReportExporter {
  // ...
}

A service that isn't auto-provided cannot be lazy-loaded with injectAsync().

You can also prefetch it

Sometimes you don't want the service in the initial bundle, but you also don't want the user to wait after clicking the button.

Angular provides a useful middle ground.

You can prefetch the dependency when the browser becomes idle:

import {
  injectAsync,
  onIdle
} from '@angular/core';

private exporter = injectAsync(
  () =>
    import('./report-exporter')
      .then(m => m.ReportExporter),
  {
    prefetch: onIdle
  }
);

The application can load normally first.

Then, when the browser has some idle time, Angular can start downloading the lazy dependency in the background.

If the user needs the feature before the prefetch happens, Angular simply loads it immediately.

When should you use it?

injectAsync() doesn't mean that every Angular service should become lazy.

For a small service used throughout the application, regular inject() is still simpler:

private userService = inject(UserService);

injectAsync() becomes more interesting when a service:

depends on a large third-party library
powers a rarely used feature
handles exports or document generation
loads specialized editors or visualization tools
performs work that only some users need

In other words, use it when loading the service later can actually save meaningful JavaScript during application startup.

Final thought

injectAsync() is a small Angular 22 API, but it fills an interesting gap.

We already lazy-load routes.

We already lazy-load components.

Now we can apply the same idea to services:

const exporter = injectAsync(
  () => import('./report-exporter')
);

And load expensive functionality only when the user actually needs it.

Sometimes improving startup performance isn't about making code execute faster.

It's simply about not loading that code yet.

How to Sync Two Browser Tabs with JavaScript

CertosinoLab — Mon, 10 Aug 2026 06:03:22 +0000

Have you ever opened the same web app in two browser tabs and noticed that they behave like two completely separate applications?

Sometimes that's fine.

But sometimes you want an action in one tab to be immediately reflected in the others.

You could use a server, WebSockets, polling, or even localStorage.

But for simple communication between browser tabs, JavaScript already provides a native API:

BroadcastChannel.

Let's see how it works by building a very small counter that stays synchronized across multiple tabs.

The HTML

We only need a counter and a button:

<h2 id="counter">0</h2>
<button id="increment">+1</button>

Nothing special so far.

Each browser tab will have its own JavaScript state:

let count = 0;

Without any synchronization, clicking the button in one tab would only update that tab.

Let's fix that.

Create a BroadcastChannel

First, create a channel:

const channel = new BroadcastChannel("counter");

The string "counter" is simply the name of the channel.

Any tab from the same origin that creates a BroadcastChannel with the same name can communicate with the others.

Now let's implement our counter.

const channel = new BroadcastChannel("counter");

let count = 0;

const counter = document.querySelector("#counter");
const button = document.querySelector("#increment");

button.onclick = () => {
  count++;

  counter.textContent = count;

  channel.postMessage(count);
};

Every time we click the button, we increase the counter and then send the new value through the channel:

channel.postMessage(count);

But the other tabs still need to listen for that message.

Receive messages from other tabs

We can do that with the message event:

channel.onmessage = ({ data }) => {
  count = data;
  counter.textContent = count;
};

And that's basically the whole implementation.

Here is the complete JavaScript:

const channel = new BroadcastChannel("counter");

let count = 0;

const counter = document.querySelector("#counter");
const button = document.querySelector("#increment");

button.onclick = () => {
  count++;

  counter.textContent = count;

  channel.postMessage(count);
};

channel.onmessage = ({ data }) => {
  count = data;
  counter.textContent = count;
};

Now open the page in two browser tabs.

Click +1 in the first tab:

Tab 1 → 1
Tab 2 → 1

Then click +1 in the second tab:

Tab 1 → 2
Tab 2 → 2

The two tabs are now communicating directly.

No server.

No WebSocket.

No polling.

What is actually happening?

When this line runs:

channel.postMessage(count);

the browser sends the value to the other contexts listening to the "counter" channel.

The other tab receives it here:

channel.onmessage = ({ data }) => {
  // data contains the received value
};

One important detail is that a channel does not send the message back to the same BroadcastChannel object that posted it.

That's why we update the current tab ourselves:

counter.textContent = count;

and use BroadcastChannel to update the other tabs.

You can send more than numbers

BroadcastChannel isn't limited to strings or numbers.

You can send objects too:

channel.postMessage({
  type: "counter-updated",
  value: count
});

And receive them normally:

channel.onmessage = ({ data }) => {
  if (data.type === "counter-updated") {
    count = data.value;
    counter.textContent = count;
  }
};

For real applications, this approach is often better because different message types can share the same channel.

Same origin only

There is one important restriction.

BroadcastChannel works between browsing contexts that belong to the same origin.

For example, two tabs opened on:

https://example.com

can communicate with each other.

A page on another domain cannot join that channel.

This makes BroadcastChannel useful for communication between different instances of the same web application.

When is this useful?

A synchronized counter is obviously just a demo.

In a real application, the same technique can be used to:

refresh data after another tab modifies it
synchronize application state
notify tabs when cached data becomes stale
coordinate background operations
communicate between tabs, windows and Web Workers

For simple cross-tab communication, it can save you from building a much more complicated solution.

Closing the channel

When you no longer need the channel, you can close it:

channel.close();

For channels that exist for the entire lifetime of a page, this may not be especially important.

But it's useful when channels are created dynamically.

Final thought

BroadcastChannel is one of those small Web APIs that is easy to overlook.

The entire idea comes down to two operations.

Send something:

channel.postMessage(data);

Receive something:

channel.onmessage = ({ data }) => {
  // react to the message
};

So the next time you need two tabs of the same web app to communicate, you might not need a server or WebSocket connection.

Sometimes the browser already gives you exactly what you need.

JavaScript Finally Fixed Summation — But 0.1 + 0.2 Is Still Broken

CertosinoLab — Fri, 07 Aug 2026 03:24:15 +0000

If you've written JavaScript for more than five minutes, you've probably seen this:

0.1 + 0.2
// 0.30000000000000004

It has become one of those JavaScript jokes we all know.

But in 2026, JavaScript got a new method that sounds like it should finally solve the problem:

Math.sumPrecise()

So... is floating-point pain finally over?

Not exactly.

Math.sumPrecise() solves a real and surprisingly common precision problem, but probably not the one you're thinking about.

And understanding the difference tells us something important about how JavaScript numbers actually work.

The problem with the way we usually sum numbers

Let's say we want to add a list of numbers.

Most JavaScript developers would probably reach for reduce():

const numbers = [10, 20, 30, 40];

const total = numbers.reduce(
  (sum, number) => sum + number,
  0
);

console.log(total);
// 100

Nothing wrong here.

For ordinary numbers, this works exactly as expected.

But now let's make things more interesting:

const numbers = [
  1e20,
  0.1,
  -1e20
];

const total = numbers.reduce(
  (sum, number) => sum + number,
  0
);

console.log(total);
// 0

Wait.

Mathematically:

100000000000000000000
+                  0.1
-100000000000000000000
--------------------------------
                   0.1

The answer should be 0.1.

JavaScript gives us:

And this is exactly the kind of problem Math.sumPrecise() was created to address.

Meet `Math.sumPrecise()`

The same calculation can now be written as:

Math.sumPrecise([
  1e20,
  0.1,
  -1e20
]);

// 0.1

That's it.

No library.

No custom summation algorithm.

No special class.

Just:

Math.sumPrecise(iterable);

The method accepts an iterable of JavaScript numbers and returns their sum while avoiding the precision loss that can happen during intermediate additions.

Math.sumPrecise() was standardized as part of ECMAScript 2026 and became Baseline Newly Available across modern browsers in April 2026.

But to understand why this matters, we need to look at what went wrong with reduce().

Why did `reduce()` return zero?

JavaScript's regular Number type uses IEEE 754 double-precision floating-point numbers.

That means numbers have a limited amount of precision.

Consider this:

1e20 + 0.1

1e20 is enormous compared with 0.1.

At that magnitude, JavaScript cannot represent the tiny difference introduced by adding 0.1.

So this:

1e20 + 0.1

is effectively stored as:

1e20

The 0.1 has disappeared.

Then our reduction continues:

1e20 + -1e20

which gives:

The important part is that the precision was lost during an intermediate calculation.

Once that information is gone, the next addition can't magically recover it.

This is why the order in which floating-point operations happen can sometimes affect the result of a naive summation.

What `Math.sumPrecise()` does differently

Conceptually, instead of repeatedly doing this:

current sum
    +
next number
    ↓
round
    ↓
current sum
    +
next number
    ↓
round
    ↓
...

Math.sumPrecise() performs the summation in a way that preserves the contributions of the input values much more accurately before producing the final JavaScript Number.

MDN describes the behavior roughly as if the exact mathematical values represented by the input floating-point numbers were summed first, with the final result then converted to the nearest representable 64-bit floating-point value.

Compare them:

const values = [
  1e20,
  0.1,
  -1e20
];

values.reduce((a, b) => a + b, 0);
// 0

Math.sumPrecise(values);
// 0.1

Or with integers of dramatically different magnitudes:

const values = [
  10_000_000_000_000_000,
  1,
  -10_000_000_000_000_000
];

values.reduce((a, b) => a + b, 0);
// 0

Math.sumPrecise(values);
// 1

That's a meaningful improvement.

But now comes the interesting part.

Does it fix `0.1 + 0.2`?

Let's try it.

Math.sumPrecise([
  0.1,
  0.2
]);

The result is:

0.30000000000000004

Yep.

Our favorite JavaScript number is still alive.

So what happened?

`Math.sumPrecise()` can't fix numbers that were already approximate

The famous 0.1 + 0.2 issue is slightly different from our previous example.

The problem begins before the addition even happens.

Numbers such as:

0.1
0.2

cannot be represented exactly using binary floating point.

In the same way that 1 / 3 cannot be represented exactly with a finite number of decimal digits:

0.333333333333...

certain decimal fractions cannot be represented exactly as finite binary fractions.

So when you write:

0.1

the value stored by JavaScript is already the closest representable floating-point approximation.

The same happens with:

0.2

Math.sumPrecise() can accurately add the floating-point values it receives.

But it cannot turn those values back into the exact decimal numbers you originally had in mind.

That's why:

Math.sumPrecise([0.1, 0.2])

still produces:

0.30000000000000004

This distinction is probably the most important thing to understand about the new API.

Math.sumPrecise() fixes precision lost while summing.

It does not fix precision already lost when representing a number.

So when is `Math.sumPrecise()` actually useful?

Consider a dashboard collecting thousands of measurements.

const measurements = [
  1200000000,
  0.00021,
  0.00017,
  -1200000000,
  0.00034,
  // ...
];

Or scientific data where values can have dramatically different magnitudes.

Or analytics where you're aggregating a large iterable:

const total = Math.sumPrecise(events.map(
  event => event.value
));

Or perhaps you're processing a generator:

function* measurements() {
  yield 1e20;
  yield 0.1;
  yield -1e20;
}

Math.sumPrecise(measurements());
// 0.1

Notice that Math.sumPrecise() doesn't require an array.

It accepts an iterable.

That means things such as arrays, sets, typed arrays, and generators can be passed directly when they yield numbers.

For example:

Math.sumPrecise(
  new Set([10, 20, 30])
);

// 60

And:

Math.sumPrecise(
  new Float64Array([
    10,
    20,
    30
  ])
);

// 60

That makes the API pleasantly small and composable.

Should we stop using `reduce()` for sums?

Not necessarily.

This:

numbers.reduce(
  (sum, n) => sum + n,
  0
);

isn't suddenly bad code.

For many applications, especially when you're adding ordinary integers or values with similar magnitudes, the result will be perfectly fine.

But there is now a more expressive operation when what you actually mean is:

“Give me the most accurate sum of these JavaScript numbers.”

Instead of implementing summation using a generic reduction:

const total = values.reduce(
  (total, value) => total + value,
  0
);

you can express your intention directly:

const total = Math.sumPrecise(values);

I like APIs like this.

Not because they make JavaScript dramatically more powerful, but because they move a surprisingly subtle problem into the language itself.

One important warning: money

You might see the word precise and immediately think:

Great. I'll use this for prices.

Be careful.

Consider:

Math.sumPrecise([
  0.1,
  0.2
]);

// 0.30000000000000004

Math.sumPrecise() does not turn JavaScript Numbers into decimal numbers.

If your application requires exact decimal arithmetic — especially financial calculations — the underlying binary floating-point representation is still relevant.

A common approach for currencies is to store values using the smallest unit:

const pricesInCents = [
  10,
  20,
  35
];

const totalInCents =
  Math.sumPrecise(pricesInCents);

console.log(totalInCents);
// 65

Then convert for display:

const totalInDollars =
  totalInCents / 100;

Depending on the requirements of the application, you may instead need BigInt or a dedicated decimal arithmetic solution.

Math.sumPrecise() makes summation better.

It does not change JavaScript's numeric model.

A couple of surprising edge cases

There are some details worth knowing.

An empty iterable returns negative zero:

Math.sumPrecise([]);

// -0

Yes, JavaScript has both 0 and -0.

You can verify it with:

Object.is(
  Math.sumPrecise([]),
  -0
);

// true

Also, Math.sumPrecise() expects numbers.

This doesn't work:

Math.sumPrecise([
  1,
  "2",
  3
]);

It throws a TypeError instead of coercing "2" into the number 2.

That's actually a nice property.

A function whose purpose is numerical accuracy probably shouldn't silently start converting random strings.

Can I use it today?

As of 2026, yes — with the usual compatibility caveat.

Math.sumPrecise() became Baseline Newly Available in April 2026, meaning current releases of the major browser engines support it, although older browsers and devices may not.

If your application supports older environments, feature detection is simple:

if (typeof Math.sumPrecise === "function") {
  const total =
    Math.sumPrecise(values);
}

There are also polyfill implementations available through projects such as core-js.

Whether you should ship a fallback depends, as always, on the browsers your users actually run.

`reduce()` vs `Math.sumPrecise()`

Here's the mental model I would keep:

	`reduce((a, b) => a + b)`	`Math.sumPrecise()`
Simple sums	✅	✅
Works with floating-point numbers	✅	✅
Minimizes intermediate precision loss	❌	✅
Fixes `0.1 + 0.2`	❌	❌
Accepts iterables directly	Depends	✅
Exact decimal arithmetic	❌	❌
Communicates “sum these values” directly	Kind of	✅

The most important row is probably this one:

Fixes 0.1 + 0.2 → NO

Because the name sumPrecise() makes it very easy to assume otherwise.

JavaScript didn't fix floating point. It fixed summation.

And I think that's the right way to think about this feature.

This:

0.1 + 0.2

is still:

0.30000000000000004

That's not going anywhere.

But this:

[
  1e20,
  0.1,
  -1e20
].reduce((a, b) => a + b, 0);

returning:

no longer has to be the best JavaScript can do.

We can now write:

Math.sumPrecise([
  1e20,
  0.1,
  -1e20
]);

// 0.1

It's a small API.

Probably not one that will change the way you write JavaScript every day.

But it's also the kind of language improvement I enjoy: taking something deceptively difficult, giving it a clear name, and making the correct solution a one-liner.

So no, JavaScript hasn't finally defeated floating point.

But it did quietly become a lot better at adding numbers.

And honestly, I'll take that.

Streaming Large ZIP Archives in the Browser with Vue and the File System Access API

CertosinoLab — Thu, 30 Jul 2026 17:32:27 +0000

Blob vs streaming, ZIP64, progress tracking, cancellation, and browser fallbacks

Exporting a file from a web application usually looks like a simple operation.

The application generates some data, creates a Blob, builds an object URL, and programmatically clicks a download link.

This approach works well for reports, JSON documents, generated images, and other relatively small outputs. However, it becomes much more problematic when the application needs to export hundreds of megabytes or several gigabytes of data.

A large archive may require the browser to keep source files, compression buffers, temporary byte arrays, and the final Blob alive at the same time. On a device with limited memory, this can slow down the page, trigger aggressive garbage collection, or terminate the browser tab completely.

To explore a different approach, I built StreamZIP Lab, a small frontend project that creates ZIP archives directly in the browser.

The application compares two export strategies:

writing the ZIP archive progressively to disk through the File System Access API;
generating the complete archive as a Blob before starting a traditional browser download.

The project also covers ZIP64, compression strategies, progress tracking, cancellation, browser compatibility, and the special treatment of formats such as JPEG and MP4.

Everything is implemented in three files:

streamzip-lab/
├── index.html
├── styles.css
└── functions.js

Vue is loaded directly from a CDN, so there is no package manager, bundler, build command, or Single-File Component involved.

This article explains the technical decisions behind the project and some of the less obvious problems involved in generating large archives inside a browser.

What the project does

StreamZIP Lab allows the user to select multiple local files and export them as a single ZIP archive.

The main workflow is:

The user selects or drops one or more files.
The application examines their extensions and MIME types.
Each file is assigned either the DEFLATE or STORE strategy.
The user chooses between streaming and Blob output.
The ZIP archive is generated.
The interface displays per-file and global progress.
The export can be cancelled while it is running.

The application also shows information about the current browser:

Secure context       Yes
showSaveFilePicker   Available
Web Streams          Available

When the File System Access API is supported, the recommended mode is Stream to disk.

When it is not available, the application automatically switches to Blob + download.

The project is related to Progressive Web Apps because direct file interaction is especially useful for installable editors, media tools, local-first applications, backup utilities, and offline-capable applications.

However, the current three-file demo is not, by itself, a complete installable PWA. A production PWA would also require at least a web app manifest and a service worker. StreamZIP Lab focuses specifically on the export and filesystem layer that could be integrated into a larger PWA.

The technology stack

The project uses only standard browser technologies and two external libraries:

Vue 3 for the reactive interface;
zip.js for ZIP creation;
the File System Access API for direct disk output;
the Web Streams API for progressive writing;
AbortController for cancellation;
the traditional Blob download pattern as a fallback.

Vue is loaded through its global production build:

<script src="https://cdn.jsdelivr.net/npm/vue@3.5.40/dist/vue.global.prod.js"></script>

zip.js is loaded in the same way:

<script src="https://cdn.jsdelivr.net/npm/@zip.js/zip.js@2.7.29/dist/zip-full.min.js"></script>

Finally, the project logic is loaded from the local JavaScript file:

<script src="functions.js"></script>

Vue officially supports this CDN-based approach. The global build exposes APIs such as createApp through the global Vue object and does not require a build step. The main limitation is that Single-File Component syntax is not available.

For a small technical lab, this limitation is acceptable. Keeping the project in three readable files makes it easier to inspect the actual browser APIs without introducing build configuration.

The Vue application starts with:

const { createApp } = Vue;
createApp({
  data() {
    return {
      files: [],
      archiveName: "streamzip-export.zip",
      exportMode: "stream",
      compressionMode: "auto",
      zip64Mode: "auto",
      status: "idle"
    };
  }
}).mount("#app");

Most of the interface state is stored in one application object.

For a larger application, I would probably divide the code into modules or Vue components. For this project, keeping the complete workflow in functions.js makes the relationship between state, browser APIs, and ZIP generation easier to follow.

The traditional Blob export pattern

A common client-side download implementation looks similar to this:

const blob = new Blob([generatedData], {
  type: "application/octet-stream"
});
const url = URL.createObjectURL(blob);
const anchor = document.createElement("a");
anchor.href = url;
anchor.download = "export.bin";
anchor.click();
URL.revokeObjectURL(url);

The same pattern can be used for a ZIP archive:

const blobWriter = new zip.BlobWriter("application/zip");
const zipWriter = new zip.ZipWriter(blobWriter);
await zipWriter.add(
  "document.txt",
  new zip.TextReader("Hello world")
);
const archiveBlob = await zipWriter.close();

Only after close() returns the finished Blob can the browser download it:

downloadBlob(archiveBlob, "archive.zip");

This approach is simple and compatible with many browsers.

The important detail is that the application needs to finish generating the archive before the download starts.

For a 5 MB archive, this is normally not a problem.

For a 5 GB archive, it may become the central architectural problem.

A Blob is not exactly the same as memory

A Blob represents immutable raw data. It provides metadata such as its size and MIME type and can expose slices or a readable stream.

It is tempting to say that every Blob always exists entirely in RAM, but that explanation is too simplistic.

A browser implementation may internally store Blob data in memory, temporary files, shared buffers, or a combination of these strategies. The exact storage mechanism is an implementation detail.

The real problem is the complete generation pipeline.

When an archive is produced as one final Blob, several resources may coexist:

Source File objects
        ↓
Reader buffers
        ↓
Compression worker buffers
        ↓
Compressed chunks
        ↓
ZIP output buffers
        ↓
Final Blob
        ↓
Object URL

Additional copies can appear when application code:

concatenates arrays;
converts streams to ArrayBuffer;
constructs large Uint8Array values;
calls Response.blob();
duplicates data between workers and the main thread;
retains references longer than necessary.

The final memory peak depends on the browser, the ZIP library, compression settings, file formats, worker implementation, and garbage collection timing.

Therefore, StreamZIP Lab does not claim that a particular input size will always crash a browser.

Instead, it introduces a configurable warning threshold:

const BYTES_IN_MIB = 1024 * 1024;
const BLOB_WARNING_BYTES = 512 * BYTES_IN_MIB;

When the selected files exceed 512 MiB and Blob mode is active, the application shows a warning and requires explicit confirmation.

This is a user-interface safety threshold, not a browser specification limit.

Some devices may handle a much larger archive. Others may struggle with a smaller one, especially on mobile devices or when several memory-intensive tabs are open.

Why streaming changes the architecture

The Web Streams API is designed for data that is created, processed, and consumed incrementally instead of being read entirely into memory. It also provides queuing and backpressure mechanisms.

A streaming ZIP pipeline can be represented as:

File
  ↓
BlobReader
  ↓
Compression
  ↓
ZIP records
  ↓
WritableStream
  ↓
Destination file

Instead of waiting for one complete archive object, the ZIP writer emits chunks as they become available.

Each chunk is passed to the destination stream and written to disk.

The main conceptual difference is:

Blob mode
Read everything
→ generate everything
→ retain final result
→ begin download
Streaming mode
Read a chunk
→ process the chunk
→ write the chunk
→ continue

Streaming does not mean zero memory usage.

The browser and compression library still require buffers. ZIP metadata must also be retained until the central directory can be written.

The objective is to keep memory usage related to the active working set rather than the complete archive size.

Backpressure

Backpressure is one of the most important properties of a streaming pipeline.

Imagine that the ZIP compressor can produce data faster than the filesystem can write it.

Without flow control, compressed chunks would continue accumulating in memory.

A stream communicates that the destination is temporarily unable to accept more data. This signal moves backward through the pipeline, slowing down the producer.

The Streams Standard describes backpressure as the process of normalizing the flow according to the rate at which the chain can process chunks.

Conceptually:

Fast producer
     ↓
Compression
     ↓
Full queue
     ↓
Slow filesystem
The destination applies backpressure
     ↑
The producer slows down

In application code, this is often handled by the stream implementation and the promises returned by write operations.

StreamZIP Lab passes a WritableStream to zip.js. The library then writes ZIP data to that stream while respecting the asynchronous destination.

Opening the save picker

The streaming export starts with showSaveFilePicker():

fileHandle = await window.showSaveFilePicker({
  id: "streamzip-lab-export",
  suggestedName: this.archiveName,
  types: [
    {
      description: "ZIP archive",
      accept: {
        "application/zip": [".zip"]
      }
    }
  ]
});

The method opens the native save dialog and returns a FileSystemFileHandle.

The options do not silently force the final location or filename. They provide hints to the browser:

suggestedName proposes a default filename;
description describes the selectable format;
accept associates a MIME type with one or more extensions;
id allows the browser to associate similar picker operations.

The File System Access specification recommends providing both MIME types and extensions because operating systems do not all identify file formats in the same way.

The API does not give the page unrestricted access to arbitrary filesystem paths.

The user sees a browser-controlled or operating-system-controlled picker and selects the destination.

User activation must be preserved

showSaveFilePicker() is a privileged operation.

It must be initiated from a user action such as a button click.

This requirement affects the order of the code.

The picker should be opened before long asynchronous work:

async exportWithFileSystemAccess() {
  // Keep this as the first await in the export path.
  const fileHandle = await window.showSaveFilePicker({
    suggestedName: this.archiveName
  });
  // Compression can begin after authorization.
  await this.createArchive(fileHandle);
}

A problematic implementation could do this:

async function exportArchive() {
  const generatedData = await performLongCalculation();
  const handle = await window.showSaveFilePicker({
    suggestedName: "archive.zip"
  });
}

By the time the long calculation finishes, the transient user activation may no longer be valid.

The picker can then fail with a security-related error.

For this reason, StreamZIP Lab keeps showSaveFilePicker() as the first awaited operation in the native streaming path.

The application first asks the user where the archive should be saved. Only after the handle has been obtained does it begin compression.

Creating the writable destination

A FileSystemFileHandle does not write bytes by itself.

The application calls createWritable():

const nativeWritable = await fileHandle.createWritable();

This returns a writable file stream connected to the selected destination.

The project stores a reference to it:

this.activeNativeWritable = nativeWritable;

The reference is needed because cancellation must be able to abort the destination even while zip.js is using an outer stream.

The project creates a small adapter:

const outputStream = new WritableStream({
  write: (chunk) => nativeWritable.write(chunk),
  close: () => nativeWritable.close(),
  abort: (reason) => nativeWritable.abort(reason)
});

The adapter exposes the three relevant operations:

write() forwards a generated ZIP chunk;
close() finalizes the destination;
abort() interrupts the write operation.

The ZIP writer is then created using this stream:

const zipWriter = this.createZipWriter(outputStream);

At this point, zip.js can progressively send archive records to the selected file.

Creating the ZIP writer

The project centralizes ZIP writer configuration:

createZipWriter(destination) {
  const options = {
    bufferedWrite: false,
    dataDescriptorSignature: true
  };
  if (this.zip64Mode === "force") {
    options.zip64 = true;
  }
  return new zip.ZipWriter(destination, options);
}

bufferedWrite: false is important for the purpose of the demo because the destination should receive data progressively instead of waiting for a fully buffered output.

dataDescriptorSignature: true tells the writer to include a signature before data descriptors.

When ZIP64 is forced, zip64 is added to the options. Otherwise, zip.js can determine when ZIP64 structures are necessary.

zip.js is designed for large data sets and supports Web Streams, multi-core compression, and archives larger than 4 GB through ZIP64.

Using a library is important here.

A valid ZIP writer must handle much more than concatenating compressed files:

local file headers;
compression methods;
CRC-32 values;
compressed and uncompressed sizes;
file names and encodings;
timestamps;
offsets;
data descriptors;
central directory entries;
end-of-directory records;
ZIP64 extra fields and records.

Implementing all of this correctly would turn the project into a ZIP format implementation rather than a File System Access API experiment.

General structure of a ZIP archive

A ZIP archive is not simply a sequence of compressed files.

A simplified archive with two files looks like this:

Local file header: document.txt
Compressed or stored data
Optional data descriptor
Local file header: photo.jpg
Compressed or stored data
Optional data descriptor
Central directory entry: document.txt
Central directory entry: photo.jpg
Optional ZIP64 end record
Optional ZIP64 locator
End of central directory record

The official ZIP specification describes the overall structure as local file records followed by the central directory and the end-of-central-directory structures. It also explicitly states that data descriptors facilitate streaming.

Each local file header appears near the corresponding file data.

It contains information such as:

the compression method;
modification time;
file name;
general-purpose flags;
CRC-32;
compressed size;
uncompressed size;
optional extra fields.

The central directory is written near the end of the archive.

It contains one entry for every archived file and repeats some information from the local headers. It also includes the offset of each local file record.

This design allows an extractor to read the directory and quickly find the contents of the archive.

Why data descriptors are useful for streaming

When writing a local file header, a ZIP generator would ideally already know:

the final CRC-32;
the final compressed size;
the uncompressed size.

The uncompressed size may be available from the source file.

The compressed size is not necessarily known until compression has finished.

The CRC-32 is also calculated while the input is processed.

A non-streaming implementation can compress the complete file first and then write a fully populated header.

A streaming implementation cannot always do that without buffering the complete result.

ZIP provides another mechanism.

The writer can mark the relevant fields as unavailable in the local header, write the file data, and append a data descriptor containing the final CRC and sizes.

Conceptually:

Local header
  CRC: not known yet
  compressed size: not known yet
Compressed data is streamed
Data descriptor
  CRC: final value
  compressed size: final value
  original size: final value

This is one of the reasons ZIP is suitable for progressive output.

It was designed with structures that permit archive data to be produced in one pass.

The central directory is still written at the end

Streaming does not eliminate the need for finalization.

While files are being written, the ZIP implementation must collect enough metadata to later produce the central directory.

The archive is not complete until the writer is closed:

await this.addEntries(zipWriter);
await zipWriter.close();

Calling close() writes the remaining directory records and final archive structures.

This explains why closing and aborting have different meanings.

close() means:

All entries are valid
→ write the central directory
→ finalize the archive
→ complete the destination

abort() means:

Stop producing data
→ discard pending writes where possible
→ do not finalize the archive

A partially written ZIP without its correct central directory should not be treated as a successful export.

Why ZIP64 is necessary

Classic ZIP records contain several 16-bit and 32-bit fields.

A 32-bit unsigned field can represent values up to:

4,294,967,295

That is 4 GiB minus one byte.

The traditional end-of-central-directory record also uses 16-bit fields for entry counts, creating the well-known limit of 65,535 entries.

ZIP64 extends the format with larger fields.

When a classic field cannot contain the real value, it uses a sentinel such as:

0xFFFFFFFF

or:

0xFFFF

The actual value is stored in a ZIP64 extra field or ZIP64 end-of-directory structure.

The PKWARE specification requires ZIP64 records when classic fields are too small for the required values.

The project displays a simple preliminary indication:

const ZIP32_MAX = 0xffffffff;
zip64Required() {
  return this.totalBytes > ZIP32_MAX
    || this.files.length > 0xffff;
}

This is useful for the interface, but it is only an estimate.

The actual need for ZIP64 depends on values such as:

the uncompressed size of an individual entry;
its compressed size;
the final archive size;
the offset of each local header;
the central directory size;
the number of entries.

The total input size alone does not fully determine every one of these values.

For that reason, the final format decision belongs to the ZIP writer.

The interface offers two modes:

Automatic
Force ZIP64

Automatic mode is appropriate for normal use.

Forced mode is useful for testing whether other archive tools correctly support ZIP64 output.

Adding files to the archive

The application processes files sequentially:

async addEntries(zipWriter) {
  let completedInputBytes = 0;
  for (const item of this.files) {
    const strategy = this.strategyFor(item.file);
    item.status = "processing";
    await zipWriter.add(
      item.archiveName,
      new zip.BlobReader(item.file),
      {
        level: strategy.level,
        signal: this.abortController.signal,
        lastModDate: item.file.lastModified? new Date(item.file.lastModified): new Date(),
        onprogress: (index, max) => {
          this.progress.currentBytes = index;
          this.progress.currentTotal = max || item.file.size;
          this.progress.processedBytes =
            completedInputBytes + index;
        }
      }
    );
    item.status = "done";
    completedInputBytes += item.file.size;
    this.progress.completedFiles += 1;
  }
}

Each browser File is already a type of Blob, so it can be passed to zip.js through BlobReader.

The source file does not need to be converted into a complete ArrayBuffer.

This avoids an unnecessary application-level copy.

Files are added one at a time, which also makes the progress model and status interface easier to understand.

Possible states are:

Pending
Running
Completed
Cancelled
Error

DEFLATE and STORE

A ZIP entry does not always need to be compressed.

The two strategies used by the project are:

DEFLATE, which compresses the input;
STORE, which copies the input into the archive without additional compression.

For plain text, CSV, JSON, XML, source code, and other repetitive data, DEFLATE can significantly reduce the output size.

For formats that are already compressed, another DEFLATE pass often produces little or no improvement.

It may even make the archive slightly larger because of compression metadata.

It also consumes CPU, increases export time, and may increase power usage on mobile devices.

The project supports three compression modes:

Automatic
DEFLATE all files
STORE all files

The automatic mode uses an extension and MIME-type heuristic.

Detecting already compressed formats

The project defines a set of commonly compressed extensions:

const ALREADY_COMPRESSED_EXTENSIONS = new Set([
  "7z",
  "aac",
  "avi",
  "avif",
  "br",
  "bz2",
  "docx",
  "epub",
  "flac",
  "gif",
  "gz",
  "heic",
  "heif",
  "jpeg",
  "jpg",
  "m4a",
  "m4v",
  "mkv",
  "mov",
  "mp3",
  "mp4",
  "ogg",
  "ogv",
  "opus",
  "pdf",
  "png",
  "pptx",
  "rar",
  "webm",
  "webp",
  "xlsx",
  "xz",
  "zip"
]);

Audio and video MIME prefixes are also treated as already compressed:

const ALREADY_COMPRESSED_MIME_PREFIXES = [
  "audio/",
  "video/"
];

The detection function combines extension and MIME checks:

isAlreadyCompressed(file) {
  const extension = this.extensionOf(file.name || "");
  const mime = (file.type || "").toLowerCase();
  return ALREADY_COMPRESSED_EXTENSIONS.has(extension)
    || ALREADY_COMPRESSED_MIME_TYPES.has(mime)
    || ALREADY_COMPRESSED_MIME_PREFIXES.some(
      (prefix) => mime.startsWith(prefix)
    );
}

This is a heuristic, not a content analysis algorithm.

A filename can have an incorrect extension.

A browser may provide an empty or inaccurate MIME type.

A PDF can contain highly compressible streams, already compressed images, or a mixture of content.

An Office Open XML document is itself a ZIP-based container, so applying DEFLATE to the complete .docx or .xlsx file normally offers limited benefit.

For a lightweight client-side application, the heuristic is a practical compromise.

A production application could make this configurable per file or inspect file signatures before choosing the compression method.

Choosing the compression strategy

The final decision is made by strategyFor():

strategyFor(file) {
  if (this.compressionMode === "store") {
    return {
      label: "STORE",
      level: 0,
      reason: "compression disabled"
    };
  }
  if (this.compressionMode === "always") {
    return {
      label: "DEFLATE",
      level: 6,
      reason: "compression forced"
    };
  }
  if (this.isAlreadyCompressed(file)) {
    return {
      label: "STORE",
      level: 0,
      reason: "already compressed format"
    };
  }
  return {
    label: "DEFLATE",
    level: 6,
    reason: "potentially compressible content"
  };
}

A compression level of 6 is used as a reasonable general-purpose balance.

A higher level can reduce output slightly for some inputs but usually requires more processing time.

For JPEG and MP4 files, automatic mode selects level 0, which corresponds to STORE.

The resulting ZIP archive still contains the files normally. They are simply not recompressed.

Progress tracking

Progress reporting for a generated ZIP is less obvious than it initially appears.

The application knows:

the size of every source file;
the total size of all source files;
how many files have completed;
the number of input bytes processed for the active file.

It does not necessarily know the final archive size in advance.

The compression ratio depends on the file contents and selected strategy.

For this reason, StreamZIP Lab defines global progress in terms of input bytes processed.

The total size is calculated with:

totalBytes() {
  return this.files.reduce(
    (total, item) => total + item.file.size,
    0
  );
}

The ZIP entry callback updates the current file:

onprogress: (index, max) => {
  this.progress.currentBytes = index;
  this.progress.currentTotal = max || item.file.size;
  this.progress.processedBytes = Math.min(
    this.totalBytes,
    completedInputBytes + index
  );
}

The percentage is then:

overallPercent() {
  if (!this.totalBytes) {
    return this.status === "success"? 100: 0;
  }
  const value = Math.round(
    this.progress.processedBytes
    / this.totalBytes
    * 100
  );
  return Math.min(100, Math.max(0, value));
}

This produces a stable and understandable progress indicator.

However, it is important to describe it correctly.

It means:

Percentage of source bytes processed

It does not mean:

Percentage of final ZIP bytes written

These metrics are related but not identical.

For example, a large text file may generate far fewer output bytes than input bytes, while a stored video file may produce almost the same number of input and output bytes.

The interface also displays:

the current filename; current-file progress; • •

completed file count;
elapsed time;
export mode;
final Blob size when available.

In native streaming mode, the application does not calculate the final output size because the archive is written directly to disk and no final Blob is returned.

Cancelling the export

Cancellation must affect more than the interface.

Changing the status label to “Cancelled” while compression continues in the background would not be a real cancellation mechanism.

The project creates an AbortController at the start of every export:

this.abortController = new AbortController();

Its signal is passed to every zip.js entry:

await zipWriter.add(
  item.archiveName,
  new zip.BlobReader(item.file),
  {
    level: strategy.level,
    signal: this.abortController.signal,
    onprogress
  }
);

When the user clicks Cancel export, the controller is aborted:

cancelExport() {
  if (!this.isBusy || this.cancelRequested) {
    return;
  }
  this.cancelRequested = true;
  if (
    this.abortController
    &&!this.abortController.signal.aborted
  ) {
    this.abortController.abort(
      this.createAbortError()
    );
  }
  void this.abortNativeWritable(
    this.createAbortError()
  );
}

The application also aborts the native destination:

async abortNativeWritable(reason) {
  const writable = this.activeNativeWritable;
  if (!writable || typeof writable.abort!== "function") {
    return;
  }
  try {
    await writable.abort(reason);
  } catch (error) {
    // The stream may already be closed or aborted.
  }
}

This two-level cancellation is useful because it stops both sides of the operation:

AbortController
→ stops ZIP entry processing
nativeWritable.abort()
→ stops destination writing and cleanup

The Streams Standard defines abortion as an error transition for the writable stream and its pending operation.

After cancellation, the project does not call the normal archive finalization path.

The destination should therefore not be presented as a successful ZIP archive.

The exact appearance of an aborted destination can vary by browser and operating system. It may be removed, left empty, or remain as an incomplete file depending on implementation details and when the operation was interrupted.

The important application rule is that an aborted file must never be reported as a completed export.

Handling picker cancellation

The user can also cancel the save dialog before the export begins.

This normally appears as an AbortError.

The project distinguishes this expected case from operational failures:

isAbortError(error) {
  return Boolean(
    error
    && (
      error.name === "AbortError"
      || /abort|cancel/i.test(
        this.errorMessage(error)
      )
    )
  );
}

The main export method maps it to the cancelled state:

catch (error) {
  if (
    this.isAbortError(error)
    || this.cancelRequested
  ) {
    this.status = "cancelled";
    this.addLog(
      "Export cancelled. The destination file was not finalized."
    );
  } else {
    this.status = "error";
    this.addLog(
      `Error: ${this.errorMessage(error)}`
    );
  }
}

Cancelling a picker is not a system failure.

The user simply decided not to continue.

Treating it as a normal cancellation produces a better interface than displaying a red error message.

The Blob fallback

The application detects native file picker support with:

const supportsFileSystemAccess =
  "showSaveFilePicker" in window;

The complete support object is:

support: {
  secureContext: window.isSecureContext,
  fileSystemAccess:
    "showSaveFilePicker" in window,
  streams:
    "ReadableStream" in window
    && "WritableStream" in window
}

When the native picker is unavailable, the application switches to Blob mode:

if (!this.support.fileSystemAccess) {
  this.exportMode = "blob";
  this.addLog(
    "File System Access API unavailable: Blob fallback enabled."
  );
}

The fallback uses BlobWriter:

async exportAsBlob() {
  this.status = "running";
  const blobWriter =
    new zip.BlobWriter("application/zip");
  const zipWriter =
    this.createZipWriter(blobWriter);
  await this.addEntries(zipWriter);
  const archiveBlob =
    await zipWriter.close();
  this.lastRun.outputBytes =
    archiveBlob.size;
  this.downloadBlob(
    archiveBlob,
    this.archiveName
  );
}

The download helper creates a temporary object URL:

downloadBlob(blob, fileName) {
  const url = URL.createObjectURL(blob);
  const anchor = document.createElement("a");
  anchor.href = url;
  anchor.download = fileName;
  anchor.rel = "noopener";
  anchor.style.display = "none";
  document.body.appendChild(anchor);
  anchor.click();
  anchor.remove();
  window.setTimeout(
    () => URL.revokeObjectURL(url),
    30_000
  );
}

The URL is not revoked immediately after click().

A short delay gives the browser enough time to begin handling the download before the reference is released.

The fallback maintains functionality on more browsers, but it does not reproduce the memory characteristics of direct streaming.

This distinction is explicitly shown in the interface.

Permissions and security

The name “File System Access API” can create the wrong impression.

A web page does not receive unrestricted access to the user’s computer.

For the picker-based workflow:

The page requests a picker. 1.

The browser displays a user-controlled dialog.
The user selects a file destination.
The page receives a handle for that selected file.
The page can write through the granted handle.

Access is explicitly gated by the picker. The specification also recommends that browsers restrict sensitive files and directories, including system locations and browser data directories.

The project never receives a traditional absolute path such as:

C:\Users\Name\Documents\archive.zip

or:

/home/name/Documents/archive.zip

The browser returns an opaque handle.

This separation prevents the application from depending on operating-system-specific path structures and limits what the site can access.

The project also normalizes suggested archive names:

normalizeArchiveName() {
  const cleaned = (
    this.archiveName
    || "streamzip-export.zip"
  ).replace(
      /[\\/:*?"<>|\u0000-\u001f]/g,
      "_"
    ).trim();
  this.archiveName =
    cleaned.toLowerCase().endsWith(".zip")? cleaned: `${cleaned || "streamzip-export"}.zip`;
}

This is not a replacement for browser security.

It is an application-level measure that avoids suggesting names containing characters commonly invalid on desktop operating systems.

The browser still has the final authority over accepted names and destinations.

Secure contexts

Powerful browser capabilities generally require a secure context.

The project checks:

window.isSecureContext

For development, the recommended setup is a local HTTP server:

python -m http.server 8000

The application can then be opened at:

http://localhost:8000

Localhost is treated as a trustworthy development context by modern browsers.

For production, the application should be served over HTTPS.

Opening the HTML file directly from the filesystem is not the best testing method because browser behavior, module loading, security policies, and file API support may differ from a normal hosted environment.

A local server also more closely represents how the project will behave after deployment.

Application state

The project uses an explicit state machine:

idle
preparing
running
success
cancelled
error

The states are reflected in both the interface and the export logic.

At the beginning of a run:

this.status = "preparing";

After the destination is authorized:

this.status = "running";

When the archive is finalized:

this.status = "success";

An expected interruption produces:

this.status = "cancelled";

An unexpected exception produces:

this.status = "error";

This separation prevents several interface problems:

starting two exports at the same time;
removing files during compression;
enabling the export button without files;
showing success after cancellation;
leaving a file marked as running after an error.

The busy state is computed from the current status:

isBusy() {
  return this.status === "preparing"
    || this.status === "running";
}

Buttons and inputs bind their disabled state to this value.

Duplicate and unsafe filenames

Multiple selected files can have the same name.

This is common when files are selected from different directories.

A ZIP archive can technically contain duplicate names, but the extraction behavior can be confusing. Some tools overwrite one entry, while others show both.

StreamZIP Lab generates unique archive names:

photo.jpg
photo (2).jpg
photo (3).jpg

The logic separates the base name from the extension and increments a counter until an unused name is found.

It also replaces characters that commonly create cross-platform filename problems.

This does not preserve the original directory hierarchy because the project receives a flat file selection.

A future version could use directory selection and store relative paths inside the archive.

That extension would require additional care to prevent unsafe archive paths such as ../, absolute paths, or platform-specific traversal patterns.

Technical logging

The application includes a small log panel.

Typical messages are:

Added 4 file(s) (1.8 GB).
Starting export in Stream to disk.
Destination authorized: streamzip-export.zip.
document.txt: DEFLATE (potentially compressible content).
video.mp4: STORE (already compressed format).
Archive completed successfully.

Logging is particularly useful for browser APIs because the user may otherwise see only a generic failure.

The log helps distinguish between:

CDN loading errors;
picker cancellation;
missing secure context;
unsupported streams;
compression failure;
destination write failure;
explicit cancellation.

The application limits the log to 80 entries:

if (this.logs.length > 80) {
  this.logs.length = 80;
}

This prevents an indefinitely growing reactive array during repeated tests.

The three project files

index.html

index.html contains the Vue template and external scripts.

The interface is divided into:

browser support;
file selection;
export configuration;
progress;
technical log;
educational explanations.

Because the global Vue build compiles templates in the browser, directives can be written directly in the HTML:

<button
  class="button button-primary"
  type="button"
  @click="exportArchive":disabled="!canExport"
>
  Export ZIP archive
</button>

Reactive values are displayed with normal Vue interpolation:

<strong>{{ overallPercent }}%</strong>

styles.css

styles.css implements the complete visual layer.

It contains:

the responsive page layout;
drag-and-drop states;
form controls;
file status chips;
progress bars;
warning panels;
technical metrics;
archive structure diagrams;
accessible hidden labels.

The CSS is deliberately independent from a component framework.

This keeps the project free from another runtime dependency and makes it possible to study the application state without utility-class noise.

functions.js

functions.js contains:

Vue initialization;
file management;
filename normalization;
format detection;
compression selection;
picker integration;
stream adaptation;
ZIP generation;
progress calculation;
cancellation;
Blob downloads;
error handling;
logging;
size formatting.

The entire JavaScript file is wrapped in an immediately invoked function:

(() => {
  "use strict";
  // Application code
})();

This prevents project constants and helper functions from being added directly to the global scope.

Vue and zip.js remain global because they are loaded through classic script tags.

Testing the project

A useful test plan should include several different file types and sizes.

Test 1: compressible text

Select a large .txt, .csv, or .json file.

Expected result:

Strategy: DEFLATE

The final archive should be significantly smaller if the input contains repeated data.

Test 2: JPEG image

Select a .jpg file.

Expected result:

Strategy: STORE

The ZIP output should be only slightly larger than the image because the ZIP still needs headers and directory records.

Test 3: MP4 video

Select a large .mp4 file.

Expected result:

Strategy: STORE

This is a good test for progressive writing because the input may be large while additional compression is unnecessary.

Test 4: forced compression

Choose DEFLATE all files and export the same JPEG or MP4.

Compare:

elapsed time;
output size;
CPU usage;
responsiveness.

In many cases, the additional work produces very little size reduction.

Test 5: Blob mode

Export the same set of files through Blob mode.

Observe that the browser download starts only after the complete archive has been created.

Test 6: cancellation

Begin exporting a large file and press Cancel export.

The interface should enter the cancelled state and the archive should not be reported as complete.

Test 7: unsupported API

Run the application in a browser without showSaveFilePicker() support.

The destination option should automatically fall back to Blob mode.

Test 8: duplicate names

Select several files with identical names from different directories.

The application should assign unique ZIP entry names.

Test 9: ZIP64

Force ZIP64 and verify the result with an archive utility that exposes format details.

For a real automatic ZIP64 test, the project needs either a very large entry, a very large archive, or more than 65,535 entries.

Limitations of the current implementation

StreamZIP Lab is intentionally small, so it has several limitations.

Browser support

The native picker is not available in every browser.

Feature detection is mandatory, and Blob fallback remains necessary.

CDN dependency

Vue and zip.js are loaded from a CDN.

The application therefore requires network access on its first load unless those files are cached externally.

A real offline PWA should self-host or precache pinned library versions.

No directory hierarchy

The project accepts a flat list of files.

It does not currently reproduce directory structures inside the ZIP.

Progress is based on input bytes

The displayed percentage represents source processing, not exact destination bytes.

No persistent handles

The file handle is used only for the current operation.

The project does not store it in IndexedDB for later reuse.

No encryption

The generated archive is not password-protected or encrypted.

No integrity verification after writing

The project trusts successful completion of the ZIP writer and destination stream.

It does not reopen the final archive and verify every entry.

Main interface and compression workload

zip.js can use workers, but very large or complex workloads still require testing on low-end devices.

Production applications should measure responsiveness under realistic conditions.

Improvements for a production PWA

The project could be extended in several directions.

Add a manifest and service worker

This would turn the browser lab into an installable PWA.

The service worker could cache:

index.html;
styles.css;
functions.js;
Vue;
zip.js;
icons and manifest assets.

Self-host dependencies

Pinned local library files would reduce CDN dependency and simplify a strict Content Security Policy.

Add directory selection

showDirectoryPicker() could be used to recursively collect files and preserve their relative paths.

Persist authorized handles

File and directory handles can be stored for workflows where the user returns to the same export destination.

Permission state must still be checked when the application starts again.

Add per-file compression controls

The user could override automatic decisions for individual files.

Add a worker-based orchestration layer

A dedicated worker could coordinate preprocessing, checksums, metadata generation, or transformations without blocking interface updates.

Add output verification

After writing, the application could reopen the archive, read its central directory, and verify expected names, sizes, and CRC values.

Add reproducible benchmarks

A benchmark mode could compare streaming and Blob output using:

identical inputs;
compression level;
elapsed time;
JavaScript heap measurements where available;
output size;
browser version;
device information.

The current risk indicator is educational. It is not a substitute for controlled performance measurements.

Final thoughts

StreamZIP Lab started as a small experiment with showSaveFilePicker(), but building the export workflow required considering several connected topics:

browser memory behavior;
stream backpressure;
user activation;
filesystem permissions;
ZIP record structure;
ZIP64 limits;
compression strategy;
progress semantics;
cancellation;
compatibility fallbacks.

The most important architectural difference is not simply replacing one API call with another.

Blob output and streaming output represent two different lifecycle models.

With a Blob, the application normally completes the artifact first and delivers it afterward.

With streaming, generation and persistence happen at the same time.

For large browser-generated files, this difference can determine whether the export is practical at all.

The File System Access API makes browser applications feel closer to desktop software, but it keeps the user in control through explicit file pickers and permission boundaries.

Combined with Web Streams and a ZIP implementation that supports progressive output, it becomes possible to create large archives without intentionally materializing the complete result as one application-managed Blob.

The Blob fallback is still valuable for compatibility.

The main design principle is to treat it as a fallback with different memory characteristics, not as an equivalent implementation.

The complete source code is available here:

https://github.com/sfestacatenate/StreamZipLab_Vue_Javascript

Thank you for reading!

Building a Linear Regression PWA with React

CertosinoLab — Thu, 23 Jul 2026 15:46:46 +0000

From a CSV file to an interactive chart, entirely in the browser

Linear regression is one of the simplest statistical techniques, but it is also a useful example of how data processing, mathematics and visualization can be combined in a modern web application.

In this project, I built a Progressive Web App with React that allows users to upload a CSV file containing pairs of X and Y values. The application processes the data, calculates a linear regression model, displays the resulting equation and plots both the original observations and the regression line.

The technology stack

The application was created with React and Vite. A few focused libraries handle the main features:

Papa Parse reads and processes the uploaded CSV file.
Chart.js and react-chartjs-2 display the dataset and regression line.
KaTeX renders the regression equation in mathematical notation.
vite-plugin-pwa adds the web app manifest, service worker and installable PWA functionality.

Everything runs directly in the browser. The CSV file does not need to be uploaded to a server, which keeps the application simple and preserves the privacy of the data.

Parsing the CSV data

When the user selects a file, Papa Parse reads its rows. The application treats the first two values of each row as the X and Y coordinates:

const parsedData = result.data
  .map((row) => ({
    x: parseFloat(row[0]),
    y: parseFloat(row[1]),
  }))
  .filter((point) => !isNaN(point.x) && !isNaN(point.y));

Invalid or non-numeric rows are filtered out. Once the data has been cleaned, it is stored in the React state and passed to the regression function.

Calculating the regression line

The application implements ordinary least squares directly in JavaScript. It calculates the sums of X, Y, XY and X², and then uses them to obtain the slope and intercept:

slope = (nΣxy − ΣxΣy) / (nΣx² − (Σx)²)

intercept = (Σy − slopeΣx) / n

The final model has the familiar form:

y = slope × x + intercept

The code also determines the minimum and maximum X values in the dataset. These values are used to generate the two endpoints of the regression line, avoiding the need to calculate a separate fitted point for every observation.

Visualizing the result

The graph is rendered through react-chartjs-2. One dataset represents the original observations as individual points, while a second dataset represents the fitted regression line.

Although the React Line component is used, the original dataset has showLine set to false. This produces a scatter-style visualization, while the regression dataset remains a continuous line.

The application also displays the minimum and maximum values of both variables and renders the regression equation with KaTeX. A small conversion function attempts to represent decimal coefficients as fractions, making the output easier to read in some datasets.

Making predictions

After calculating the model, users can enter a new X value. The application applies the previously calculated slope and intercept and returns the expected Y value:

const y = slope * x + intercept;

This turns the project from a static visualization into a simple interactive prediction tool.

Turning it into a PWA

The PWA configuration is handled through vite-plugin-pwa. The project defines an application manifest, installable icons, a standalone display mode and an automatic service-worker update strategy.

Static assets such as JavaScript, CSS, HTML and images are cached through Workbox. As a result, the application can be installed on supported devices and continue to work even when the network connection is unavailable.

Final thoughts

This project demonstrates that a useful data-analysis application does not always require a backend or a large machine-learning framework.

With React, a CSV parser and a charting library, it is possible to create a lightweight tool that imports data, performs a real statistical calculation, visualizes the results and works as an installable application.

The complete source code is available in the project’s public GitHub repository:
https://github.com/sfestacatenate/React_PWA_Linear_Regression

Link to the project:
https://pwa-linear-regression-react.surge.sh

Exploring Database-First Approach with Entity Framework in .NET Core 6

CertosinoLab — Fri, 16 Jun 2023 09:52:19 +0000

Exploring Database-First Approach with Entity Framework in .NET Core 6

Introduction: In the world of software development, the efficient management of databases is crucial for the success of any application.

Dotnet Core 6 provides powerful tools and features for working with databases. One popular approach is the database-first approach, which allows developers to design their database schema first and then generate the corresponding models and context using the Entity Framework. In this article, we will explore how to utilize the Entity Framework in a database-first manner using .NET Core 6.

Step 1: Generating the Database Script for Microsoft SQL Server

To demonstrate the database-first approach, let’s consider the example of an ecommerce application. The database for this application consists of the following tables:

Products
Customers
Orders
Order_Details
Product_Categories
Categories

-- Create Products table
    CREATE TABLE Products (
        ProductId INT PRIMARY KEY,
        Name NVARCHAR(100) NOT NULL,
        Price DECIMAL(10, 2) NOT NULL,
        Description NVARCHAR(MAX)
    );

    -- Create Customers table
    CREATE TABLE Customers (
        CustomerId INT PRIMARY KEY,
        FirstName NVARCHAR(50) NOT NULL,
        LastName NVARCHAR(50) NOT NULL,
        Email NVARCHAR(100) NOT NULL
    );

    -- Create Orders table
    CREATE TABLE Orders (
        OrderId INT PRIMARY KEY,
        CustomerId INT NOT NULL,
        OrderDate DATETIME NOT NULL,
        TotalAmount DECIMAL(10, 2) NOT NULL,
        FOREIGN KEY (CustomerId) REFERENCES Customers(CustomerId)
    );

    -- Create Order_Details table
    CREATE TABLE Order_Details (
        OrderId INT NOT NULL,
        ProductId INT NOT NULL,
        Quantity INT NOT NULL,
        Price DECIMAL(10, 2) NOT NULL,
        PRIMARY KEY (OrderId, ProductId),
        FOREIGN KEY (OrderId) REFERENCES Orders(OrderId),
        FOREIGN KEY (ProductId) REFERENCES Products(ProductId)
    );

    -- Create Categories table
    CREATE TABLE Categories (
        CategoryId INT PRIMARY KEY,
        Name NVARCHAR(50) NOT NULL
    );

    -- Create Product_Categories table
    CREATE TABLE Product_Categories (
        ProductId INT NOT NULL,
        CategoryId INT NOT NULL,
        PRIMARY KEY (ProductId, CategoryId),
        FOREIGN KEY (ProductId) REFERENCES Products(ProductId),
        FOREIGN KEY (CategoryId) REFERENCES Categories(CategoryId)
    );

Step 2: Create a new Visual Studio Project and install necessary packages

In Visual Studio Community 2022 create for example a Console Application, select .NET 6.0. Now install Entity Framework Packages, we need to install several packages using NuGet. Follow these steps to install the required packages in Visual Studio Community 2022:

Open your project in Visual Studio Community 2022.
Right-click on the project in the Solution Explorer and select “Manage NuGet Packages.”
In the NuGet Package Manager window, search for the following packages one by one:

Microsoft.EntityFrameworkCore
Microsoft.EntityFrameworkCore.Design
Microsoft.EntityFrameworkCore.SqlServer
Microsoft.EntityFrameworkCore.Tools

Select each package and click on the “Install” button to install them into your project.

Step 3: Generating Models and Context Using Scaffold-DbContext

Once the necessary packages are installed, we can generate the models and the database context using the Scaffold-DbContext command. This command helps in automatically scaffolding the entity types for the existing database schema.

Create the Models directory, you can choose any name of course
Open the Package Manager Console by navigating to “Tools” -> “NuGet Package Manager” -> “Package Manager Console.”
In the Package Manager Console, run the following command:

PM> Scaffold-DbContext "Data Source=localhost\SQLEXPRESS;Initial Catalog=ecommerce;Integrated Security=True;TrustServerCertificate=True;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir Models

The Scaffold-DbContext command will examine the database schema and generate the corresponding model classes and the database context. These generated classes will be placed in the specified output directory (Models in this case).

Conclusion

By following the above steps, we have explored the database-first approach using Entity Framework in .NET Core 6. We started by creating a database script for an ecommerce application and defined the necessary relationships. Then, we installed the required Entity Framework packages using NuGet in Visual Studio Community 2022. Finally, we utilized the Scaffold-DbContext command to automatically generate the model classes and the database context based on the existing database schema.

Utilizing the Entity Framework in a database-first manner allows developers to seamlessly integrate their existing databases with their .NET Core applications. This approach simplifies the development process by eliminating the need for manual creation of models and context classes, saving time and effort. With .NET Core 6 and Entity Framework, developers can build robust and scalable applications with ease.

Thank you!

Basic Text Analysis with Python and MongoDB

CertosinoLab — Sun, 07 May 2023 23:50:41 +0000

Introduction

Have you ever needed to analyze unstructured text data? Python can help you do just that. In this article, we’ll look at a basic example of parsing unstructured text data located in MongoDB using Python.

Let’s Write the Code

First, let’s connect to a MongoDB client and retrieve all the documents from a collection in our database:

import pymongo
import re
from matplotlib import pyplot as plt

# Connect to a MongoDB client
client = pymongo.MongoClient("mongodb://localhost:27017/")
db = client["your_db"]
col = db["your_collection"]

Next, we’ll create an empty string that will contain all the offer details from each document:

# Create an empty string that contains all texts
all_details_string = ''

# Iterate over all documents in your MongoDB instance
for doc in col.find():
    all_details_string = all_details_string + doc.get('offer_details').upper()

# Create a list containing all words
doc_general = re.split(" |/|\n", all_details_string)

# Get all words count
all_words_count = len(doc_general)
print('Total Occurrences:', all_words_count)

# Set technologies to analise
tec_list = ['Java', 'C#', 'Angular', 'React']
count_list = []

On the list of the technologies we want to analyze, iterate through each one, counting the number of occurrences in the concatenated string and adding the count to our list:

for tec in tec_list:
    count_list.append(doc_general.count(tec.upper()))
    print(tec, 'Total Occurrences:', doc_general.count(tec.upper()))

In my environment, i got the following result:

Finally, we’ll create a bar chart using the Matplotlib library, with the technologies on the x-axis and their respective counts on the y-axis:

# Create a bar chart
labels = tec_list
values = count_list
fig, ax = plt.subplots()
ax.bar(labels, values)

# Add labels and title
ax.set_ylabel('Occurrence')
ax.set_xlabel('Technology')
ax.set_title('Occurrences of the chosen technologies')

# Show the chart
plt.show()

Complete code and final thoughts

By analyzing unstructured text data, we can gain insights into the most common words and topics. This can be useful for a wide range of applications, such as sentiment analysis, topic modeling, and more.

Here the full code:

import pymongo
import re
from matplotlib import pyplot as plt

# Connect to a MongoDB client
client = pymongo.MongoClient(“mongodb://localhost:27017/”)
db = client[“your_db”]
col = db[“your_collection”]

# Create an empty string that contains all texts
all_details_string = ‘’
list_detail_offer = []

# Iterate over all documents in your MongoDB instance
for doc in col.find():
 all_details_string = all_details_string + doc.get(‘offer_details’).upper()

# Create a list containing all words
doc_general = re.split(“ |/|\n”, all_details_string)

# Get all words count
all_words_count = len(doc_general)
print(‘Total Occurrences:’, all_words_count)

# Set technologies to analise
tec_list = [‘Java’, ‘C#’, ‘Angular’, ‘React’]
count_list = []
for tec in tec_list:
 count_list.append(doc_general.count(tec.upper()))
 print(tec, ‘Total Occurrences:’, doc_general.count(tec.upper()))

# Create a bar chart
labels = tec_list
values = count_list
fig, ax = plt.subplots()
ax.bar(labels, values)

# Add labels and title
ax.set_ylabel(‘Occurrence’)
ax.set_xlabel(‘Technology’)
ax.set_title(‘Occurrences of the chosen technologies’)

# Show the chart
plt.show()

Thank you!

Find occurrences of a word in a Pdf file with c# and PdfPig

CertosinoLab — Sun, 07 May 2023 17:11:59 +0000

Introducing PdfPig

PdfPig is an open source C # library that allows us to extract text and other content from pdfs. Its a port of the java pdfbox library. You can find more here: https://github.com/UglyToad/PdfPig

The Word Counter

The project will be a simple console application and will have the following structure:

Creating The Project

With Visual Studio 2022, follow the steps below:

Open Visual Studio 2022
Create New Project
Select Console Application in C#
Set Name and Path
Choose .NET 5.0 Framework

Now you have the basic structure of a console application. Create a folder and call it pdf. Add a pdf inside this folder. In this tutorial i used a pdf created from this page: https://en.wikipedia.org/wiki/Cr%C3%AApe

To get PdfPig:

On the search bar print Manage NuGet Packages
Click on Browse
Search PdfPig
Install It

The Code

Thanks to PdfPig extracting text from the pdf and calculating the occurrences of a word is trivial, here the full code:

using System;
using UglyToad.PdfPig;
using UglyToad.PdfPig.Content;

namespace pdf_pig_word_counter
{
    internal class Program
    {
        static void Main(string[] args)
        {
            string wordToFind = "pancake";
            int numberOfOccurrences = 0;

using (PdfDocument document = PdfDocument.Open(@"YOUR PATH\pdf\test.pdf"))
            {
                foreach (Page page in document.GetPages())
                {
                    string pageText = page.Text;

foreach (Word word in page.GetWords())
                    {
                        if (word.Text.ToLower().Contains(wordToFind.ToLower()))
                            numberOfOccurrences++;
                    }
                }
                Console.WriteLine("Total Occurrences: " + numberOfOccurrences);
            }
        }

}
}

This program will tell us how many times the word pancake is present in the pdf.

You can find the project here: https://github.com/CertosinoLab/mediumarticles/tree/pdf_pig_word_counter

Thank you!

Using Event Bus in Vue.js 3

CertosinoLab — Sun, 07 May 2023 16:02:31 +0000

Introduction

In vue js we have essentially three ways of making unrelated components communicate with each other:

Vuex
Pinia
Event Bus

On the official documentation we can read:

In most circumstances, using a global event bus for communicating between components is discouraged. While it is often the simplest solution in the short term, it almost invariably proves to be a maintenance headache in the long term.

So generally in the long run it is better to use vuex.

Also in the official documentation you can see how the Event Bus implementation has changed from Vue 2 to Vue 3

Scaffolding the project

In this tutorial we will use Vite build tool to scaffold the project

# npm 6.x
npm init vite@latest vue-event-bus-1 --template vue

# npm 7+, extra double-dash is needed:
npm init vite@latest vue-event-bus-1 -- --template vue

then we need to install an external library implementing the event emitter interface, in this case mitt

npm install --save mitt

The Project

The project consists of two simple components, FirstComponent.vue and SecondComponent.vue, when we click on the emit event button in SecondComponent.vue String to change in **FirstComponent.vue **becomes String changed thanks to the Event Bus

The Code

In **main.js **we create an instance of mitt which is used globally

import { ***createApp ***} from 'vue'
import mitt from 'mitt'
import App from './App.vue'


const emitter = mitt()
const app = ***createApp***(App)

app.config.globalProperties.emitter = emitter
app.mount('#app')

Now we can access emitter globally, so in FirstComponent.vue we subscribe to the event emitted by SecondComponent.vue.

Let’s take a look to FirstComponent.vue

<script>
export default {
  data: function () {
    return {
      testEvent: 'String to change'
    }
  },
  created (){
    this.emitter.on('my-event', (evt) => {
      this.testEvent = evt.eventContent;
    })
  }
}
</script>

Now in **SecondComponent.vue **let’s emit the event

<template>

    <div style="border: 1px solid black;">

        <h1>Second Component</h1>

        <button v-on:click="emitMyEvent">Emit Event</button>

    </div>

</template>

<script>

    export default {

        methods: {

          emitMyEvent() {

              this.emitter.emit('my-event', {'eventContent': 'String changed'})

          }

        }

    }

</script>

Github

You can find the code of this tutorial on github: CertosinoLab/mediumarticles at vue-event-bus-1 (github.com)

Thank you for reading!

DEV Community: CertosinoLab

Building AI Prompt Lab with Java 21, Spring Boot and React 19

The project

Technology stack

Backend

Frontend

Backend architecture

Prompt management

Authentication and authorization

PostgreSQL and schema management

OpenRouter integration

Handling external API credentials

The React frontend

A dedicated API layer

The chat flow

Why I kept the architecture simple

Possible extensions

Prompt categories and tags

Prompt versioning

Streaming responses

Multiple AI providers

Conversation persistence

Usage metrics

Conclusion

Source Code

Next.js + NestJS: Useful Architecture or Unnecessary Complexity?

Start with Next.js alone

So when does NestJS start to make sense?

Case 1: Multiple clients use the same backend

Case 2: Background jobs become important

Case 3: Your business logic is getting complicated

Case 4: The backend must scale independently

The hidden cost of adding NestJS

A simple rule

Final thought

C# 15 Finally Gets Labeled `break` and `continue`

The problem with a normal break

C# 15: name the loop

It also works with continue

What about goto?

break and continue aren't identical

Should you start labeling every loop?

Trying it today

Lazy Load Angular Services with `injectAsync()

The usual approach

Enter injectAsync()

Your service must be auto-provided

You can also prefetch it

When should you use it?

Final thought

How to Sync Two Browser Tabs with JavaScript

The HTML

Create a BroadcastChannel

Receive messages from other tabs

What is actually happening?

You can send more than numbers

Same origin only

When is this useful?

Closing the channel

Final thought

JavaScript Finally Fixed Summation — But 0.1 + 0.2 Is Still Broken

The problem with the way we usually sum numbers

Meet Math.sumPrecise()

Why did reduce() return zero?

What Math.sumPrecise() does differently

Does it fix 0.1 + 0.2?

Math.sumPrecise() can't fix numbers that were already approximate

So when is Math.sumPrecise() actually useful?

Should we stop using reduce() for sums?

One important warning: money

A couple of surprising edge cases

Can I use it today?

reduce() vs Math.sumPrecise()

JavaScript didn't fix floating point. It fixed summation.

Streaming Large ZIP Archives in the Browser with Vue and the File System Access API

What the project does

The technology stack

The traditional Blob export pattern

A Blob is not exactly the same as memory

Why streaming changes the architecture

The problem with a normal `break`

It also works with `continue`

What about `goto`?

`break` and `continue` aren't identical

Enter `injectAsync()`

Meet `Math.sumPrecise()`

Why did `reduce()` return zero?

What `Math.sumPrecise()` does differently

Does it fix `0.1 + 0.2`?

`Math.sumPrecise()` can't fix numbers that were already approximate

So when is `Math.sumPrecise()` actually useful?

Should we stop using `reduce()` for sums?

`reduce()` vs `Math.sumPrecise()`