DEV Community: nishchal singh

OpenRouter Returned 200, But My Next.js AI Stream Was Empty

nishchal singh — Mon, 14 Sep 2026 12:16:34 +0000

My AI chat was working locally. In production, Vercel gave me a 504. After fixing that, OpenRouter returned 200 — and I still received nothing.

That was the point where I stopped looking for one broken line and started looking at the whole streaming path.

The eventual problem was simpler than I expected:

I had too many layers handling the same stream.

Here's how I found it.

The setup

The application uses:

Next.js App Router
React
TypeScript
MongoDB / Mongoose
Clerk
TanStack Query
Cloudinary
OpenRouter

The AI assistant is available at:

https://www.pssmumbai.org/ai

It uses reviewed application knowledge to answer questions around PSS teachings, meditation and related topics.

The public chat endpoint is:

POST /api/ai/chat

The model is:

openai/gpt-5-mini

through OpenRouter.

There is quite a bit happening around the model request:

Authentication
Rate limiting
Quota
Conversation history
Knowledge retrieval
AI response
Conversation persistence
Usage tracking

I wanted the response to stream to the browser instead of waiting for the entire answer.

That's where things had become unnecessarily complicated.

The streaming architecture I had built

The application already had an AI SDK implementation using:

streamText()

and:

@openrouter/ai-sdk-provider

But there was also an older custom streaming implementation.

The older path used:

src/lib/openai.ts

That wrapper made its own request to OpenRouter and requested:

Accept: text/event-stream

The API route then manually handled the provider response.

It had to read chunks, parse SSE events, extract token deltas, detect completion and usage, accumulate the response, and convert everything into our own NDJSON format.

The browser then had another custom parser for that NDJSON stream.

So the flow looked roughly like this:

Browser
  ↓
fetch()
  ↓
Custom NDJSON parser
  ↓
Next.js API route
  ↓
Custom OpenRouter wrapper
  ↓
Custom SSE parser
  ↓
OpenRouter
  ↓
GPT-5 Mini

There was also an AI SDK path sitting alongside it.

That was the first thing I should have questioned.

Multiple layers understood the same stream.

Then production failed

The first thing I saw in the browser was:

Unexpected token 'A', "An error o"... is not valid JSON

At first, I thought I had a JSON problem.

Maybe the API was returning something unexpected.

Maybe the frontend parser was wrong.

Maybe the error response wasn't valid JSON.

So I opened the Network tab.

The request was:

POST /api/ai/chat

and the response was:

504 Gateway Timeout

That changed the investigation.

The JSON error wasn't the root problem.

The request itself wasn't completing.

Vercel was killing the function

The Vercel logs showed:

FUNCTION_INVOCATION_TIMEOUT

with:

10.37s / 10s

The function was being terminated before the AI request could finish.

I checked the repository for anything that might have configured this.

There was no:

vercel.json

No route-level:

maxDuration

and no runtime override that I had intentionally added.

So I checked the Vercel project settings.

Fluid Compute was disabled.

I enabled it and redeployed.

The function now had a much larger execution window.

The platform timeout was fixed.

But the request still wasn't working.

The timeout moved

After the deployment, the application started reaching its own timeout:

AI_TIMEOUT

with:

The AI service took too long to respond. Please try again.

The application-level timeout was around:

20 seconds

That was useful information.

The problem had changed from:

Platform timeout

to:

Application/provider streaming latency

Increasing the function duration hadn't fixed the stream.

It had simply allowed the request to get further.

So I added more timing and streaming logs.

Then OpenRouter returned `200`

This was the part that really confused me.

The request successfully passed the application stages:

auth_end
rate_limit_end
quota_reserve_end
conversation_lookup_end
retrieve_context_end

Then:

openrouter_request_start
streaming=true

OpenRouter responded:

openrouter_stream_headers
status=200

So far, so good.

Except the stream counters said:

chunkCount=0
parsedEventCount=0
deltaCount=0
accumulatedChars=0
sawFinishReason=false
sawUsage=false
sawDone=false

Eventually:

openrouter_stream_unexpected_eof

The API itself eventually returned:

POST /api/ai/chat 200

but the browser received:

The AI service disconnected before completing the response.

So I had an HTTP 200 from OpenRouter, but zero usable streaming events reached my application.

That was the clue.

I couldn't reasonably say OpenRouter itself was broken.

The evidence pointed toward the streaming path I had built around it.

I stopped patching the parser

At this point, I could have kept modifying the custom SSE parser.

Instead, I wanted to answer one smaller question:

Can the AI SDK receive an OpenRouter stream correctly?

So I created an isolated test using:

AI SDK v6
+
@openrouter/ai-sdk-provider
+
OpenRouter
+
openai/gpt-5-mini

The test successfully produced streamed deltas.

The result included:

success: true
model: openai/gpt-5-mini
deltasCount: 4
accumulatedChars: 21
finishReason: stop
usage present
providerRequestId present

I wouldn't rely on the exact timing from that isolated test because the instrumentation around it wasn't reliable enough.

But I had enough evidence to move forward:

The AI SDK + OpenRouter combination could receive streamed output.

That changed the question.

Instead of asking:

Which line in my parser is broken?

I started asking:

Why am I maintaining this parser at all?

The actual problem was architectural

Looking back, I was handling too much myself.

The application had custom code for:

Provider streaming
SSE parsing
Transport conversion
Client stream parsing
Message accumulation
Cancellation
Completion handling

None of those things are impossible to build.

The problem was that multiple layers had responsibility for the same stream.

The browser understood one streaming format.

The API route translated between formats.

The OpenRouter wrapper understood the provider stream.

The SSE parser interpreted provider events.

And the AI SDK had its own streaming abstraction.

More layers meant more places where data could be transformed, misunderstood or lost.

And when something failed, it wasn't immediately obvious which layer was responsible.

The fix: one authoritative streaming path

I stopped using the legacy custom streaming path for the public chat route.

The new flow is:

Browser
  ↓
POST /api/ai/chat
  ↓
Authentication
  ↓
Rate limiting
  ↓
Quota
  ↓
Conversation lookup
  ↓
Knowledge retrieval
  ↓
streamText()
  ↓
@openrouter/ai-sdk-provider
  ↓
OpenRouter
  ↓
GPT-5 Mini
  ↓
Stream back to browser
  ↓
Save completed response
  ↓
Persist usage

The public route no longer calls:

getOpenAIClient().chat.completions.stream()

and it no longer manually parses OpenRouter's raw SSE response.

The existing OpenAI-compatible wrapper wasn't removed completely because other non-streaming/admin functionality still uses it.

The change was specifically for the public streaming path.

The important decision was:

One implementation should be responsible for the model stream.

I didn't rewrite the frontend

I also didn't want to change everything at once.

The frontend already understood our NDJSON protocol:

{ "type": "delta", "text": "..." }

{ "type": "done", "..." }

{ "type": "error", "..." }

I could have changed the provider, server transport, frontend parser and UI state management together.

That would have made the debugging harder.

Instead, I kept the existing browser contract and changed the provider-side streaming implementation first.

For the moment, the flow became:

AI SDK
  ↓
AI SDK stream
  ↓
Small compatibility layer
  ↓
Existing NDJSON client

It's not the final architecture.

The longer-term plan is to move the frontend away from custom:

fetch() + NDJSON parsing

and eventually use the AI SDK's React transport.

But that can be a separate change.

The first successful end-to-end test

After changing the public route, I tested the chat with:

Guide me through a 5-minute mindful meditation.

The browser streamed the response successfully.

The logs showed:

ai_stream_selected
stream_path = ai_sdk_openrouter

stream_started

stream_first_text
firstDeltaMs = 10568

The response was then persisted:

conversation_save:
~472 ms

usage persistence:
~166 ms

And the request finished with:

stream_finished

POST /api/ai/chat 200 in 18584ms

The old failure events were gone.

No:

openrouter_stream_unexpected_eof

No:

openrouter_stream_error

And the browser no longer showed the disconnect error.

The streaming path was working again.

But it was still slow

This is where the story gets more interesting.

The streaming problem was fixed.

The performance problem wasn't.

The successful request took approximately:

First text: ~10.568s
Total request: ~18.584s

Ten seconds before the first useful text is still too long.

I don't want to hide that behind a nicer loading animation.

Now the question is:

Why is the first text taking around 10.5 seconds?

That's a different investigation.

I'm looking at:

Model reasoning configuration
OpenRouter/provider routing
Prompt size
Conversation history size
Retrieved context size
Duplicated instructions/context
Work happening before the provider call
AI SDK/provider configuration

The model remains:

openai/gpt-5-mini

I'm not changing the model just to get a better-looking number.

First I want to understand where the time is actually going.

Working and fast are different problems

This distinction became pretty important during this debugging session.

The first successful test answered:

Does the stream work?

Yes.

It didn't answer:

Is the stream fast enough?

Not yet.

Those are two different engineering problems.

So I'm now measuring:

Request start
Stream start
First text
Completion
Abort
Failure
Total latency

I also want a request ID that follows the request through the important stages.

That should make the next performance investigation much easier than piecing unrelated log lines together.

What I'd change if I built it again

I wouldn't start by building a pile of streaming infrastructure.

I'd first decide which layer should own the stream.

For this application, the responsibilities are roughly:

Application
→ auth, quota, retrieval, persistence, business rules

AI SDK
→ model streaming and stream lifecycle

Provider
→ OpenRouter/model communication

UI
→ displaying and interacting with the response

The mistake wasn't writing custom code.

The mistake was allowing several layers to own the same problem.

Once I removed that overlap, the system became much easier to reason about.

And that's probably the most useful thing I got from this debugging session:

Sometimes the fix isn't adding another layer.

It's deciding which layer doesn't need to be there.

The NGO App's AI Worked Locally. Then Vercel Gave Me a 504.

nishchal singh — Wed, 09 Sep 2026 01:49:08 +0000

I was testing the AI assistant locally, and everything was working.

Then I deployed it.

I opened the production app and asked:

how start meditation. im a beginner

Instead of an answer, I got:

Unexpected token 'A', "An error o"... is not valid JSON

At first, I thought I had broken something in the frontend.

I hadn't.

The error was hiding the actual problem

I checked the browser Network tab.

The request was:

POST /api/ai/chat

and the response was:

504 Gateway Timeout

So the JSON error wasn't the actual problem. The frontend was trying to parse an error response as JSON, while the request itself had already timed out.

That changed my debugging path.

Instead of looking at the JSON parser, I needed to find out why the server request was timing out.

But it worked locally

This was the confusing part.

The same AI request worked on my local machine.

The local terminal showed:

POST /api/ai/chat 200 in 21994ms

The logs showed:

AI context retrieved
model: openai/gpt-5-mini

The AI completion itself took around 17.76 seconds.

The usage was:

promptTokens: 1663
completionTokens: 1500
totalTokens: 3163
finishReason: "length"

So the complete local request was taking roughly 22 seconds, but it still succeeded.

That was an important clue.

The model wasn't simply broken.

OpenRouter wasn't obviously unreachable.

The application could make the request and receive a response.

Something was different in production.

Vercel gave me the useful error

I checked the Vercel production logs.

This time, the error was much more useful:

FUNCTION_INVOCATION_TIMEOUT

And there was a number that immediately stood out:

Execution Duration / Maximum
10.37s / 10s

The logs also showed that parts of the request had already completed:

Clerk authentication succeeded
AI context retrieval succeeded
POST request to OpenRouter was made
AI completion did not return before the function was terminated

So the function wasn't failing immediately.

It was running out of time while waiting for the AI completion.

That explained the 504.

Where was that 10-second limit coming from?

I checked the repository first.

There was no:

vercel.json

There was no route-level:

maxDuration

There was no runtime override.

And there wasn't a Next.js configuration setting a 10-second function duration.

So I hadn't configured this timeout in the application code.

I checked the Vercel project settings next.

That's where I found it.

Fluid Compute was disabled.

Screenshot: Vercel Functions settings showing Fluid Compute disabled

That was the missing piece.

The fix

I enabled Fluid Compute in the Vercel project settings and redeployed the application.

After the redeployment, the execution numbers changed from:

10.37s / 10s

to:

26.31s / 5m

The AI request could now finish.

The browser displayed the generated response instead of the 504.

The production logs also showed the rest of the request completing:

conversation_save_start
conversation_save_end
usage_persist_start
usage_persist_end
ai_chat_request_end

The application recorded:

totalElapsedMs: 25384

Vercel reported approximately:

26.31s

And the API returned:

Screenshot: successful production request / Vercel execution metrics

So the first production problem was fixed.

One important clarification

I don't want to turn this into the wrong Vercel lesson.

I'm not saying:

"Vercel cannot run AI functions longer than 10 seconds."

That's not what I observed.

What I observed was that this deployment was running with a 10-second maximum while Fluid Compute was disabled.

After enabling Fluid Compute and redeploying, the same function was allowed to run for up to 5 minutes, and the request completed.

The fix wasn't making OpenRouter faster.

It removed the execution limit that was killing the request before the AI response could return.

But then I noticed something else

The 504 was gone.

The AI was working in production.

So I could have stopped there.

But the successful request was still taking around 25–26 seconds.

The local request was around 22 seconds.

So fixing one problem exposed another one.

I don't know the cause yet, and I don't want to guess.

Instead, I added temporary timing logs around different parts of the request:

authentication
rate limiting
quota reservation
database connection
conversation lookup/create
AI context retrieval
OpenRouter request start
OpenRouter response headers
OpenRouter full response
conversation save
usage persistence
total request duration

Now I'm measuring each part instead of assuming where the time is going.

That's the next problem.

What I learned from this

Don't trust the first error

The browser showed a JSON parsing error.

The actual problem was a 504.

The Network tab gave me the next clue.

Local success doesn't guarantee production success

Locally, the request took around 22 seconds and worked.

Production was terminating it after 10 seconds.

The application code wasn't the only thing that mattered. The execution environment mattered too.

Check the platform before changing your code

There was no 10-second timeout configured in my repository.

The useful information was in the Vercel runtime logs and project settings.

Don't immediately blame the AI provider

The request reached OpenRouter, and the same model worked locally.

There wasn't enough evidence to blame the provider.

Don't blindly increase timeouts

First find out which layer is timing out.

In this case, the function itself was being terminated before the AI completion could return.

Measure again after every fix

Enabling Fluid Compute fixed the 504.

It also made the next problem visible:

Why is the request still taking ~25 seconds?

Measure first. Change second.

That's probably the simplest way I can describe this debugging session.

I started with a strange frontend error.

Then I checked the Network tab.

Then the production logs.

Then the repository configuration.

Then the Vercel project settings.

Each step removed another assumption.

Eventually, the 504 made sense.

The actual fix was only one setting.

Finding that setting was the debugging work.

The application is live here if you want to have a look:

https://www.pssmumbai.org/

Part 2: Why is the AI still taking ~25 seconds?

The timeout is fixed.

The request now completes successfully in production.

But waiting 25+ seconds for an AI response isn't something I want to leave alone.

So now I'm trying to find out where those seconds are actually going.

Is it the AI request?

Context retrieval?

Database work?

Something else?

I don't know yet.

That's what I'm measuring now.

Part 2 will be about finding that answer.

I Spent $5 on OpenRouter While Building AI Features for an NGO App

nishchal singh — Thu, 03 Sep 2026 13:01:15 +0000

I've been working on the PSS website for quite some time, and recently a lot of my work went into its AI features.

The application already handles sessions, events, staff, blog posts, gallery, testimonials, donations, settings, and an admin CMS.

For the AI work, I wanted two things:

PSS-specific information available to the user-facing AI
AI-assisted content creation inside the admin CMS

The stack is Next.js, React, TypeScript, MongoDB, Mongoose, Clerk, Cloudinary, Tailwind CSS, shadcn/ui, TanStack Query and OpenRouter.

During development, my OpenRouter dashboard reached about $4.99 in total spend.

The $5 isn't the interesting part.

What happened while building the features is.

Giving the AI PSS-specific knowledge

I didn't want the AI to answer PSS-related questions only from its general knowledge.

I needed information that the application could control and update.

So I built a knowledge flow around approved PSS content:

Approved PSS knowledge
        ↓
     Chunking
        ↓
    Embeddings
        ↓
     MongoDB
        ↓
Relevant knowledge retrieved
        ↓
    AI context
        ↓
 Response / content generation

The stored knowledge includes the content plus details such as its source, authority, status and visibility.

That also gives me a way to separate public knowledge from internal AI guidance and policies.

The idea I ended up using is simple:

The knowledge base decides what PSS teaches. The model decides how to communicate it.

That became much more important once I started checking the generated content.

AI inside the admin CMS

The admin CMS also has AI-assisted blog creation.

AI can help generate:

title/context
tags
SEO title
SEO description
excerpt
full article

I didn't want one button to generate an entire blog post from nothing.

For smaller fields, the admin can run individual AI actions. Full article generation is a separate flow.

The article generation can use the information already entered in the editor:

Title
Category
Tags
SEO title
SEO description
Excerpt
Writing instruction
Relevant PSS knowledge
        ↓
     AI model
        ↓
 Generated article
        ↓
   Article editor

This is much more useful than sending something generic like:

"Write a blog post about meditation."

The application already has context. The AI should use it.

The first problem: the article stopped halfway

My first full-article generation didn't finish.

The logs showed:

model: openai/gpt-5-mini
task: full_article
promptTokens: 1013
completionTokens: 1800
finishReason: length

The application reported:

AI generation reached the model's output limit.

I increased:

AI_CONTENT_MAX_TOKENS

from 1800 to 2000, and after testing again, the generation completed.

It was a small configuration issue, but it reminded me that an AI feature has limits that a normal API call doesn't have.

The request can succeed while the output is still incomplete.

The application needs to detect and handle that.

Then I found a bigger problem

The generated article looked good.

That was actually the problem.

When I compared it with the approved PSS knowledge, I found some contradictions.

The approved information included specific guidance around:

clasped/interlaced hands
closed eyes
natural breathing
avoiding breath manipulation
other PSS-specific meditation instructions

The generated article introduced more general meditation advice, including things like resting the hands in the lap or on the knees, allowing the eyes to remain open, and suggesting specific practice durations.

Those suggestions may sound reasonable for meditation in general.

But the website isn't publishing generic meditation advice.

It represents PSS.

So the output can be well written and still be wrong for the application.

That was the most useful thing I found during testing.

RAG became more than a search problem

Before this work, I mostly thought of retrieval as a way to give the model better information.

Now I also see it as a way to keep the application's content under control.

The embeddings help find relevant information, but the application still needs to know:

Is the information approved?
Is it public?
Where did it come from?
Who is the authority?
Is the document active?
Should this information be used for this AI workflow?

So it isn't simply:

documents → embeddings → model

There is an application around it.

The admin UI mattered too

Getting the backend generation working wasn't enough.

While using the admin workflow, I also found that the AI actions needed to behave like normal application features.

I worked on things such as:

clearer generation states
disabling relevant fields while generation is running
loading/progress feedback
better AI action buttons
separate actions for smaller fields
clearer error messages
keeping the writing instruction separate from generated content
putting generated content into the article editor

Adding AI doesn't remove normal UX problems.

It gives you a few more.

What did the $4.99 actually show?

My OpenRouter dashboard showed approximately:

Total spend: $4.99
Requests: ~1K
Token volume: 73.5M
Cache hit rate: 94.7%
Blended cost: $0.07 / 1M

The dashboard also showed usage from GPT-5.4, GPT-5 Mini and Text Embedding 3 Small.

One clarification: 73.5M is the token-volume metric shown by the dashboard. I wouldn't describe it as 73.5M tokens of generated text.

Most of this usage came from development, testing AI flows, model calls and embeddings.

The useful part wasn't getting a lot of AI work done for $5.

It was being able to see what experimentation actually costs.

The 94.7% cache hit rate also made me think more about repeated context and what these costs could look like with more traffic.

What I'm checking now

I'm trying not to judge an AI feature only by whether the API returns a successful response.

I also need to ask:

Does the generated content use the right knowledge?
Can it introduce unsupported information?
Can it contradict approved information?
What happens when the output limit is reached?
Does the UI clearly show that generation is running?
What happens when generation fails or hits a rate limit?
Should a person review generated content before publishing?

Some of these are things I've already encountered during development. Others are areas I still want to make more systematic with testing.

The AI system isn't finished.

What I'd do earlier next time

If I started this part of the project again, I'd think about the knowledge and failure cases earlier.

Not only:

Which model should I use?

But also:

What information should the AI use?

What information should it never use?

What happens when there is no relevant information?

What happens when the model doesn't finish?

How do I know the generated content is acceptable?

The model is only one part of the feature.

The rest is application engineering.

Final takeaway

The biggest thing I learned wasn't about a particular model.

It was that adding AI to an existing application means dealing with a lot more than an API call:

knowledge retrieval
embeddings
prompt context
content generation
token limits
model selection
caching
cost
admin UX
error handling
validation
testing
human review

The AI can generate a very good-looking article.

I still have to ask:

Is this actually what we want the application to say?

For this project, that question matters more than whether the model produced a polished paragraph.

You can see the application here:

https://www.pssmumbai.org/

If you're building AI into an existing application, I'd be interested to hear what surprised you after the first successful API response.

Why Your Nextjs UI Flickers: TanStack Query vs useEffect

nishchal singh — Wed, 13 May 2026 03:04:49 +0000

A page can load quickly and still feel unstable.

That usually happens when the initial render strategy is fine, but client-side data updates are handled poorly.

In this article, we’ll compare two common approaches:

A basic useEffect fetch
A production-ready pattern using TanStack Query

Both fetch the same API under the same network conditions.

One flickers.

The other stays smooth.

The Experiment

I built a small Next.js Rendering Lab to visualize:

SSR
CSR
SSG
ISR
Hydration
Cached background refetching
UI flicker caused by naive fetching

Both components:

call the same endpoint
refetch every few seconds
run under throttled network conditions
display live telemetry

Naive `useEffect` Fetching

A common pattern looks like this:

useEffect(() => {
  setLoading(true);

  fetch("/api/data")
    .then((res) => res.json())
    .then((data) => {
      setData(data);
      setLoading(false);
    });
}, []);

This works, but on every refetch:

loading state resets
content disappears
layout shifts
charts blink

The data may arrive quickly, but the interface feels unstable.

TanStack Query

TanStack Query handles updates differently.

It:

keeps previous data visible
fetches in the background
updates only changed values
avoids unnecessary loading states

The result is a much smoother experience.

Users continue seeing the existing UI while fresh data is being fetched.

Rendering Strategy vs Data Strategy

These are two separate concerns.

Rendering Strategy

Determines how the page initially loads.

Data Strategy

Determines how the UI behaves after hydration.

useEffect
TanStack Query
SWR
caching
background refetching

A page can be server-rendered and still flicker if data updates are handled poorly.

Why This Matters

This becomes obvious in:

dashboards
analytics tools
admin panels
live metrics
stock tickers
collaborative applications

Users may not understand hydration or caching, but they notice:

flicker
disappearing content
layout shifts
unstable interfaces

Good frontend UX is often about preserving visual stability.

Try the Rendering Lab

Live Demo:
Next.js Rendering Lab

Source Code:
GitHub Repository

Watch the YouTube Short

I also recorded a short visual comparison showing both patterns side by side under Slow 4G throttling.

Final Thoughts

The biggest lesson from this experiment:

Performance is not only about speed. It is also about stability.

Two apps can fetch data at almost the same speed but feel completely different depending on how updates are handled.

TanStack Query does not make your API faster.

It makes your UI behave better.

And users notice that immediately.

Why Date and Time Bugs Happen in JavaScript (And How Apps Actually Get It Right)

nishchal singh — Tue, 10 Feb 2026 11:46:37 +0000

If you’ve ever seen reminders fire early, late, or on the wrong day,

this post is for you.

I used to think date and time bugs were just edge cases.

They’re not.

Most of the time, they come from a slightly wrong mental model of how
time actually works in JavaScript. The problem only becomes visible
when an app starts dealing with real users, real schedules, and real
expectations.

This post explains why these bugs happen so often, how JavaScript really
handles date and time, and how production apps avoid them.

No heavy theory.
No library comparisons.
Just the parts that matter.

The illusion: “I used `Date()`, so time should be correct”

Most developers start with this:

new Date()

It prints a date and time that looks correct, so we assume everything
underneath is local and intuitive.

That assumption is where many bugs begin.

JavaScript dates are not stored as local time.

Internally, they are stored as:

Milliseconds since January 1, 1970 (UTC)

Local time, timezone, and formatting are applied only when the date is
read or displayed.

This sounds like a small detail.
In real apps, it isn’t.

What JavaScript is actually doing

A useful mental model is this:

JavaScript stores one number
That number represents a moment in UTC
Local time is calculated only at display or formatting time

For example:

new Date("2026-02-10T09:00:00")

This does not mean “9am in my timezone”.

It means “9am UTC, converted to the user’s local timezone”.

If your app does not control that context explicitly, time slowly drifts.

The three most common time mistakes

1. Assuming `Date()` is local internally

Date behaves like a local clock, but it is not one.

It is a UTC timestamp with a local view layered on top.

This becomes a problem when:

users are in different timezones
servers run in UTC
background jobs don’t share locale information

2. Mixing server time and client time

A very common pattern:

server schedules something
client displays or adjusts it
background job runs later

If these layers don’t agree on what “now” means, reminders drift.

This is especially dangerous for:

recurring schedules
weekly reminders
“tomorrow at 9am” logic

3. Generating dates without context

Any logic that generates dates needs to know:

today’s date
the user’s timezone
daylight saving rules

Without this context, it’s easy to generate reminders:

in the past
on the wrong day
in the wrong year

Why this gets worse in PWAs

These problems become much more visible in Progressive Web Apps.

Browsers are not designed to guarantee precise scheduling.
They optimize for:

battery life
performance
security

As a result:

background execution is delayed
service workers wake unpredictably
scheduled logic runs in time windows, not exact moments

I ran into this while building a productivity app where reminders and
check-ins were core features.

Notifications worked.
Nothing crashed.
But timing was unreliable.

I wrote about that experience here:

When Notifications Matter, PWAs Start to Show Their Limits

https://dev.to/nishchaldev/when-notifications-matter-pwas-start-to-show-their-limits-5ebl

That post explains where things broke.
This post explains why.

How mature apps avoid time bugs

Once I looked at how established reminder apps work, a clear pattern
emerged.

One clear definition of “now”

There is exactly one source of truth for current time:

based on the device timezone
or an explicit user setting

No guessing.
No hidden defaults.

Store in UTC, schedule in local time

This is the most important rule.

Store timestamps in UTC
Convert to local time for display
Schedule alarms using local context

This avoids:

daylight saving bugs
timezone drift
unexpected early or late triggers

Let the OS handle scheduling

On native platforms, reminders are scheduled using system services.

The operating system:

reschedules after reboots
adjusts for timezone changes
guarantees delivery timing

JavaScript logic does not need to stay alive.

The shift that fixed my app

After understanding these patterns, I changed the architecture:

the web app handles dashboards and planning
the native layer handles scheduling and notifications
the backend stores everything in UTC
time context is always explicit

The same product logic runs everywhere, but time-sensitive
responsibilities live where they belong.

The app is still evolving, but the difference is noticeable.

Live app:

https://wio-dev.vercel.app

A simple rule that helps

If you remember only one thing, remember this:

Time is not a utility. It’s a product feature.

If your app depends on time being correct:

model it deliberately
pass context explicitly
let the platform handle scheduling

Closing thought

JavaScript dates are not broken.
Browsers are not broken.

Most time bugs come from assumptions that feel reasonable until real
users and real schedules expose them.

Once your mental model matches how time actually works, things become
much simpler.

A question for you

Have you run into confusing date or timezone bugs?
How are you handling reminders or schedules today?
Did this explanation match what you’ve seen in practice?

I’d genuinely love to hear how others are dealing with this.

When notifications matter, PWAs start to show their limits

nishchal singh — Sat, 07 Feb 2026 08:37:57 +0000

I was getting notifications at 3am.

Users were confused.

I hadn’t changed anything.

That’s when I realized something uncomfortable:

PWAs don’t really understand time the way we expect them to.

Nothing was “broken” in the obvious sense.

Reminders worked. Notifications appeared. Logs looked fine.

But for a productivity app — where reminders and check-ins are the product —

“mostly works” isn’t good enough.

This post is about what went wrong, why it wasn’t actually a bug, and why I eventually stopped relying on a pure PWA setup for time-critical notifications.

When PWAs work great (and when they don’t)

If your app needs:

in-app banners
occasional push notifications
background sync when possible

PWAs are an excellent choice.

They’re fast to build, easy to ship, and good enough for many products.

But reminders are different.

A reminder isn’t just a notification.

It’s a promise about time.

And time is where PWAs start to show their limits.

How PWA notifications really behave

When a PWA is open:

JavaScript is running
the user’s local time is known
scheduling logic is predictable

Things feel solid.

The problems start once the app is closed or backgrounded.

At that point:

the browser decides when background work runs
service workers wake up only under certain conditions
push delivery is best-effort
timing happens in windows, not exact moments

A “scheduled” notification often looks like this:

a backend job checks reminder time
timezone logic runs on the server
a web push is sent
the browser decides when (or if) to wake the service worker
the OS eventually shows the notification

Each step makes sense on its own.

Together, they introduce uncertainty.

This isn’t bad engineering.

It’s how browsers are designed.

Browsers optimize for battery life, performance, and security —

not precise scheduling guarantees.

Where things actually broke for me

At first, I assumed this was just a PWA limitation.

Then I wrapped the app with a native Android container and refactored the notification flow.

Some issues still showed up.

That’s when it became clear:

Notification reliability isn’t just about platform choice.

It’s also about how your app understands time itself.

Looking at how mature reminder apps work made the gaps obvious.

What real reminder apps get right

Apps like Google Calendar, TickTick, and Any.do all follow the same principles.

One clear definition of “now”

There is a single authoritative source of current time —

based on device timezone or an explicit user setting.

No guessing.

No hidden defaults.

Store in UTC, schedule in local time

Events are stored in UTC.

They’re converted to local time only for display and scheduling.

This avoids slow, painful bugs around daylight saving and timezone changes.

OS-level scheduling

Reminders are scheduled using system services (for example, AlarmManager on Android).

They’re automatically rescheduled when:

the device restarts
the timezone changes
daylight saving rules shift

The OS owns delivery — not JavaScript.

No dates without context

Any AI planner or automation that generates dates is explicitly told:

“Today is YYYY-MM-DD in this timezone.”

Without this, it’s surprisingly easy to generate reminders in the past or wrong year without noticing.

The real issues in my app

Once I stepped back, the problems were surprisingly basic:

timezone defaulting to UTC instead of user locale
AI planner not receiving current date and timezone explicitly
weekly reminders drifting due to timezone conversion
limited control over notification channels and sounds

These aren’t exotic bugs.

They’re the kind that appear only after real users and real time collide.

Why Android behaves more predictably

On Android, the mental model is simpler:

the app schedules the reminder locally
the OS owns the timing
the notification fires when expected

Even if:

the app is closed
the process is killed
the device restarts

Notifications are first-class system features.

That’s why:

sound and vibration are consistent
notification channels behave correctly
widgets are possible
background behavior is predictable

This isn’t about Android being “better”.

It’s about using the platform for what it was designed to do.

The setup that finally made sense

For this app, reminders and check-ins aren’t optional.

They are the product.

So the architecture that aligned best was:

Web app (desktop)

dashboards
insights
planning and review

Android app (Capacitor wrapper)

native scheduling
OS-level notifications
background reliability

Same backend.

Same database.

Same product logic.

Different delivery mechanisms — matched to platform strengths.

A simple rule of thumb

If notifications are a nice-to-have → PWAs are usually fine
If notifications are a core promise → let the OS handle timing

That distinction would have saved me weeks.

Final thought

PWAs aren’t unreliable.

They’re just not designed to guarantee time.

Native platforms are.

Once you align product expectations with what a platform can realistically promise, a lot of confusion — and frustration — disappears.

Quick question for you

Have you faced random notification timings in PWAs?
How are you handling scheduled reminders today?
Would you still choose a PWA if notifications were critical?

I’m genuinely curious how others are solving this.

Live app (still evolving):

👉 https://wio-dev.vercel.app

Object Cloning in Javascript

nishchal singh — Fri, 01 Mar 2024 05:43:13 +0000

While coding in Javascript have you ever encountered a situation where you needed to copy an object? and when you try to copy an object, you face some issues like all of the properties are not cloned, or when changing the copied object somehow the original object is changed, leaving you without the desired results. Well, In this article we'll explore some simple solutions to these issues.

First thing that came to your mind is that why not simply use 🟰 to copy objects, but it'll not work b'coz Javascript objects are reference type values. worry not, there are 3 basic ways of object cloning:

const originalObject = { name: 'John', age: 30 };

// Using Spread Operator (...)
const spread_Cloned = { ...originalObject };

// Using Object.assign() Method
const assign_Cloned = Object.assign({}, originalObject);

// Using JSON.stringify() and JSON.parse() 
const cloned_JSON = JSON.parse(JSON.stringify(originalObject));

console.log(spread_Cloned); // { name: 'John', age: 30 }
console.log(assign_Cloned); // { name: 'John', age: 30 }
console.log(cloned_JSON); // { name: 'John', age: 30 }

Introduction

If you're dealing with tricky data setups, making exact copies, or just want to keep things from changing unexpectedly, copying objects can be super helpful in JavaScript. This article is all about diving into object cloning in JavaScript. We'll check out different ways to do it and figure out when and why it's important. By the time you finish reading, you'll totally get how to clone objects and be ready to use it in your own coding projects.

Shallow Clone vs Deep Clone

When you shallow clone something in JavaScript, you're basically making a copy that only goes skin-deep. It means you get a new object with the same basic stuff as the original, but if those basic things include other objects, those aren't copied – they're just referenced. Now, deep cloning is like making a photocopy of everything. You get a brand-new object where every little thing, even the stuff inside other stuff, gets copied over completely. So, you end up with a totally separate copy of everything from the original.

Techniques for Object Cloning

Using Spread Operator (...)

The spread operator in JavaScript is a concise and efficient way to clone objects. It allows us to create a copy of an object, including all its enumerable properties, into a new object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = { ...originalObject };

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Very simple syntax
Supports cloning both Shallow and moderately nested objects

Limitations:

Cannot handle deeply nested objects
Does not clone non-enumerable properties or methods

Using Object.assign() Method

The Object.assign() method is another powerful technique to clone objects. It copies the values of all enumerable properties from one or more source objects into a target object, returning the target object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = { ...originalObject };

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Handles cloning of non-enumerable properties and methods
Supports cloning moderately nested objects

Limitations:

Cannot clone deeply nested objects directly
Overwrites properties if they already exist in the target object

Using JSON.stringify() and JSON.parse()

The combination of JSON.stringify() and JSON.parse() methods can be used as a workaround for cloning complex objects. By converting the object to a JSON string and then parsing it back into an object, we can achieve a Deep Clone of the original object.

const originalObject = { name: 'John', age: 30 };
const clonedObject = JSON.parse(JSON.stringify(originalObject));

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Supports cloning deeply nested objects
Can be used to clone objects with circular references

Limitations:

Does not preserve non-enumerable properties or methods
May not preserve certain data types (e.g., dates, regular expressions) during cloning
.

Using Third-party Library

Lodash is a popular JavaScript utility library that provides a powerful method called cloneDeep() for object cloning. It performs a deep copy of the entire object hierarchy, ensuring accurate replication of the original object's structure.

const originalObject = { name: 'John', age: 30 };
const clonedObject = _.cloneDeep(originalObject);

console.log(clonedObject); // { name: 'John', age: 30 }

Advantages:

Can handle cloning of any level of object nesting
Preserves non-enumerable properties and methods

Limitations:

Adds a dependency on an external library (Lodash)
May have performance implications for large objects due to deep copying

If you don't want to use any third-party library, there is an alternate solution: using a custom deep cloning function we'll discuss it further in this article. Both have their advantages and limitations.

Shallow Cloning

Shallow cloning is the simplest form of object cloning. It creates a new object with the same top-level properties as the original object. However, if those properties are themselves objects, they are still references to the original objects. Shallow cloning is a quick and easy way to duplicate objects when there's no need to clone nested objects.

Shallow Clone Example:

const originalObject = {
  name: 'John',
  age: 25,
  hobbies: ['reading', 'swimming'],
};

const clonedObject = { ...originalObject };

In this example, the spread operator (...) creates a shallow clone of originalObject. Although clonedObject appears to be an identical copy, modifying the hobbies property in either object will affect both, as they still share a reference to the same array.

We can fix this issue by Deep Cloning.

Deep Cloning

Deep cloning is a more thorough form of object cloning. It creates a new object and recursively clones all nested properties and their descendants, ensuring each object is an independent copy. Deep cloning is indispensable when working with complex data structures and avoiding unintended side effects.

Using JSON.stringify() and JSON.parse():

//Deep Clone Using JSON.stringify() and JSON.parse()
const originalObject = {
  name: "John",
  age: 30,

  // Nested object
  address: {
    city: "New York",
    state: "NY",
  },

  // Method
  doAction: function () {
    console.log(this.name + " is walking in " + this.address.city);
  },
};
const clonedObject = JSON.parse(JSON.stringify(originalObject));

console.log(clonedObject);
 // { name: 'John', age: 30, address: { city: 'New York', state: 'NY' } }

As we can see in the above example we are losing our data, the method "doAction" is not cloned b'coz it does not preserve non-enumerable properties or methods. The solution for this issue is given below.

Using Custom Recursive Function:

// Deep Clone Using Custom Recursive Function
// Custom Recursive Function 
function deepClone(obj, visited = new WeakMap()) {
  // Handle non-object types and null
  if (obj === null || typeof obj !== 'object') {
    return obj;
  }

  // Handle circular references
  if (visited.has(obj)) {
    return visited.get(obj);
  }

  // Handle dates
  if (obj instanceof Date) {
    return new Date(obj.getTime());
  }

  // Handle regular expressions
  if (obj instanceof RegExp) {
    return new RegExp(obj);
  }

  // Handle arrays
  if (Array.isArray(obj)) {
    const cloneArray = [];
    visited.set(obj, cloneArray);
    obj.forEach((item, index) => {
      cloneArray[index] = deepClone(item, visited);
    });
    return cloneArray;
  }

  // Handle objects
  const cloneObj = {};
  visited.set(obj, cloneObj);
  for (let key in obj) {
    if (Object.prototype.hasOwnProperty.call(obj, key)) {
      cloneObj[key] = deepClone(obj[key], visited);
    }
  }
  return cloneObj;
}

const clonedObject = deepClone(originalObject);
console.log(clonedObject); /*{
  name: 'John',
  age: 30,
  address: { city: 'New York', state: 'NY' },
  doAction: [Function: doAction]
}*/

console.log(clonedObject.doAction()); // John is walking in New York

In this example, deepClone is a recursive function that clones all properties and nested objects of originalObject. The resulting clonedObject is a deep copy, ensuring no changes made to original one and no object will impact the other.

We use a WeakMap to keep track of visited objects to handle circular references.
We add support for cloning Date objects and RegExp objects.
We handle cloning of arrays and objects separately to ensure correct cloning and handling of circular references.
We use Object.prototype.hasOwnProperty.call(obj, key) to ensure that properties from the object's prototype chain are not mistakenly cloned.

This deepClone function can handle a wider range of data types and scenarios.

Let's see another example of 'deepClone' function with different data types:

// Define an object with various data types including arrays, objects, dates, and regular expressions
const originalObject = {
  string: "Hello",
  number: 123,
  boolean: true,
  array: [1, 2, 3],
  object: { a: 1, b: 2 },
  date: new Date(),
  regexp: /test/g,
};

// Add circular reference
originalObject.circular = originalObject;

// Clone the original object
const clonedObject = deepClone(originalObject);

// Modify the cloned object
clonedObject.string = "Modified";
clonedObject.number = 456;
clonedObject.array.push(4);
clonedObject.object.c = 3;

// Log both original and cloned objects
console.log("Original Object:", originalObject);
/*Original Object: <ref *1> {
  string: 'Hello',
  number: 123,
  boolean: true,
  array: [ 1, 2, 3 ],
  object: { a: 1, b: 2 },
  date: 2024-02-23T13:18:38.521Z,
  regexp: /test/g,
  circular: [Circular *1]
}*/
console.log("Cloned Object:", clonedObject);
/*Cloned Object: <ref *1> {
  string: 'Modified',
  number: 456,
  boolean: true,
  array: [ 1, 2, 3, 4 ],
  object: { a: 1, b: 2, c: 3 },
  date: 2024-02-23T13:18:38.521Z,
  regexp: /test/g,
  circular: [Circular *1]
}*/

in this example:

We define an originalObject containing various data types including arrays, objects, dates, and regular expressions.
We add a circular reference to the originalObject.
We then clone the originalObject using the deepClone function.
We modify some properties of the cloned object to demonstrate
that the original object remains unaffected by the modifications to the clone.
Finally, we log both the original and cloned objects to see the differences.

The deepClone function has several advantages and limitations:

Advantages:

Deep Cloning: The function can recursively clone nested objects and arrays, ensuring a deep copy of the original object.
Support for Various Data Types: It supports cloning of various data types including objects, arrays, dates, and regular expressions, making it versatile for different use cases.
Handling Circular References: It can handle circular references gracefully by keeping track of visited objects using a WeakMap, preventing infinite recursion.
Maintains Object Structure: It maintains the structure of the original object, including nested objects and arrays, ensuring the cloned object has the same structure.
Flexible and Customizable: It can be extended to support additional data types or custom cloning logic based on specific requirements.

Limitations:

Performance: Deep cloning can be computationally expensive, especially for large and deeply nested objects, potentially leading to performance issues.
Prototype Chain: It does not preserve the prototype chain of objects. Cloned objects will lose their original prototype chain and inherit from Object.prototype.
Non-Clonable Properties: Certain properties like non-enumerable properties or properties with getters/setters may not be cloned accurately.
External References: If the original object contains references to external resources or mutable shared state, the cloned object will still reference the same external resources, potentially leading to unintended side effects.
Memory Consumption: The use of a WeakMap for handling circular references may consume additional memory, especially for large datasets with many circular references.

Overall, while the deepClone function provides a robust solution for deep copying objects, it's important to be aware of its limitations and potential impact on performance and memory usage, especially in scenarios involving large or complex data structures.

Conclusion

Remember, when cloning objects, it's crucial to choose the appropriate method based on your specific needs. Whether you opt for native JavaScript techniques or leverage external libraries like Lodash or Immer, object cloning is a valuable tool for maintaining data integrity and preventing unintended side effects.

So, the next time you find yourself needing to duplicate an object in JavaScript, don't go down the path of manual copying and mutation. Instead, harness the power of object cloning and unlock a world of possibilities.

"Object cloning in JavaScript is the key to maintaining data integrity and avoiding unintended side effects."

Overview of ReactJs

nishchal singh — Tue, 12 Dec 2023 14:14:59 +0000

Whenever the development community talks about modern web development stacks, the word "ReactJS" is often mentioned. It's one of the widely used tech stacks for web development, In this article, we'll take an overview of ReactJS.

What is ReactJs?

ReactJS, or simply React, is like a superhero or supertool for building websites and web applications. It's a special set of tools and rules that helps people create websites that are not only really cool but also super fast and easy to work with.

React is a JavaScript-based front-end library used for UI(user interface) development. It's used to create modular user interfaces and promotes the development of reusable UI components that display dynamic data. React is often used to build single-page applications (SPAs).

Concept of ReactJS

his is Hashnode's homepage as we can see here a react application is made from independent components that together make a whole web application. The search bar in the top header is a reusable component. the same search bar component is used in the other sections of this app.

Key concepts and principles of ReactJS include:

Component-Based Architecture: React is built around the idea of breaking down user interfaces into reusable, self-contained components. These components can range from simple elements like buttons or form inputs to complex parts of the user interface like navigation bars or entire pages. By building UIs as components, development becomes modular, maintainable, and scalable.

Virtual DOM (Document Object Model): React introduced the concept of a Virtual DOM which is like a lightweight copy of the actual DOM. virtual DOM is an abstract representation of the actual DOM in the browser. When data in a React application changes, React doesn't directly manipulate the real DOM. Instead, it creates a virtual representation of the changes and efficiently updates only the parts of the real DOM that need to change. This approach minimizes browser reflows and enhances performance.

The image below is a visual representation of the concept of the virtual DOM:

Unidirectional Data Flow: React follows a unidirectional data flow, where data moves in one direction, usually from parent components to child components. Child components cannot send data back to their parent components. This design minimizes errors and gives us greater control over our code.

As shown in the diagram below, data can only flow from top to bottom:

Component Lifecycle: React components have a lifecycle that includes various methods such as componentDidMount, componentDidUpdate, and componentWillUnmount. These lifecycle methods allow developers to hook into different stages of a component's existence and perform actions like data fetching, DOM manipulation, or cleanup.

State in React: In ReactJS, "state" refers to a built-in feature that allows you to manage and store data within a component. State represents the internal data of a component that can change during the component's lifecycle, and when it does change, React will automatically re-render the component to reflect the updated state.

State acts as a storage space for data essential for a component's functioning. It's versatile, capable of holding different data types like numbers, strings, arrays, or objects. Unlike props, which are unchangeable and flow from parent to child components, state is changeable. Components have the power to modify their own state through React's setState method.

Reactivity: React encourages a reactive approach to UI development. When the state or props of a component change, React automatically re-renders the component to reflect those changes. This reactivity simplifies UI updates and ensures that the UI always matches the application's data.

State Management: React components can effectively handle their internal state using either the useState hook for functional components or class-based state for class components. These approaches allow components to store and update data within themselves.

For more intricate applications, developers often turn to state management libraries like Redux or Mobx. These libraries centralize and manage state across the entire application, making it easier to handle complex data interactions.

For instance, consider a web application with dynamic notification functionality. State management ensures that notifications can be added, removed, and displayed in real-time without the need for complex manual updates. Similarly, in an online shopping cart, managing the dynamic count of items and their state helps ensure a seamless and responsive user experience.

JSX (JavaScript XML): JSX, which stands for JavaScript XML, is a powerful feature in React. It's like a special language that React developers use to describe how a component should look. Imagine it as a blend of HTML and JavaScript that makes building user interfaces more intuitive.

With JSX, you can write your user interface code in a way that closely resembles HTML. This not only makes it easier to understand but also helps you visualize your UI components. However, under the hood, JSX gets converted into regular JavaScript using tools like Babel before it's shown in the browser.

One of the cool things about JSX is that you can embed JavaScript expressions within curly braces {}. This means you can include dynamic content, variables, and calculations right alongside your JSX code. It's a flexible way to create dynamic and interactive user interfaces in React.

import React from 'react';

function Greeting(props) {
  const name = props.name;
  const isLoggedIn = props.isLoggedIn;

  // Define a JavaScript function to conditionally render a greeting message
  function getGreeting(name) {
    if (isLoggedIn) {
      return <p>Hello, {name}!</p>;
    } else {
      return <p>Please log in.</p>;
    }
  }
  return (
    <div>
      {/* Embed JavaScript expression to render the greeting message */}
      {getGreeting(name)}
    </div>
  );
}
export default Greeting;

Community and Ecosystem: React has a vast and active community, resulting in a rich ecosystem of third-party libraries, tools, and extensions. These resources make it easier for developers to build feature-rich and performant applications.

How Does ReactJS Work?
ReactJS works by utilizing a component-based architecture to build user interfaces efficiently. It uses a Virtual DOM to optimize updates, enforces a unidirectional data flow for predictable behavior, and allows developers to define UI components using JSX, which is transpiled into JavaScript. React updates the actual DOM efficiently, making it ideal for creating dynamic and interactive web applications.

Conclusion
ReactJS stands as a powerful and pivotal force in modern web development. Its component-based architecture, Virtual DOM, and unidirectional data flow provide developers with a robust toolkit to create dynamic and responsive user interfaces. React's flexibility, combined with a thriving community and extensive ecosystem, makes it a top choice for building web applications that are not only efficient and maintainable but also user-friendly. As we've explored in this overview, ReactJS empowers developers to bring their web projects to life with elegance and precision, setting new standards for web development in the digital age. Whether you're a seasoned developer or just beginning your journey, ReactJS remains a technology worth exploring and mastering.

DEV Community: nishchal singh

OpenRouter Returned 200, But My Next.js AI Stream Was Empty

The setup

The streaming architecture I had built

Then production failed

Vercel was killing the function

The timeout moved

Then OpenRouter returned 200

I stopped patching the parser

The actual problem was architectural

The fix: one authoritative streaming path

I didn't rewrite the frontend

The first successful end-to-end test

But it was still slow

Working and fast are different problems

What I'd change if I built it again

The NGO App's AI Worked Locally. Then Vercel Gave Me a 504.

The error was hiding the actual problem

But it worked locally

Vercel gave me the useful error

Where was that 10-second limit coming from?

The fix

One important clarification

But then I noticed something else

What I learned from this

Don't trust the first error

Local success doesn't guarantee production success

Check the platform before changing your code

Don't immediately blame the AI provider

Don't blindly increase timeouts

Measure again after every fix

Measure first. Change second.

Part 2: Why is the AI still taking ~25 seconds?

I Spent $5 on OpenRouter While Building AI Features for an NGO App

Giving the AI PSS-specific knowledge

AI inside the admin CMS

The first problem: the article stopped halfway

Then I found a bigger problem

RAG became more than a search problem

The admin UI mattered too

What did the $4.99 actually show?

What I'm checking now

What I'd do earlier next time

Final takeaway

Why Your Nextjs UI Flickers: TanStack Query vs useEffect

The Experiment

Naive useEffect Fetching

TanStack Query

Rendering Strategy vs Data Strategy

Rendering Strategy

Data Strategy

Why This Matters

Try the Rendering Lab

Watch the YouTube Short

Final Thoughts

Why Date and Time Bugs Happen in JavaScript (And How Apps Actually Get It Right)

If you’ve ever seen reminders fire early, late, or on the wrong day,

The illusion: “I used Date(), so time should be correct”

What JavaScript is actually doing

The three most common time mistakes

1. Assuming Date() is local internally

2. Mixing server time and client time

3. Generating dates without context

Why this gets worse in PWAs

How mature apps avoid time bugs

One clear definition of “now”

Store in UTC, schedule in local time

Let the OS handle scheduling

The shift that fixed my app

A simple rule that helps

Closing thought

A question for you

When notifications matter, PWAs start to show their limits

I was getting notifications at 3am.

When PWAs work great (and when they don’t)

How PWA notifications really behave

Where things actually broke for me

What real reminder apps get right

One clear definition of “now”

Store in UTC, schedule in local time

Then OpenRouter returned `200`

Naive `useEffect` Fetching

The illusion: “I used `Date()`, so time should be correct”

1. Assuming `Date()` is local internally