Forem: BysonTech

How JavaScript Async Actually Works (Event Loop, Micro tasks, and Call Stack)

BysonTech — Wed, 08 Apr 2026 23:50:06 +0000

If you have ever thought:

Why does Promise.then() run before setTimeout?
Why does await run “later” even though it looks synchronous?
What is actually happening behind async / await?

then you are ready to understand how JavaScript async really works.

When I first struggled with “why a Promise is returned”, I realized that I could not go further without understanding the internal mechanism.

In JavaScript, async behavior is built on these five concepts:

Call Stack
Web APIs
Task Queue
Microtask Queue
Event Loop

Promise and async / await are just built on top of this system.

Let’s break it down step by step.

1. JavaScript Is Single-Threaded

JavaScript can execute only one thing at a time.

Example:

console.log("A")
console.log("B")
console.log("C")

Output:

A  
B  
C

This order is controlled by the Call Stack.

2. What Is the Call Stack?

The call stack is:

a stack that keeps track of currently executing functions

It follows LIFO (Last In, First Out).

Example:

function main() {
  a()
}

function a() {
  b()
}

function b() {
  console.log("hello")
}

main()

Execution order:

1 main()  
2 a()  
3 b()  
4 console.log()

The stack grows as functions are called and shrinks as they finish.

3. The Problem: Long-Running Tasks

Now consider this:

console.log("start")

setTimeout(() => {
  console.log("timeout")
}, 0)

console.log("end")

Output:

start  
end  
timeout

Why does setTimeout run later, even with 0ms?

This is where Web APIs come in.

4. Web APIs

JavaScript engines (like V8) do not handle timers or network requests.

Features like:

setTimeout
fetch

are provided by the browser (or runtime environment).

Flow:

setTimeout is called
It is handed off to Web APIs
Timer starts outside the call stack
JavaScript continues execution

5. Task Queue

When the timer finishes, the callback is not executed immediately.

It is placed into the:

Task Queue (Macrotask Queue)

This is a queue of functions waiting to be executed.

6. Event Loop

The event loop is:

a mechanism that checks if the call stack is empty

Flow:

Run everything in the call stack
When empty → take one task from the task queue
Push it to the call stack
Repeat

7. Full Async Flow

Example:

console.log("A")

setTimeout(() => {
  console.log("B")
}, 0)

console.log("C")

Execution:

A  
C  
B

Why:

A runs
setTimeout registers callback
C runs
call stack becomes empty
event loop pushes task
B runs

8. Promise Is Special

Here is the important part:

Promise.then() does NOT use the normal task queue.

It uses a different queue called:

Microtask Queue

9. Microtasks vs Tasks

JavaScript has two queues:

Task Queue (Macrotasks)

setTimeout
setInterval
DOM events

Microtask Queue

Promise.then
catch
finally
queueMicrotask

Key rule:

Microtasks run before tasks

10. Example

console.log("start")

setTimeout(() => {
  console.log("timeout")
}, 0)

Promise.resolve().then(() => {
  console.log("promise")
})

console.log("end")

Output:

start  
end  
promise  
timeout

Because microtasks run first.

11. Event Loop Order (Important)

The real execution order:

Run call stack
Run ALL microtasks
Run ONE task
Run microtasks again
Repeat

This is the core rule.

12. What async Really Does

async function test() {
  return 1
}

This is actually:

Promise.resolve(1)

So:

async = function that returns a Promise

13. What await Really Does

Example:

async function main() {

  console.log("A")

  const value = await Promise.resolve(1)

  console.log("B")

}

main()

console.log("C")

Output:

A  
C  
B

Why?

Because:

await splits the function into two parts using Promise.then

14. Mental Model of await

This:

async function main() {
  const value = await getData()
  console.log(value)
}

is conceptually:

getData().then(value => {
  console.log(value)
})

15. await Splits Execution

Example:

async function main() {

  console.log("1")

  await Promise.resolve()

  console.log("2")

}

console.log("3")

main()

console.log("4")

Output:

Everything after await becomes a microtask.

16. Another Example

console.log("A")

async function test() {

  console.log("B")

  await Promise.resolve()

  console.log("C")

}

test()

console.log("D")

Output:

A  
B  
D  
C

17. Key Insight About await

await does NOT block the thread

It just:

splits the function and schedules the rest as a microtask

18. Sequential vs Parallel

Sequential:

const a = await fetchA()
const b = await fetchB()

Parallel:

const [a, b] = await Promise.all([
  fetchA(),
  fetchB()
])

Important:

Parallelism depends on when the Promise starts, not when you await it

19. Why This Matters

If you write:

const a = await fetchA()
const b = await fetchB()

then:

fetchA runs
wait
fetchB runs

But if you write:

const aPromise = fetchA()
const bPromise = fetchB()

const a = await aPromise
const b = await bPromise

both start immediately.

20. Big Picture

JavaScript async is built on:

Call Stack → current execution
Web APIs → timers, network
Task Queue → setTimeout
Microtask Queue → Promise
Event Loop → orchestrates everything

21. Final Summary

The most important ideas:

Promise → runs in microtask queue
setTimeout → runs in task queue
microtasks always run first
await → splits code into microtasks

Once you understand this, you can explain:

Why Promise runs before setTimeout
Why await runs “later”
Why sequential vs parallel happens

And at that point:

async / await stops being magic and becomes predictable.

Why JavaScript Returns a Promise: Understanding async / await from the Ground Up

BysonTech — Sun, 05 Apr 2026 06:50:17 +0000

If you have ever written async JavaScript and wondered:

Why is this returning a Promise?
Why can’t I get the value immediately?
What exactly is async / await doing?

you are not alone.

Many developers use Promise and async / await without fully understanding what is happening under the hood. I was the same way at first.

This article breaks it down in a simple, practical way.

1. What Synchronous Code Means

JavaScript runs code from top to bottom, in order.

This is called synchronous execution.

Example:

console.log("A");
console.log("B");
console.log("C");

Output:

A  
B  
C

2. Why Asynchronous Code Exists

Some operations take time:

API calls
File reading
Database access
User input
Timers

If these were all synchronous, the UI would freeze.

So JavaScript allows code to continue running without waiting for these operations to finish.

That is asynchronous processing.

Example:

console.log("Start");

setTimeout(() => {
  console.log("After 3 seconds");
}, 3000);

console.log("End");

Output:

Start  
End  
After 3 seconds

The callback runs later, so "End" appears first.

3. What a Promise Actually Is

A Promise solves one core problem:

How do we handle a result that is not available yet?

A Promise is:

a value that will be available in the future

You can think of it as a placeholder.

Promise States

A Promise has three states:

pending → still running
fulfilled → success
rejected → failure

When the state changes, then() or catch() runs.

Example

function task() {
  return new Promise((resolve, reject) => {
    const success = true;

    if (success) {
      resolve("Success");
    } else {
      reject("Failure");
    }
  });
}

task()
  .then((result) => console.log(result))
  .catch((error) => console.log(error));

4. Why You Don’t Get the Value Immediately

This is the most important point.

function getData() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("OK"), 2000);
  });
}

const data = getData();
console.log(data);

Output:

Promise { <pending> }

The value is not ready yet.

A Promise is not the value — it is a future value.

5. Promise Chaining

You can chain asynchronous steps:

getData()
  .then((data) => {
    console.log(data);
    return "Next step";
  })
  .then((msg) => console.log(msg))
  .catch((error) => console.log(error));

This works, but can become hard to read.

That is why async / await exists.

6. What `async` Means

async means:

this function always returns a Promise

Example:

async function test() {
  return "hello";
}

This is the same as:

Promise.resolve("hello")

7. What `await` Means

await means:

wait for a Promise and return its value

Example:

function getData() {
  return new Promise((resolve) => {
    setTimeout(() => resolve("Data"), 2000);
  });
}

async function main() {
  const data = await getData();
  console.log(data);
}

main();

await pauses the function, not the whole program.

8. Promise vs async / await

Promise:

getData()
  .then((data) => console.log(data))
  .catch((error) => console.log(error));

async / await:

async function main() {
  try {
    const data = await getData();
    console.log(data);
  } catch (error) {
    console.log(error);
  }
}

async / await is just a cleaner way to write Promise-based code.

9. Error Handling

With Promise → catch()

With async → try / catch

async function main() {
  try {
    const data = await getData();
  } catch (error) {
    console.log(error);
  }
}

10. Parallel Processing

Sequential:

const a = await fetchA();
const b = await fetchB();

Parallel:

const [a, b] = await Promise.all([
  fetchA(),
  fetchB()
]);

11. Promise.allSettled

If you need all results:

const results = await Promise.allSettled([
  task1(),
  task2()
]);

12. fetch with async / await

async function getUsers() {
  const response = await fetch("/api/users");

  if (!response.ok) {
    throw new Error("Request failed");
  }

  const data = await response.json();

  return data;
}

Two steps:

Wait for response
Wait for JSON parsing

13. Common Mistakes

async returns a Promise

async function test() {
  return 123;
}

const x = test(); // Promise

await outside async

function main() {
  const x = await test(); // Error
}

Missing error handling

async function main() {
  const data = await getData(); // may crash
}

14. When to Use new Promise

Usually, you do not need it.

Bad:

function bad() {
  return new Promise((resolve, reject) => {
    fetch("/api/data")
      .then((res) => res.json())
      .then(resolve)
      .catch(reject);
  });
}

Good:

function good() {
  return fetch("/api/data")
    .then((res) => res.json());
}

Use new Promise mainly to wrap callback APIs:

function wait(ms) {
  return new Promise((resolve) => {
    setTimeout(resolve, ms);
  });
}

15. Real-World Pitfall

I once expected a boolean, but got a Promise.

function isWindows11OrLater() {
  return navigator.userAgentData
    .getHighEntropyValues(["platformVersion"])
    .then((ua) => {
      if (navigator.userAgentData.platform !== "Windows") {
        return false;
      }

      const version = parseInt(ua.platformVersion.split(".")[0], 10);
      return version >= 13;
    });
}

async function main() {
  const result = await isWindows11OrLater();
  console.log(result);
}

The reason:

the API itself is asynchronous, so it returns a Promise.

Summary

Promise → a future value
async → always returns a Promise
await → unwraps that value

Once this clicks, async JavaScript becomes much easier.

You will use this everywhere:

API calls
data fetching
parallel execution
error handling

Understanding Promise first makes async / await much clearer.

Designing “Just Enough” API Security for Solo Developers

BysonTech — Mon, 29 Dec 2025 02:13:12 +0000

How I Avoided Overengineering While Keeping My API Safe

API security in solo development is tricky.

It’s often unclear how far is “enough”,

which leads to either:

overengineering everything out of fear, or
leaving critical parts completely unprotected.

In my own projects, I evaluated both Firebase’s simplicity and AWS’s robustness,

but repeatedly ran into the same problems:

cost
operational complexity
long-term maintenance burden

What I eventually settled on was this idea:

Don’t aim for perfection.

Protect your API in layers.

This article summarizes what I decided to protect,

what I intentionally did not,

and why—based on actually building a small API as a solo developer.

Target Architecture

React Native (client)
Cloudflare Workers + Hono (API)
Supabase (Auth / PostgreSQL / RLS)

The API is designed to be called from multiple client applications.

Demo repository:

https://github.com/umemura-dev/hono-supabase-auth-security-demo

1. Security Was Not Clearly Defined at the Start

From the beginning, I knew security mattered.

But I didn’t know how strong it needed to be.

Once you start thinking about security,

the list of possible attacks never ends.

I found myself stuck in a loop of anxiety:

“What if this attack happens?”

“What about that scenario?”

As a result, it was difficult to move forward.

2. Deciding the Scope Before Writing Code

I realized that security design needs boundaries.

Before implementing anything, I decided to define:

what I would consider

and

what I would intentionally ignore

3. My Practical Threat Model

This was not a formal threat model.

It evolved while building the API.

What I assumed would happen

Unauthenticated requests
Invalid or malformed parameters
Requests with stolen or replayed JWTs

What I chose not to assume

Perfect secrecy of client-side code
Defenses against full reverse engineering of native apps
Stopping every possible attack at the API layer alone

As a solo developer,

I limited the scope to what I could realistically manage.

4. Moving Away from “The API Must Do Everything”

Initially, I thought:

“The API should validate everything perfectly.”

But during implementation, I realized:

bugs happen
edge cases are missed
future changes can weaken assumptions

So I changed my mindset:

Don’t rely on a single layer to be perfect.

5. Splitting Responsibilities by Layer

I ended up with the following responsibility split.

API layer (Cloudflare Workers)

Basic request validation at the entry point
JWT verification and user identification
Rejecting unexpected clients
Input validation
Lightweight rate limiting

Supabase Auth

Guaranteeing authenticated users
Providing consistent user IDs (UIDs)

Supabase RLS

Row-level access control
Protecting data even if the API layer makes mistakes

No single layer is trusted completely.

6. Why JWT Alone Was Not Enough

JWT tells you:

who the user is
whether they are authenticated

But it does not tell you:

which application sent the request
whether the client was expected

That led to this conclusion:

users and applications should be verified separately

So I added application-level verification at the API entry point.

7. Keeping Request Signing “Reasonable”

For application identification,

I use request signing (HMAC).

However, I intentionally avoided:

signing the request body
strict nonce management
perfect replay protection

Instead, I sign only:

timestamp
HTTP method
path

This was a conscious tradeoff between:

implementation cost
operational complexity
actual threat level

Also, since the secret key lives in the client (React Native),

I did not consider full HMAC-level rigor realistic for solo development.

8. RLS as the Final Line of Defense

No matter how careful the API design is,

the following will eventually happen:

bugs
refactoring mistakes
new routes added later

So I made one rule non-negotiable:

even if the API is bypassed, other users’ data must not be accessible

Supabase RLS enforces this at the database level.

9. Final Architecture (Conceptual View)

Layer 1: Client
[ React Native App ]

JWT + Signature

Layer 2: API
[ Cloudflare Workers API ]

app validation
JWT verification

Layer 3: Database
[ Supabase PostgreSQL ]

RLS enforcement

Result:
[ Authorized JSON Response ]

Even if one layer fails,

the next layer is expected to stop the request.

This layered thinking made it much easier to decide

how far security design should go.

10. Logging and Error Design

Security is not only about prevention.

It’s also about being able to investigate incidents.

In this demo API:

every request is assigned a requestId
logs are structured JSON for future aggregation
error responses to clients are minimal
internal logs clearly distinguish auth and authorization failures

At the moment, logs go to console,

but the design allows production-grade logging by simply swapping outputs.

11. Final Thoughts

While building this demo API, I learned that:

designing security “correctly” from day one is extremely difficult

What helped was changing my approach:

don’t design everything at once—decide the order.

The order that worked best for me:

Fix assumptions
- what is the client
- who are the users
Decide threat boundaries
- what must be protected
- what is acceptable to ignore
Lock down the database
- RLS to prevent cross-user access
Confirm user identity
- JWT authentication
Validate requests at the API entry
- basic validation
- reject unexpected traffic
Add application-level identification if needed
- signatures / timestamps
Throttle unintended request bursts
- rate limiting
Make issues traceable
- requestId
- structured logs

By following this sequence,

I arrived at an API design that is:

not overengineered,

but difficult to break accidentally.

I hope this article helps you decide

how far your own API security should go.

Protecting the API Entry Point with Cloudflare Workers

BysonTech — Mon, 29 Dec 2025 02:00:32 +0000

Verifying Application Authenticity Beyond JWT

In this article, I describe how I designed an API that assumes multiple client applications, using the following architecture:

React Native → Cloudflare Workers (Hono) → Supabase

A demo implementation is available here:

GitHub:

https://github.com/umemura-dev/hono-supabase-auth-security-demo

In the previous article, I explained how Supabase Auth and RLS guarantee

who can access which data at the database layer.

This article focuses on one step earlier:

how incoming requests themselves are handled at the API entry point.

1. Why I Felt JWT Alone Was Not Enough

With Supabase Auth, JWTs allow us to verify:

“Which user is making this request?”

However, as I refined the design, several concerns emerged:

JWT proves user identity
It does not prove which application sent the request
If a token is leaked, requests can still be made as a valid user
Bots, scripts, and unintended clients are indistinguishable

In other words:

user authenticity and application authenticity are separate concerns.

JWT is essential, but relying on it alone felt insufficient.

2. Introducing “Application Authentication”

To address this, I separated responsibilities as follows:

JWT: who the user is
App Guard: which application is making the request

In addition to user authentication, the API verifies:

“Is this request coming from a pre-approved application?”

This mechanism is referred to here as App Guard.

3. App Guard Specification in the Demo

App Guard uses the following request headers:

X-App-Id
X-App-Timestamp
X-App-Signature

Each serves a distinct purpose.

X-App-Id

Identifies which client application is sending the request.

The server maintains pre-registered configurations per app.

X-App-Timestamp

Indicates when the request was created.

This helps prevent replay attacks using old requests.

X-App-Signature

Verifies that the request was not tampered with in transit.

4. The Concept of Request Signing

Each client application shares a secret key with the server.

When sending a request:

The app computes a value from the request content and the secret key
The value is sent as X-App-Signature
The server performs the same calculation
If both values match, the request is considered legitimate

This ensures:

Third parties cannot forge valid requests without the secret
Any request modification breaks the signature

Internally, this uses a standard signing algorithm (HMAC),

but this article focuses on the design rationale, not the cryptographic details.

5. Why This Signing Format Was Chosen

The signature input is constructed as:

${timestamp}.${METHOD}.${path}

This format was chosen deliberately.

Why include the timestamp

Prevents replaying old requests
Makes requests valid only for a short time window

Why include METHOD and path

Prevents confusion between GET and POST
Prevents reuse against different endpoints

Why the request body is excluded

JSON ordering and formatting differences easily break signatures
Increases implementation and operational complexity
Not cost-effective for a small-scale API

Instead of perfection,

a balance between security and maintainability was prioritized.

6. Why STRICT and LENIENT Modes Exist

App Guard supports multiple validation levels:

STRICT: timestamp and signature required
LENIENT: timestamp only
NONE: validation skipped (development use)

Applying maximum strictness everywhere can be overkill.

This flexibility allows each application to choose an appropriate security level without excessive overhead.

7. Implementation Approach with Cloudflare Workers (Hono)

App Guard is implemented as a Hono middleware:

Runs before all routes
Immediately returns 401 / 403 on failure
Logs App-Id and failure reasons

This design allows:

API handlers to focus purely on business logic
Security logic to be centralized and consistent

8. Responsibility Split: App Guard / JWT / RLS

Security in this API is layered, not monolithic.

Layer	Responsibility
App Guard	Is this a legitimate application?
JWT	Is this a legitimate user?
RLS	Can this user access this data?

Even if one layer is compromised,

the next layer is expected to stop the request.

9. Important Limitations

This App Guard design assumes the client-side secret key remains protected.

If a client application is reverse-engineered and the secret leaks,

valid signatures can still be generated.

This means App Guard alone is not a perfect defense.

In this demo API, the weakness is mitigated by combining:

Mandatory Supabase Auth (email/password)
JWT-based authenticated users
RLS enforcing “only your own data” at the database level

As a result:

Unauthenticated users cannot access data
Authenticated users cannot access others’ data
A leaked App Guard secret alone does not lead to data exposure

Rather than relying on any single mechanism,

this design emphasizes defense in depth.

10. Summary

In this demo API:

JWT verifies users
App Guard verifies applications
RLS enforces data access rules

Even small APIs can achieve layered security

with careful responsibility separation.

Cloudflare Workers are particularly well-suited for

controlling and validating requests at the API entry point.

All concepts discussed here are implemented in the following repository:

Cloudflare Workers + Hono API
Supabase Auth (JWT) + PostgreSQL RLS
App Guard (signature-based client authentication)
CI passing (Biome / TypeScript / Tests)

GitHub:

https://github.com/umemura-dev/hono-supabase-auth-security-demo

How I Designed Supabase and Row Level Security (RLS)

BysonTech — Mon, 29 Dec 2025 01:53:12 +0000

Designing a Secure API with Cloudflare Workers × Supabase

In this article, I explain how I approached Supabase and RLS, and how I incorporated them into my API design, based on a personal project built with:

React Native → Cloudflare Workers (Hono) → Supabase

The API assumes a simple use case: user-specific notes.

Supabase is powerful but very flexible, which makes it difficult to decide how much responsibility to delegate to it.

This article exists to clarify:

where I chose to rely on Supabase,
where I deliberately did not,
and why I made those decisions.

The concepts discussed here are demonstrated in the following repository:

https://github.com/umemura-dev/hono-supabase-auth-security-demo

1. How I Positioned Supabase (Initial Design Principles)

Supabase provides many features out of the box: database, authentication, storage, and auto-generated APIs.

Without clear boundaries, it’s easy for responsibilities to blur and the system to become complex.

So I fixed the following principles at the very beginning.

Principle 1

Supabase is responsible for data integrity and safety.

Principle 2

Final access decisions must always be enforced by RLS.

Principle 3

Business logic, input validation, and error handling live in Workers (the API layer).

Principle 4

Client-side privileges are kept minimal, and Service Role keys are never exposed.

By defining these four rules, each layer’s responsibility became clear,

and I avoided pushing application logic into Supabase unnecessarily.

2. Supabase Components Used in This Project

Auth (Authentication)

The role of Supabase Auth in this design is simple:

to reliably identify the user (UID).

On the Workers side, the flow is:

Extract the JWT from the Authorization header
Verify its signature using Supabase’s JWT_SECRET
Treat the sub claim (UID) as userId

This userId is stored in the request context and reused for database operations.

Database (PostgreSQL)

This demo uses a single table, demo_notes,

designed to store user-specific data.

Example columns:

id
user_id
title
body
created_at
updated_at
deleted_at

The deleted_at column enables soft deletes, avoiding physical row deletion.

RLS (Row Level Security)

RLS is a native PostgreSQL feature that determines:

“Is this user allowed to access this row?”

Supabase tightly integrates Auth and RLS,

allowing the JWT’s UID (sub) to be referenced as auth.uid().

Even if Workers validates userId,

without RLS there would still be a risk of data exposure if a malicious client accessed Supabase directly.

For that reason, RLS is always treated as the final defensive layer.

3. Example RLS Policies (demo_notes)

Below is a minimal RLS setup used in this project.

In real-world systems, you would typically extend this with read-only roles, admin roles, etc.

All policies use to authenticated, meaning:
only users authenticated via Supabase Auth are eligible.

This cleanly blocks unauthenticated or malicious access.

SELECT (Only fetch your own notes)

create policy "select_own_notes"
on demo_notes
for select
to authenticated
using (
  auth.uid() = user_id
);

INSERT (Only create notes for yourself)

create policy "insert_own_notes"
on demo_notes
for insert
to authenticated
with check (
  auth.uid() = user_id
);

UPDATE (Only update your own notes)

create policy "update_own_notes"
on demo_notes
for update
to authenticated
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

Note:

DELETE is not exposed via the API.

Instead, notes are soft-deleted by updating deleted_at.

4. How I Designed the Workers (Hono API)

Responsibilities are clearly split as follows.

Workers Responsibilities

JWT verification (authentication)
Extracting userId
Input validation (Valibot)
Application-specific logic (e.g. soft delete)
Preparing data for Supabase
Logging, rate limiting, error handling

Supabase (RLS) Responsibilities

Determining row-level access permissions
Blocking unauthorized access even if the API layer is bypassed

No matter how careful the Workers layer is,

it can never be considered perfectly secure.

By enabling RLS, I ensure that even if a request reaches the database, other users’ data remains inaccessible.

5. Why I Use Supabase RLS (Compared to Plain PostgreSQL)

RLS is available in PostgreSQL everywhere,

but I chose Supabase for three main reasons.

Automatic Auth–RLS Integration

Supabase provides a built-in bridge between JWTs and auth.uid(),

dramatically reducing design and implementation complexity.

Safe Even with Direct Client Access

Even when using Supabase’s official PostgREST API or client SDKs,

RLS policies are always enforced.

Security does not depend on routing everything through Workers.

The client SDK also supports automatic token refresh,

which simplifies client-side implementation.

That said, designing a system that safely supports direct access requires:

careful RLS design,
query design,
cache strategies,
and well-defined permission boundaries.

Since this project focuses on API security design,

I intentionally centralized access through Workers.

Strong Security Even for Personal Projects

RLS policies are defined in simple SQL and can be customized with conditions.

Once you understand the syntax, it becomes relatively easy

to enforce strong guarantees—even in small personal projects.

6. Summary: What This Architecture Prioritizes

Although this is a small demo project, the design emphasizes:

Workers (API) handle application behavior
RLS (DB) provides the final security boundary
Supabase Auth establishes user identity

With this structure,

I believe the risk of catastrophic data leaks is significantly reduced.

Going forward, I plan to expand on this foundation by documenting:

request signing strategies,
and additional API-side security patterns.

Demo Implementation

Everything described in this article is implemented in the following repository:

Cloudflare Workers + Hono API
Supabase Auth (JWT) + PostgreSQL RLS
App Guard (signature-based client authentication)
CI passing (Biome / TypeScript / Tests)

GitHub:

https://github.com/umemura-dev/hono-supabase-auth-security-demo

The Obstacles I Faced in Personal Development and How I Chose My Tech Stack

BysonTech — Sun, 28 Dec 2025 23:28:38 +0000

This article is a companion piece to my earlier post:

“Comparing API Architecture Choices: A Technical Evaluation of Six Setups Tested in Personal Development”

While that article focused on technical pros and cons,

this one documents my personal decision-making process:
how I chose certain architectures, why I abandoned others,
where I hit walls, and what I learned along the way.

Rather than listing abstract reasons, this article focuses on:

how my understanding evolved,
where I got stuck,
and why I changed direction at each stage.

1. Early Stage: I Didn’t Even Think About APIs or Backends

The first thing I tried to build was a small shopping list app.

At that point, I didn’t think an API or server was necessary at all.

My assumptions were simple:

It only needs to work on an iPhone
Local storage should be enough
The priority is to build screens and make something visible
Backend systems feel optional

With that mindset, I started development assuming a Swift-only, standalone app.

2. First Turning Point: I Didn’t Know How to Share Data

A few days into development, a new requirement appeared:

“I want to share the shopping list with my family.”

At that moment, it became obvious that local storage alone wouldn’t work.

That’s when I first thought:

“Maybe I need a database.”

However, my knowledge of APIs and backend systems was very limited.
In my day job, I had only worked with on-premise systems,
and I barely understood the concept of serverless architectures.

3. Trying Firebase — and Starting to See Its Limits

While researching databases for Swift, Firebase was the first option I encountered.
It was easy to set up, came with authentication, and looked very beginner-friendly.

But as the app idea evolved, several problems became clear.

Firestore (NoSQL) Didn’t Match My Requirements

For features like:

group-based data sharing,
managing multiple lists,
permission control,
frequently updated records,

a relational database felt much more appropriate.

Firebase was convenient, but it didn’t align with:

an RDB-centered design,
or my mental model for future expansion.

4. Moving from Swift to React Native: A Change in Assumptions

Initially, I was building only for iOS.
Later, I realized that React Native would allow Android support as well.

I switched from Swift to React Native.
This unified the frontend, but also made one requirement unavoidable:

“I need a proper relational database.”

At this stage, it became clear that I had to design a system
that could reliably connect to an RDB.

5. Discovering Supabase and Serverless RDBs

Around the time I felt Firebase wasn’t a good fit,
I discovered Supabase and learned that PostgreSQL could be used in a serverless way.

What stood out was:

Serverless-friendly architecture
PostgreSQL, which I was already familiar with
Built-in Row Level Security (RLS)
A generous free tier

Being able to use an RDB at low cost was very appealing for personal development.

6. Realizing the Limits of Direct Supabase Access

At first, I connected React Native directly to Supabase.
But once I started using it seriously, several issues surfaced.

No API Layer

Business logic and shared processing couldn’t live on the server.
As a result, complexity accumulated on the client side.

Security Design Was Hard

I initially embedded the Supabase anon key directly in the app.
This setup itself is not inherently wrong,
but with my level of knowledge, managing keys and security
without a backend layer felt risky.

The Need for a Shared Backend Emerged

As I started thinking about multiple apps,
I realized that direct client access would not scale well.

Supabase itself was great,
but a direct-connection architecture had clear limits.

7. Considering FastAPI + AWS — and Facing Cost Reality

Wanting a proper API foundation,
I started considering FastAPI + AWS.

What I initially imagined was a fairly “enterprise-style” setup:

API Gateway or ALB
FastAPI running on EC2 or containers
RDS (PostgreSQL) or Aurora Serverless v2
A private VPC-based architecture

As I researched further, one issue became obvious.

The Running Cost Would Be Too High

AWS can be inexpensive if you use:

API Gateway
Lambda
DynamoDB

But my mental model was:

always-on RDBs,
VPC networking,
monitoring and production-grade setups.

For a small personal project,
this felt too close to enterprise infrastructure.

From this point on, cost awareness became a major decision factor.

8. Trying Next.js API Routes — and Letting Them Go

While looking for a lower-cost alternative,
I found Vercel and Next.js API Routes.

At first, this seemed perfect:

JavaScript-based API development
Easy Git and Supabase integration
Simple deployment

I moved forward with this approach,
but soon encountered problems.

SSR / RSC billing was hard to avoid
My expected traffic and usage pattern would exhaust free tiers quickly

I also realized that Next.js works best
when frontend and API are tightly integrated,
which didn’t match my goal of an API-focused backend.

At this point, the conclusion was clear:

“I need an API platform that is API-only by design.”

9. Discovering Cloudflare Workers — Everything Clicked

When I started exploring Cloudflare Workers,
it immediately felt like a good fit.

Large free tier
Extremely low latency
Fully serverless, no maintenance
KV and Durable Objects available
Hono looked lightweight and expressive
Easy integration with Supabase

Problems that had been scattered across previous architectures
suddenly felt unified.

10. Adopting Workers × Hono — Finally a Coherent System

Once I moved the API layer to Workers × Hono,
multiple issues were resolved at once.

Centralized API Logic

Signing, logging, validation, and rate limiting
could all live in the API layer,
making both security and operations easier to reason about.

No Need to Distribute anon Keys to Clients

This was the biggest turning point.

Defense in Depth with Supabase RLS

Combining API-level checks with RLS
gave me confidence in the security model.

Scaling and Cost Were No Longer Concerns

This finally felt like an architecture
designed for personal development.

Although Hono requires more manual implementation,
my experience maintaining custom frameworks at work
made this manageable.

At this point, I concluded that:

React Native × Cloudflare Workers × Hono × Supabase

was the best solution for my needs.

11. Reflections on the Decision Process

The final architecture wasn’t obvious from the start.
It emerged through repeated trial, failure, and adjustment.

Looking back, several lessons stand out:

I didn’t even understand the need for APIs at first
Firebase is convenient, but has clear long-term limits
Supabase is powerful, but needs an API layer
AWS is excellent, but often overkill for personal projects
Cloudflare Workers align extremely well with personal development needs

12. Relationship to the Comparison Article

This article documents how I thought and why I decided,
based on hands-on experience.

For a more objective, technical comparison,
see the related article here:

https://dev.to/bysontech_8dd1313811a8895/comparing-api-architecture-choices-a-technical-evaluation-of-six-setups-tested-in-personal-4o63

Final Thoughts

I’ve now settled on a stack built around:

React Native × Cloudflare Workers × Hono × Supabase

Going forward, I plan to use this API foundation
to support multiple small applications.

This article records one part of that journey.
If you have suggestions or alternative approaches,
I’d love to hear them in the comments.

Update

A demo API based on this architecture is now available:
https://github.com/umemura-dev/hono-supabase-auth-security-demo

Comparing API Architecture Choices: A Technical Evaluation of Six Setups Tested in Personal Development

BysonTech — Sun, 28 Dec 2025 22:43:53 +0000

API Architecture Comparison for Personal Projects

When I first started personal development, I assumed the app could be mostly self-contained.

However, as requirements such as data sharing, user authentication, and multi-app expansion grew,

it became necessary to select a proper backend (API) and serverless infrastructure.

After evaluating multiple setups — including Swift-only, Firebase, FastAPI, direct Supabase access, and Next.js —

I ultimately concluded that React Native × Hono × Cloudflare Workers × Supabase was the optimal architecture.

This article objectively summarizes the characteristics of each option and explains the technical reasons for adoption or rejection.

1. Selection Criteria

The API architecture was evaluated based on the following requirements.

Functional Requirements

APIs usable from both iOS and Android
Support for guest users and authenticated users
Persistent data storage (RDB required)
A shared API used by multiple small applications

Non-Functional Requirements

Affordable for long-term personal development
Protection against unauthorized access at the API level
Scalability toward multi-tenant / SaaS use
Low operational and maintenance overhead
Preference for a serverless architecture

2. Evaluated Architectures

Each candidate architecture is reviewed below, along with an assessment of how well it meets the requirements.

2-1. Swift (iOS Only)

Overview

A native iOS app built using Swift only, with data stored locally.

Evaluation

Pros

Fast UI development
High performance due to native execution

Cons (Requirement Mismatch)

No Android support → fails cross-platform requirement
Cannot include RDB or API layer → fails data-sharing requirement
Relying solely on app-side security is inappropriate

→ Rejected due to unmet requirements

2-2. Swift + Firebase

Overview

Uses Firebase Authentication and Firestore as the backend.

Evaluation

Pros

Low learning curve
Fast development with SDK integration

Cons (Data Requirement Mismatch)

No Android support
Firestore does not satisfy RDB requirements (joins and normalization are difficult)
Security rules become complex and fragile at scale

→ Rejected due to RDB and scalability constraints

2-3. React Native + Firebase

Overview

A cross-platform React Native app connected directly to Firebase Authentication and Firestore.

Evaluation

Pros

Cross-platform support
Very fast development speed

Cons (API Requirement Mismatch)

Firestore does not meet RDB requirements
Direct client access prevents building a proper API logic layer
Audit logs, signatures, and advanced security logic cannot be enforced server-side

→ Rejected due to insufficient security architecture

2-4. React Native + FastAPI + AWS

Overview

FastAPI (Python) used as the API layer, with AWS services such as RDS, Lambda, and VPC.

Evaluation

Pros

Enterprise-grade security design
Highly flexible business logic
Broad database options (PostgreSQL, MySQL, Aurora)

Cons (Cost Mismatch)

Overkill for personal development once RDS, VPC, and monitoring are included
High operational cost and fixed expenses
Even serverless setups accumulate costs via API Gateway and CloudWatch

→ Rejected due to poor cost-performance balance

2-5. React Native + Supabase (Direct Client Access)

Overview

React Native connects directly to Supabase (PostgreSQL + RLS).

Evaluation

Pros

Full RDB support
Basic security via Row Level Security (RLS)

Cons (No Server Layer)

No API layer to implement business logic
Risky secret management on the client side
Insufficient as a shared backend for multiple applications

→ Rejected due to security and architectural limitations

2-6. React Native + Next.js (Vercel) + Supabase

Overview

API built using Next.js API Routes and Vercel Edge with KV caching.

Evaluation

Pros

Fast responses with Edge Runtime
Easy KV-based caching
Seamless integration of web and API

Cons (Cost and Purpose Mismatch)

SSR / RSC billing can quickly exhaust free tiers
Limited benefit when using Next.js purely as an API
Less cost-efficient for API-focused workloads compared to Workers

→ Rejected due to cost efficiency concerns

2-7. React Native + Hono + Cloudflare Workers + Supabase (Final Choice)

Overview

Hono runs on Cloudflare Workers as the API layer.

Supabase (PostgreSQL + RLS) is used as the primary datastore, with Workers KV for caching.

Reasons for Adoption

1. Meets Security Requirements

JWT verification, request signing, and rate limiting at the API layer
Defense in depth with Supabase RLS
Cloudflare WAF can be placed in front
No need to distribute Supabase anon keys to clients

2. Low Cost

Workers remain free under ~100k requests/month
KV and caching reduce Supabase query volume
Zero fixed operational cost

3. High Scalability

API modularization suitable for multi-app expansion
Hono provides Express-like ergonomics with high performance
Serverless scaling removes infrastructure concerns

4. High Development Efficiency

Workers + Hono are optimized for API-only use
Simple middleware composition
Smooth integration with Supabase

→ Adopted as it best satisfies both technical and non-functional requirements

3. Architecture Diagram

4. Comparison Table

Security, cost, and scalability are subjective evaluations based on this project’s assumptions.

Architecture	RDB	Security	Cost	API Extensibility	Overall
Swift	×	Low	Low	Low	Rejected
Swift + Firebase	×	Medium	Low	Low	Rejected
RN + Firebase	×	Medium	Low	Medium	Rejected
RN + FastAPI + AWS	○	High	High	High	Rejected
RN + Supabase (Direct)	○	Medium	Low	Low	Rejected
RN + Next.js + Vercel	○	Medium	Medium	Medium	Rejected
RN + Hono + Workers + Supabase	○	High	Very Low	High	Adopted

5. Summary

This article compared multiple API architectures for a personal development project,

evaluating each option against functional and non-functional requirements.

The final choice — React Native × Cloudflare Workers × Hono × Supabase — stood out for:

Strong API-level security controls
Reliable RDB support with Supabase and RLS
Excellent cost efficiency via Cloudflare Workers
Flexible serverless scaling
A structure well-suited for multi-app expansion

Learning Cookie Creation and Access Through Implementation (Part 3)

BysonTech — Sun, 28 Dec 2025 21:11:23 +0000

Understanding Cookie Issuance and Retrieval with Real Code (Java × JavaScript)

In Part 1, we covered what cookies are.

In Part 2, we explored when cookies are stored and sent by browsers.

In Part 3, we’ll work with actual, runnable code to understand how cookies are handled in practice.

We’ll cover:

Issuing cookies in Java (Servlet)
Issuing cookies in JavaScript
Reading cookies in Java (Servlet)
Reading cookies in JavaScript

1. Issuing Cookies in Java (Servlet)

Based on my experience, issuing cookies in Java typically follows this flow:

Create a cookie with new Cookie
Set attributes such as Path, MaxAge, HttpOnly, and Secure
Optionally set Domain
Send it using response.addCookie()

Example: Cookie Issuance Code

    import java.io.IOException;
    import javax.servlet.ServletException;
    import javax.servlet.annotation.WebServlet;
    import javax.servlet.http.Cookie;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;

    @WebServlet("/login")
    public class LoginServlet extends HttpServlet {

        @Override
        protected void doGet(HttpServletRequest request, HttpServletResponse response)
                throws ServletException, IOException {

            Cookie tokenCookie = new Cookie("cookieName", "abcd1234");

            tokenCookie.setPath("/");
            tokenCookie.setMaxAge(60 * 60);
            tokenCookie.setHttpOnly(true);
            tokenCookie.setSecure(false);

            tokenCookie.setDomain("localhost");

            response.addCookie(tokenCookie);

            response.setContentType("text/plain; charset=UTF-8");
            response.getWriter().println("Cookie has been issued.");
        }
    }

Note:

In some browsers, cookies with Domain=localhost may not be stored correctly.

If that happens, omit the Domain attribute and rely on Path instead.

About Domain Configuration

Local environment

→ localhost or 127.0.0.1
Production environment

→ Passed via environment variables

(e.g., System.getenv("COOKIE_DOMAIN"))

Incorrect domain settings often cause:

Cookies being stored but not sent
Cookies being sent but not readable

2. Issuing Cookies in JavaScript

In JavaScript, cookies are set via string assignment:

document.cookie = "key=value; Path=/; Max-Age=seconds; attributes...";

Example:

    document.cookie = "cookieName=abcd1234; Path=/; Max-Age=86400; Secure";

Important notes:

HttpOnly cannot be set from JavaScript
Secure cookies are sent only over HTTPS

3. Reading Cookies in Java (Servlet)

Java retrieves cookies using request.getCookies().

Helper method example:

    private Cookie getCookie(HttpServletRequest request, String name) {
        Cookie[] cookies = request.getCookies();
        if (cookies == null) {
            return null;
        }

        for (Cookie c : cookies) {
            if (c.getName().equals(name)) {
                return c;
            }
        }
        return null;
    }

Usage:

    Cookie tokenCookie = getCookie(request, "cookieName");
    if (tokenCookie != null) {
        String token = tokenCookie.getValue();
        System.out.println("Login token = " + token);
    }

4. Reading Cookies in JavaScript

document.cookie returns all cookies as a single string:

    cookieName=abcd1234; example=test; example1=test1

Parsing function example:

    function getCookie(name) {
        const cookies = document.cookie.split(";");

        for (let i = 0; i < cookies.length; i++) {
            const cookie = cookies[i].trim();
            if (cookie.startsWith(name + "=")) {
                return cookie.substring(name.length + 1);
            }
        }
        return null;
    }

Usage:

    const token = getCookie("cookieName");
    console.log("cookieName:", token);

HttpOnly cookies cannot be accessed from JavaScript.

5. Common Pitfalls in Local Development

① Secure and http://localhost

Secure cookies are sent only over HTTPS.

Local development often uses HTTP, causing cookies not to be sent.

For development, Secure=false is recommended.

If Secure=true is required in production, always test with HTTPS locally.

② SameSite=None requires Secure=true

Most modern browsers require Secure when SameSite=None is used.

③ Different ports mean different sites

localhost:3000 and localhost:8080 do not share cookies.

④ Different Path or Domain means a different cookie

Same cookie name with different Path or Domain creates separate cookies.

⑤ Browser-specific differences

Cookie visibility and tooling differ by browser, making cross-browser testing essential.

6. Summary

Java issues cookies via new Cookie → attribute settings → response.addCookie
Same name with different Path or Domain creates separate cookies
JavaScript sets cookies via document.cookie
HttpOnly cookies are invisible to JavaScript
Local development is tricky due to Secure, SameSite, and port differences
Browser behavior must always be considered

A Critical Security Note

Cookies are easily manipulated on the client side:

Values can be modified
Expiration can be extended
Domain and Path can be changed
Cookies can be deleted or added
JavaScript can read/write non-HttpOnly cookies

Therefore, cookies must never be trusted as authentication proof.

Dangerous designs:

Storing user_id directly in cookies
Treating the existence of a cookie as authentication

A proper design requires:

Cookies carry signed tokens (e.g., JWT)
Authentication is verified server-side
Token forgery is impossible even if cookies are modified
Proper use of HttpOnly, Secure, and SameSite

Understanding Browser Cookie Behavior (Part 2)

BysonTech — Sun, 28 Dec 2025 20:51:03 +0000

Understanding Browser Cookie Behavior (Part 2)

In Part 1, I covered what cookies are and why they exist.

In this second article, I’ll focus on a topic that often causes confusion in real-world development:

Where browsers store cookies, and when they actually send them.

While implementing cookie issuance logic myself, I repeatedly ran into issues such as:

Cookies not being sent as expected
Cookies not disappearing (or mysteriously remaining)
Behavior changing due to SameSite differences
Different behavior across browsers

This article organizes those common points of confusion.

Where Are Cookies Stored in the Browser?

Cookies are automatically stored and managed by the browser.

The exact storage location differs by browser, but the concept is the same.

Chrome (Chromium-based browsers)

Stored in a local SQLite database (e.g., a Cookies file)
Viewable via DevTools: Application > Cookies

Safari (macOS / iOS)

Managed internally by WebKit
Often not accessible as user-visible files

Firefox

Stored in cookies.sqlite
Accessible via DevTools under the Storage tab

In all cases, developers never interact with these files directly—the browser handles everything.

When Are Cookies Sent?

Cookies are only sent when all required conditions are satisfied.

If even one condition fails, the browser will not include the cookie.

The request domain matches the Domain attribute
The request path matches the Path attribute
If Secure is set, the request uses HTTPS
The SameSite condition is satisfied
The cookie has not expired

If any of these are misconfigured, cookies may silently fail to be sent.

Cookie Attributes and Their Behavior

1. Domain

Example:

Set-Cookie: token=abc; Domain=example.com;

This cookie will be sent to:

example.com
www.example.com

If you specify Domain=www.example.com, the cookie is only sent to that exact host.

If the Domain attribute is omitted, the cookie becomes a host-only cookie,

meaning it is sent only to the issuing domain and not to subdomains.

2. Path

Example:

Set-Cookie: token=abc; Path=/app;

The cookie is sent only for requests under /app.

Using Path=/ causes the cookie to be sent with all requests to the domain.

3. Secure

Cookies with the Secure attribute are only sent over HTTPS.

Examples:

https://example.com → sent
http://localhost → not sent

This is a common pitfall in local development.

I personally lost time debugging issues caused by not fully understanding this behavior.

4. HttpOnly

Cookies with HttpOnly cannot be accessed from JavaScript.

Because of this:

HttpOnly cookies cannot be set via JavaScript
They must be set using Set-Cookie on the server

Example:

document.cookie

→ HttpOnly cookies will not appear

This attribute is critical for security, especially as a defense against XSS.

5. SameSite

One of the most impactful cookie attributes today.

SameSite=Lax (default)
SameSite=None (allows cross-site requests, but requires Secure)
SameSite=Strict (sent only for same-site requests)

Authentication flows and integrations with external services often fail because cookies are blocked by SameSite rules.

Differences in Browser Behavior

Due to historical reasons and security policies, cookie behavior differs slightly between browsers.

Chrome

Strict adherence to SameSite specifications
SameSite=None requires Secure

Safari (including iOS)

Strongly affected by ITP (Intelligent Tracking Prevention)
3rd-party cookies are deleted very quickly
Even 1st-party cookies may be deleted if the user does not revisit within 7 days

Many cases of “login sessions suddenly expiring” or unstable external integrations are caused by ITP.

Firefox

Generally close to the specification
Behavior may differ in private browsing mode

Because of these differences, testing across multiple browsers is essential.

Common Reasons Cookies “Remain” or “Disappear”

Typical causes encountered in development include:

Cookies with different Path values existing simultaneously
Multiple cookies created due to different Domain settings
Cookies blocked by SameSite in cross-site requests
Secure cookies not sent over HTTP in local environments
HttpOnly cookies not visible in JavaScript, causing confusion
Automatic deletion by Safari’s ITP

Since I previously paid little attention to browser-level behavior, it took time to determine whether issues were caused by my implementation or by browser rules.

Cookies often fail due to overlapping conditions, so debugging requires checking them one by one.

Summary

Cookies are stored internally in the browser (often using SQLite)
Cookie transmission depends on Domain, Path, Secure, SameSite, and HttpOnly
SameSite is a critical modern attribute that must be understood
Safari’s ITP has a strong impact on cookie behavior
Issues with cookies persisting or disappearing are usually due to configuration or browser differences

Part 3 Preview

In the next article, I’ll walk through real code examples, including:

Issuing cookies on the server side (Java)
Manipulating cookies with JavaScript
Common pitfalls in local development

Original Japanese article:

https://zenn.dev/bysontech/articles/68c9e472adb403

What Is a Cookie? A Clear Introduction from the Basics (Part 1)

BysonTech — Sun, 28 Dec 2025 08:03:03 +0000

What Is a Cookie? A Clear Introduction from the Basics (Part 1)

A while ago, I worked on a project that introduced Risk-Based Authentication (RBA) — the mechanism that detects suspicious logins (such as foreign access or unusual behavior) and requires additional verification.

Before we could even design the authentication logic, we ran into a prerequisite concept: cookies.

To be honest, even after working with Java and React, I was in the familiar situation of

“I kind of know what cookies are, but I can’t explain them clearly.”

No one on the team had a solid explanation either, so I decided to start by revisiting how cookies actually work from the ground up.

This article is for people who are at the same stage I was:

What exactly is a cookie?
Why do we need it in the first place?

I’ll focus only on the fundamentals.

What Is a Cookie?

In short, a cookie is

a small piece of data that a website stores in your browser.

When a browser sends an HTTP request to a server, cookies are automatically included in the request.

This allows the server to continuously recognize things like:

Whether this user has visited before
Whether the user is authenticated
Which preferences or settings are in use

HTTP itself is stateless by design — it does not remember past requests.

Cookies are one of the primary mechanisms used to fill this gap.

Why Are Cookies Necessary?

Cookies serve many purposes, but their core roles can be summarized into two main ones.

1. User Identification

To distinguish authenticated users, cookies often store a session ID or a token identifier.

Without cookies, login information would be lost on every page transition.

The reason users can stay logged in is that cookies are automatically sent with each request.

2. Persisting User Preferences

Cookies are also used to remember user-specific settings such as:

Dark mode
Language preferences
Partially completed forms

In other words, cookies exist to maintain state.

In the project I worked on, they were mainly used for the first purpose: authentication.

The Difference Between 1st-Party and 3rd-Party Cookies

When learning about cookies, you will almost always encounter the distinction between

1st-party cookies and 3rd-party cookies.

The difference is based on which domain issued the cookie.

1st-Party Cookies

Cookies issued by the site you are currently visiting.

Example:

If you are browsing example.com and its server returns a Set-Cookie header, that cookie is a 1st-party cookie.

Characteristics:

Used for authentication and session management
Few restrictions in modern browsers
Essential for basic web application behavior

3rd-Party Cookies

Cookies issued by a domain different from the one you are visiting.

Example:

An advertising network like ad.example.net issuing its own cookie inside a page you’re viewing.

Characteristics:

Traditionally used for ads and cross-site tracking
Strongly restricted by most modern browsers
Being phased out entirely (Chrome included, gradually)

Why This Distinction Matters

In risk-based authentication, decisions are made based on signals such as:

Which browser the request comes from
Whether the same device has authenticated before
When and where a cookie was issued
Whether consistency is maintained within the same site

Cookie data is especially important for detecting suspicious behavior.

For this reason, systems are typically designed to rely on safe, controllable 1st-party cookies, while avoiding unnecessary dependence on 3rd-party cookies.

Understanding this distinction is a prerequisite for making sound design and implementation decisions later.

Summary

Cookies are small pieces of data stored in the browser
HTTP is stateless, so cookies enable state management
Cookies are widely used for authentication, preferences, and user identification
1st-party cookies are issued by the site itself
3rd-party cookies are issued by external domains and are heavily restricted today
Proper cookie handling is fundamental to risk-based authentication

What’s Next (Part 2)

In the next article, I’ll dive into how browsers actually handle cookies, including:

Where browsers store cookies
When cookies are sent with requests
SameSite, Secure, and HttpOnly attributes
Differences between Chrome, Safari, and Edge
How to inspect cookies using developer tools

I’ll focus on the points that tend to cause confusion in real-world development.

Original Japanese article:

https://zenn.dev/bysontech/articles/dd7cfb2c9faf57t

Forem: BysonTech

How JavaScript Async Actually Works (Event Loop, Micro tasks, and Call Stack)

1. JavaScript Is Single-Threaded

2. What Is the Call Stack?

3. The Problem: Long-Running Tasks

4. Web APIs

5. Task Queue

6. Event Loop

7. Full Async Flow

8. Promise Is Special

9. Microtasks vs Tasks

Task Queue (Macrotasks)

Microtask Queue

10. Example

11. Event Loop Order (Important)

12. What async Really Does

13. What await Really Does

14. Mental Model of await

15. await Splits Execution

16. Another Example

17. Key Insight About await

18. Sequential vs Parallel

19. Why This Matters

20. Big Picture

21. Final Summary

Why JavaScript Returns a Promise: Understanding async / await from the Ground Up

1. What Synchronous Code Means

2. Why Asynchronous Code Exists

3. What a Promise Actually Is

Promise States

Example

4. Why You Don’t Get the Value Immediately

5. Promise Chaining

6. What async Means

7. What await Means

8. Promise vs async / await

9. Error Handling

10. Parallel Processing

11. Promise.allSettled

12. fetch with async / await

13. Common Mistakes

async returns a Promise

await outside async

Missing error handling

14. When to Use new Promise

15. Real-World Pitfall

Summary

Designing “Just Enough” API Security for Solo Developers

How I Avoided Overengineering While Keeping My API Safe

Target Architecture

1. Security Was Not Clearly Defined at the Start

2. Deciding the Scope Before Writing Code

3. My Practical Threat Model

What I assumed would happen

What I chose not to assume

4. Moving Away from “The API Must Do Everything”

5. Splitting Responsibilities by Layer

API layer (Cloudflare Workers)

Supabase Auth

Supabase RLS

6. Why JWT Alone Was Not Enough

7. Keeping Request Signing “Reasonable”

8. RLS as the Final Line of Defense

9. Final Architecture (Conceptual View)

10. Logging and Error Design

11. Final Thoughts

Protecting the API Entry Point with Cloudflare Workers

Verifying Application Authenticity Beyond JWT

1. Why I Felt JWT Alone Was Not Enough

2. Introducing “Application Authentication”

3. App Guard Specification in the Demo

X-App-Id

X-App-Timestamp

X-App-Signature

4. The Concept of Request Signing

5. Why This Signing Format Was Chosen

Why include the timestamp

Why include METHOD and path

Why the request body is excluded

6. Why STRICT and LENIENT Modes Exist

6. What `async` Means

7. What `await` Means