Forem: Yasir Ansari

Building a React Native + Web3 Project - Looking for Developers in the Same Space

Yasir Ansari — Tue, 31 Mar 2026 22:08:19 +0000

I'm working on a React Native + Solana project. Learning one thing at a time, sharing updates as I go, and figuring things out along the way.

Looking to Connect

If you're building with any of these:

React Native / Expo
Web3 / Solana / Blockchain
GenAI / LLMs
Next.js

I started a Telegram community for exactly this — a place to share
what you're working on, ask questions, discuss decisions, and connect with people in the same domain.

No noise. Just developers working on similar things.

Join

👉 https://t.me/+XEa-UVHL3HY0ODA1

Say what you're building when you join. That's the best way to start.

Minologue: Why I Started Building This Boring AI Application

Yasir Ansari — Fri, 06 Mar 2026 20:28:11 +0000

A few months ago, I started thinking seriously about moving beyond frontend development.

For most of my career, I had been working as a frontend developer — building interfaces, polishing UI interactions, and working closely with product teams. But over time, I felt a growing curiosity about the systems behind the interface. I wanted to understand how the entire product worked, not just the layer users see.

So I made a small decision:

I would start learning and practicing full-stack development by building real things.

Like most developers, I had many product ideas floating around in my head. Ideas about tools I wanted to build, problems I noticed while working, concepts I wanted to explore, experiments I wanted to try.

And I realized something strange.

I had been thinking about these ideas for years — during work, during late nights learning something new, even back in college.

So I thought:

Maybe I should go back and look at all the ideas I've written before.

I started searching through my old notes.

Some were in phone notes.
Some were in random documents.
Some were written during college projects.
Some were half-written ideas saved somewhere in a folder I had forgotten existed.

A few pieces I managed to find.

But most of them were gone.

And the ones I did find had another problem — they were out of context.

Interesting idea about building discipline systems for Coders.

But I had no idea about:

What I meant when I wrote it.
Why did I think it was interesting?
What problem was I trying to solve?
What was the original thought behind it?

The idea was there — but the thinking behind it was lost.

That moment made me realize something important.

The problem wasn't that I wasn't writing ideas down.
The problem was that my ideas were scattered.

I tried to fix it.

I attempted to organize everything inside traditional note apps — folders, tags, categories, all the usual systems. For a moment it felt like it would work.

But then reality hit.

Human thoughts don't behave like folders.
Ideas don't arrive in neat categories.
They don't appear in fixed formats.
They don't wait until you're "ready to organize them."

Ideas are messy.

Sometimes they appear randomly while you're working.
Sometimes while you're reading something unrelated.
Sometimes while you're walking or solving a completely different problem.

And many of those ideas are incomplete.
Just fragments.

But fragments matter.

Because sometimes, months later, those fragments connect with something new.

And that's when a thought came to my mind.

What if instead of just storing notes, I built a memory system?

A system where ideas could be captured quickly, but more importantly recalled later. Something that could act like a digital library for my thoughts.

A place where ideas were not just stored — but traceable.
That idea slowly turned into a small project.

Not a flashy AI startup idea.
Not something trying to replace human thinking.

Just a small, practical tool.

A boring AI application, Minologue.
I call it boring because it doesn't try to be smart.

It doesn't know anything about the world.
It won't entertain you.
It won't generate random answers.

It only knows what you have told it.
That's it.

Its job is simple:

Help you rediscover your own ideas.
Help you reconnect thoughts that you once had.
Help you build on the thinking you've already done.

And that is how Minologue started.

But as a small system I wanted for myself,
a traceable ideas platform that could help me both:
• build products while learning full-stack development
• and keep track of the ideas that shape those products

In a way, Minologue become both:

a learning project
and a solution to a problem I had been quietly dealing with for years.

This project is just getting started.
I’ll keep updating it as I build.

If you're curious about how the system works:
• Architecture docs
• Devlogs
• System design decisions

You can explore everything here:
→ https://github.com/minologue/minologue-docs

[Boost]

Yasir Ansari — Tue, 17 Feb 2026 01:31:34 +0000

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

Yasir Ansari ・ Feb 16

#devops #webdev #programming #discuss

Railway app: running Logs: clean localhost: works Website: dead https://dev.to/yasir_etc/railway-url-timeouts-why-a-healthy-server-can-still-be-unreachable-5cc3

Yasir Ansari — Mon, 16 Feb 2026 10:02:54 +0000

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

Yasir Ansari ・ Feb 16

#devops #webdev #programming #discuss

The server is alive… but you’re talking to the wrong place.

Yasir Ansari — Mon, 16 Feb 2026 09:57:37 +0000

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

Yasir Ansari ・ Feb 16

#devops #webdev #programming #discuss

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

Yasir Ansari — Mon, 16 Feb 2026 09:56:42 +0000

My deployed backend on Railway kept timing out even though the server, logs, and health checks looked perfect. The culprit wasn't my code, my port configuration, or my deployment—it was my mobile hotspot's DNS resolver caching a stale IP address. This post explains what actually happened, why switching to Cloudflare DNS (1.1.1.1) fixed it instantly, and how DNS resolution can silently break modern cloud deployments.

The Situation

I had just deployed my backend to Railway at
https://0x*******-production.up.railway.app.

Everything worked perfectly locally:

curl localhost:8080 → ✅ OK
Server logs showed it running smoothly
Database connected successfully
Health check routes responded

But when I tried accessing the public url ERR_CONNECTION_TIMED_OUT
My immediate thought: The server must be crashing in production.

The Wild Goose Chase

Like any developer facing a production timeout, I went through the standard checklist:

✅ Verified port configuration (changed to 0.0.0.0)
✅ Checked SSL certificates
✅ Reviewed CORS settings
✅ Redeployed multiple times
✅ Checked firewall rules Nothing changed. The timeout persisted.

Then some random article I read suggested something seemingly unrelated:

"Try switching to Cloudflare DNS (1.1.1.1)"

I was skeptical, but I made the change. And instantly—the site opened. That single DNS change revealed the real problem: my application had been working perfectly the entire time.

Understanding DNS: The Internet's Phone Book

When you visit a URL like https://railway.app, your computer doesn't inherently know where that server lives. Here's what actually happens:

Your browser asks a DNS resolver: "What's the IP address for this domain?"
DNS responds with an IP: 0x*******-production.up.railway.app → 104.26.xx.xx
Your browser connects to that IP address
The server responds

The critical insight:
If DNS returns the wrong IP, your browser connects to the wrong machine. Your backend can be perfectly healthy and completely unreachable at the same time.

Why Modern Platforms Are Different

Traditional hosting uses fixed IP addresses. Deploy a server, get an IP, done.
Modern platforms like Railway, Vercel, and Cloudflare Pages work differently. They use Anycast CDN routing, which means:

The same domain resolves to different edge servers based on: Geographic location, Load balancing, Server availability.
IP addresses behind your domain change frequently
DNS records use extremely low TTL (Time To Live), often 60 seconds

This architecture enables global scale and resilience, but it requires DNS resolvers to respect TTL values and fetch fresh records constantly.

Good resolvers do this. Bad ones don't.

The Hidden Problem: My Mobile Hotspot's DNS

Here's what was actually happening on my network:
Laptop → Phone Hotspot → Mobile Carrier DNS → Internet

My laptop queried the hotspot's DNS server (172.20.10.1), which forwarded requests to my mobile carrier's resolver.

The carrier's DNS resolver cached an old Railway edge server IP address.

So every request from my browser went to a server that no longer hosted my application. The result? Connection timeout (not "connection refused").

This is critically deceptive:

A crashed server typically returns: connection refused
A wrong IP address returns: timeout

One suggests server failure. The other suggests... nothing specific.

Why Cloudflare DNS (1.1.1.1) Fixed It

When I switched to Cloudflare's public DNS resolver, my network path changed:

Laptop → Cloudflare DNS (1.1.1.1) → Correct Railway Edge → Backend

Cloudflare's resolver:

Respects low TTL values (refreshes DNS records every 60 seconds)
Returns the current, correct edge server location
Uses a globally distributed infrastructure for reliability

My backend had been working the entire time. I simply wasn't reaching it.

The Most Confusing Part

Here's what made this bug so difficult to diagnose:
Local testing worked perfectly:

curl localhost:8080 # ✅ 200 OK

Why? Because localhost doesn't use DNS at all. It goes directly to the loopback interface (127.0.0.1).

This created the worst possible debugging experience:

✅ No error logs
✅ Healthy server metrics
✅ Working local environment
❌ Completely unreachable production URL Everything looked healthy while production appeared completely dead.

How to Recognize a DNS Resolver Issue

You're likely facing a DNS problem if you notice:

✅ Deployed URL times out consistently
✅ localhost works perfectly
✅ Server logs show no errors
✅ Works on mobile data but not Wi-Fi (or vice versa)
✅ Works for colleagues but not you
✅ Suddenly starts working hours later with no code changes
✅ Switching DNS providers fixes it instantly ← smoking gun That last point is the definitive test.

The Permanent Solution

Instead of relying on your ISP, router, or hotspot DNS, use a reliable public resolver:

Primary DNS: 1.1.1.1
Secondary DNS: 1.0.0.1
(Cloudflare DNS)

Or alternatively:
Primary DNS: 8.8.8.8
Secondary DNS: 8.8.4.4
(Google DNS)

After changing your DNS settings:

Flush your DNS cache
Reconnect to your network
Test your deployment

Your deployments should now open immediately and consistently.

Why This Matters for Developers

If you frequently work with:

Serverless backends (Railway, Vercel, Render)
Preview deployment URLs
Custom domain configurations
Edge-deployed applications You're constantly creating fresh DNS records that need to propagate quickly.

Unreliable DNS resolvers will:

Cache incorrect IPs
Ignore low TTL values
Create inconsistent behavior across your team
Make you think your production system is unstable

The result is a dangerous false signal: you believe your application is broken when the problem is actually upstream networking.

The Broader Lesson

Modern web development has changed.
Debugging isn't just about code anymore.

Your application stack now spans multiple layers:
Code → Container → Platform → CDN → DNS → Resolver → Network

A failure in any of these layers can manifest as what appears to be an application failure.

This experience taught me one critical debugging rule:

If localhost works but production times out, suspect DNS before rewriting your backend.

Sometimes the server isn't down. You're just asking the wrong person for directions.

Final Thoughts

This "bug" cost me hours of debugging—rechecking ports, SSL certificates, firewall rules, and deployment configurations. The actual problem was completely invisible in my application logs.

The fix took 30 seconds: changing two DNS server addresses.

If you're deploying to modern cloud platforms and experiencing unexplained timeouts while your logs look perfect, check your DNS resolver first. It might save you from questioning your entire deployment strategy.

And if you're using a mobile hotspot for development?

Switch to `1.1.1.1` now. Your future self will thank you.

Have you encountered mysterious timeouts that turned out to be DNS issues? I'd love to hear your war stories in the comments.

Forem: Yasir Ansari

Building a React Native + Web3 Project - Looking for Developers in the Same Space

Looking to Connect

Join

Minologue: Why I Started Building This Boring AI Application

[Boost]

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

Yasir Ansari ・ Feb 16

Railway app: running Logs: clean localhost: works Website: dead https://dev.to/yasir_etc/railway-url-timeouts-why-a-healthy-server-can-still-be-unreachable-5cc3

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

Yasir Ansari ・ Feb 16

The server is alive… but you’re talking to the wrong place.

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

Yasir Ansari ・ Feb 16

Railway URL Timeouts: Why a Healthy Server Can Still Be Unreachable

The Situation

The Wild Goose Chase

Understanding DNS: The Internet's Phone Book

Why Modern Platforms Are Different

The Hidden Problem: My Mobile Hotspot's DNS

Why Cloudflare DNS (1.1.1.1) Fixed It

The Most Confusing Part

How to Recognize a DNS Resolver Issue

The Permanent Solution

Why This Matters for Developers

The Broader Lesson

Final Thoughts

Switch to 1.1.1.1 now. Your future self will thank you.

Switch to `1.1.1.1` now. Your future self will thank you.