david orisabiyi

Fullstack Engineer | system design, perf wins, debugging & AI tools | Nigeria→global | Follow for production hacks I wish I knew |

[david orisabiyi @DevOrisabiyi]

Spent months trying to solve address suggestions for a consumer + business logistics product. Here's the journey.

First try: Google Places. It worked great. Bill came in and we couldn't figure out why it was so high.

So we pivoted: collect addresses manually. For every entry, we showed a popup asking users to fill in structured fields because Nigerian addresses are notoriously inconsistent and we needed clean data. Users hated it. The flow felt heavy.

Next: Mapbox. Tested it for other countries solid, held up against Google. Tested it for Nigeria too, and even wrote custom logic to make it match our address format. In dev, it looked fine. In production with real users? It folded. Nigerian addresses are messy in ways Mapbox just couldn't handle.

So we went back to Google but this time I went deep into the docs to figure out the cost problem.

That's when I found session tokens.

By default, Google bills every autocomplete keystroke individually, plus the final place details call separately. With session tokens, the autocomplete calls and the final selection get grouped into a single billable session. Same UX. Significantly lower bill.

Mehnn, life saver.

Now before someone says "just use debounce" or "call the API once with a trick" debounce alone doesn't change Google's billing model. And calling the API once destroys the autocomplete experience that made users pick Google over manual entry in the first place.

Session tokens are the right answer. The docs just don't surface them well enough.

[coderhema @coderhema]

Thank you @afro_launch

Download Tailored Resumes and Cover letters in less than 2 mins
5 themes available currently

Here's how:

1. Open https://t.co/aUh1F33ALd

2. Login with Google

3. Paste example resume

4. Checkout and Download

Try now: https://t.co/aUh1F33ALd

[coderhema @coderhema]

If you're on my timeline and can see this

I have a cool idea of buying a 1tb SSD or Pendrive setting up ollama and installing a few openweights, so I can use open models anytime I plug into a new system

If you would like to see how I would do this pls comment and react.

[david orisabiyi @DevOrisabiyi]

Here we go

[CommonChronicles @create_eureka]

We’re going live 🟠

Portfolio Night starts now. Creatives and builders presenting their portfolios and getting honest feedback in real time.

This is what @create_eureka looks like in action.

[david orisabiyi @DevOrisabiyi]

@create_eureka Looking forward to this

[david orisabiyi @DevOrisabiyi]

The two most important days in once life is when someone was born and the day one find out why

[CommonChronicles @create_eureka]

Dear Builders,

A new month is here for us to build, learn, share, and keep showing up.

Whether you’re starting something new or continuing what you began, every step adds to the story.

Let’s make something worth remembering. ✨

[david orisabiyi @DevOrisabiyi]

Do you write your auth system by yourself or you allow libraries handle it for you?

[david orisabiyi @DevOrisabiyi]

Auth Series 3:

I write most of my auth myself. The most managed I've gone is NextAuth (now Auth.Js).

BetterAuth, Clerk, Lucia, Auth0 name it. I've read about, evaluated, but ultimately chosen not to use and there is a reason for that.

Most auth libraries fall into one of two camps. Either they're so abstracted that I can't see where the session lives or how tokens flow which makes debugging painful when something breaks, or they're so flexible that I'm essentially writing the auth logic anyway, just with extra steps.

When I write it myself, I know:
• Exactly where the session is stored
• Exactly how tokens are issued, refreshed, and revoked
• Exactly what happens when something fails
• Exactly which security tradeoffs I made and why

This isn't a flex. It's a tradeoff. Writing your own auth means:
• You own the security implications. If you mess up password reset, that's on you.
• You spend a week 1/2 building what a library gives you in a day.
• You re-implement features (passkeys, 2FA, social login) yourself when you need them.

What I've stopped trusting:
• Tutorials that put JWTs in localStorage. Auto-fail.
• "Just roll your own" advice from people who've never shipped auth to prod.
• Libraries that hide the session model from you.

For learning: Lucia's docs at https://t.co/OT4V8IspGZ are now an educational resource, not a library. Read them before you decide to roll your own. They'll either convince you to do it or talk you out of it both useful outcomes.

Next will be, frontend implementation. The stuff that breaks when 2 tabs both try to refresh a token at the same time

[david orisabiyi @DevOrisabiyi]

Auth Series 3:

I write most of my auth myself. The most managed I've gone is NextAuth (now Auth.Js).

BetterAuth, Clerk, Lucia, Auth0 name it. I've read about, evaluated, but ultimately chosen not to use and there is a reason for that.

Most auth libraries fall into one of two camps. Either they're so abstracted that I can't see where the session lives or how tokens flow which makes debugging painful when something breaks, or they're so flexible that I'm essentially writing the auth logic anyway, just with extra steps.

When I write it myself, I know:
• Exactly where the session is stored
• Exactly how tokens are issued, refreshed, and revoked
• Exactly what happens when something fails
• Exactly which security tradeoffs I made and why

This isn't a flex. It's a tradeoff. Writing your own auth means:
• You own the security implications. If you mess up password reset, that's on you.
• You spend a week 1/2 building what a library gives you in a day.
• You re-implement features (passkeys, 2FA, social login) yourself when you need them.

What I've stopped trusting:
• Tutorials that put JWTs in localStorage. Auto-fail.
• "Just roll your own" advice from people who've never shipped auth to prod.
• Libraries that hide the session model from you.

For learning: Lucia's docs at https://t.co/OT4V8IspGZ are now an educational resource, not a library. Read them before you decide to roll your own. They'll either convince you to do it or talk you out of it both useful outcomes.

Next will be, frontend implementation. The stuff that breaks when 2 tabs both try to refresh a token at the same time

[david orisabiyi @DevOrisabiyi]

I will be continuing the auth series today, so stay tuned

[david orisabiyi @DevOrisabiyi]

It's actually been a while since I posted some refreshing content here. We will be picking up the series were we left off

[david orisabiyi @DevOrisabiyi]

It's actually been a while since I posted some refreshing content here. We will be picking up the series were we left off

[david orisabiyi @DevOrisabiyi]

Continuing the auth series.

Today: why I default to session-based auth even though almost every one pushes for stateless JWTs.

The pitch for JWTs:
• Stateless. No DB lookup on every request.
• Scales horizontally because any server can verify the token.
• Self-contained, the token carries the user claims.

The reality after shipping it:

1. You need to log a user out. JWT is stateless, so there's no way to invalidate it. Your options:
a) Wait for it to expire (could be hours)
b) Maintain a blocklist of revoked JWTs (you're now stateful, just badly)
c) Use short-lived access tokens + refresh tokens (now you have a stateful refresh token table anyway)

2. User changes their password from device A. Their session on device B is still valid for hours. With sessions, you UPDATE one row and you're done.

3. You ban a user for fraud. They keep accessing your app until the JWT expires. With sessions, the next request fails immediately.

4. You want to show "active sessions" in user settings. Impossible with pure JWTs. Trivial with a sessions table.

Every production auth system I've worked on ended up stateful. The ones that started stateless rebuilt themselves into stateful systems under pressure, usually after a security incident.

So I skip the rebuild. Stateful from day one.

```
sessions table:
id, user_id, refresh_token_hash,
user_agent, ip_address,
created_at, last_used_at, expires_at, revoked_at
```
One table. Solves every problem above.
Next post Friday, the tools and libraries I actually use, and the ones I've stopped trusting.

[david orisabiyi @DevOrisabiyi]

Most tutorials teach to wire up a login form and store a JWT. That's not authentication that's the easy 10%.

I've built auth systems for logistics product, an e-commerce store, an internal admin dashboard, healthcare dashboard and a few side projects. Each one taught me what the other 90% actually looks like:

• Where do you store the token? localStorage gets XSS'd. Cookies need CSRF protection. Memory loses state on refresh.

• What happens when a token expires mid-request? Refresh token rotation, race conditions when two tabs refresh at once, what to do when refresh itself fails.

• How do you log a user out everywhere? JWTs are stateless by design. Revocation requires a stateful piece you didn't plan for.

• Permissions vs roles vs scopes most apps conflate these and end up with auth logic scattered across 40 files.

• Password reset is more dangerous than login. It's where most security researchers I follow find their first critical bug.

• Social login is a feature you ship for users and a liability you carry forever.

Each is its own decision with its own tradeoffs. Get any of them wrong and you create a security hole, a UX nightmare, or both.

Kicking off a 2-week deep dive on how I actually design auth systems in production backend, frontend, tools, scaling, production pitfalls.

If you've ever shipped auth and felt like you got away with something, this series is for you.

[david orisabiyi @DevOrisabiyi]

@Om7248 Oh nice I know about clipchamp, will check it out

[david orisabiyi @DevOrisabiyi]

@Om7248 @grok what are possible ways to do a demo video without having to do any edit just putting in a text a voice generated and upload my video

[david orisabiyi @DevOrisabiyi]

Most tutorials teach to wire up a login form and store a JWT. That's not authentication that's the easy 10%.

I've built auth systems for logistics product, an e-commerce store, an internal admin dashboard, healthcare dashboard and a few side projects. Each one taught me what the other 90% actually looks like:

• Where do you store the token? localStorage gets XSS'd. Cookies need CSRF protection. Memory loses state on refresh.

• What happens when a token expires mid-request? Refresh token rotation, race conditions when two tabs refresh at once, what to do when refresh itself fails.

• How do you log a user out everywhere? JWTs are stateless by design. Revocation requires a stateful piece you didn't plan for.

• Permissions vs roles vs scopes most apps conflate these and end up with auth logic scattered across 40 files.

• Password reset is more dangerous than login. It's where most security researchers I follow find their first critical bug.

• Social login is a feature you ship for users and a liability you carry forever.

Each is its own decision with its own tradeoffs. Get any of them wrong and you create a security hole, a UX nightmare, or both.

Kicking off a 2-week deep dive on how I actually design auth systems in production backend, frontend, tools, scaling, production pitfalls.

If you've ever shipped auth and felt like you got away with something, this series is for you.

[david orisabiyi @DevOrisabiyi]

Working remotely as a software engineer has me straight up roasting hybrid and on-site corporate gigs!! Like, who wants to drag themselves to the office when the bed setup hits different?! 😤💻 Remote supremacy only!! Drop a 🔥 if you feel me!!

[david orisabiyi @DevOrisabiyi]

Doing excellent work has been the core of software engineering.

[david orisabiyi @DevOrisabiyi]

Working remotely as a software engineer has me straight up roasting hybrid and on-site corporate gigs!! Like, who wants to drag themselves to the office when the bed setup hits different?! 😤💻 Remote supremacy only!! Drop a 🔥 if you feel me!!

[david orisabiyi @DevOrisabiyi]

@Benn_X1 I can very much relate to this