DEV Community: Tarunya Kesharwani

The Security Problems Hiding Inside ‘Normal’ Frontend Code

Tarunya Kesharwani — Sun, 02 Aug 2026 06:20:34 +0000

For a long time, my understanding of frontend security was basically:

Don't expose API keys.

Don't do something stupid with passwords.

Use HTTPS.

Done :))

Turns out...

absolutely not XD

While working on production code, I started noticing something uncomfortable.

A lot of security vulnerabilities don't look like security vulnerabilities.

They look like completely normal code.

A line displaying HTML.

A hidden admin button.

A form validator.

A token stored in the browser.

An environment variable.

An API request.

Nothing is flashing red.

VS Code isn't screaming.

The application works perfectly.

And that's exactly what makes some of these problems dangerous ._.

So this isn't going to be another:

"Here are 10 OWASP vulnerabilities you should memorize."

I want to show you something more useful:

how security changes the way you read ordinary frontend code.

And more importantly, for every problem we'll answer three questions:

Why is this actually dangerous?
What should we do instead?
What should you learn so you can recognize it yourself?

Because telling someone:

"YOUR APPLICATION IS VULNERABLE!!!"

and then disappearing is not particularly helpful XD

Let's break some things.

Preferably theoretically.

1. The Browser Is Not Your Trusted Environment

This is probably the most important rule in this entire article.

If code reaches someone's browser...

they control that environment.

They can open DevTools.

Modify JavaScript.

Change HTML.

Modify requests.

Call your API directly.

Change values in browser storage.

Disable your frontend validation.

Send requests your UI never allows.

Your beautiful Angular interface is not a security boundary :')

This sounds obvious after someone says it.

But it has consequences everywhere.

Consider:

if (user.role === 'admin') {
  showAdminPanel();
}

Perfectly reasonable frontend code.

But if your backend assumes:

"Well... only admins can see the button."

we have a problem.

An attacker doesn't need your button.

They need your endpoint.

If this exists:

DELETE /api/admin/repositories/123

they can attempt to call it directly.

Your carefully hidden button is sitting there feeling extremely secure while the attacker completely ignores it XD

So what should you do?

Use frontend authorization for user experience.

Use backend authorization for security.

The frontend can decide:

Should I display this action?

The backend must independently decide:

Is this authenticated user actually allowed to perform this action?

Every sensitive endpoint should verify authorization server-side.

Learn next

Study:

Authentication vs authorization
Role-Based Access Control (RBAC)
Permission-based authorization
HTTP status codes 401 vs 403
Server-side authorization guards/middleware

If you're using NestJS, specifically learn Guards and authorization patterns.

2. Disabled Buttons Are Also Not Security XD

Suppose we have:

<button disabled>
  Delete Everything
</button>

Attacker:

oh no :(

Anyway...

Open DevTools.

Remove disabled.

Or skip the interface completely.

Send the HTTP request manually.

The same applies to logic like:

if (!isAdmin) {
  return;
}

Again:

Good UX.

Not sufficient security.

The browser belongs to the user.

Anything enforced exclusively there can potentially be modified or bypassed.

The rule

Whenever you write a frontend restriction, ask:

"What happens if someone completely ignores this frontend?"

If the answer is:

"They can delete the database."

we may have discovered a slight architectural issue :')

3. “But The Data Came From Our API!”

This one changed how I think about data.

Imagine:

this.http.get('/api/profile').subscribe(profile => {
  this.bio = profile.bio;
});

Then somewhere:

<div [innerHTML]="bio"></div>

At first glance:

The backend sent it.

Therefore it's trusted.

Right?

Not necessarily.

Where did the backend get bio?

Maybe:

User
  ↓
Database
  ↓
API
  ↓
Frontend
  ↓
HTML

The data took a lovely vacation through your entire technology stack...

but nobody actually made it trustworthy XD

The database storing malicious input doesn't sanitize it.

JSON serialization doesn't sanitize it.

HTTPS doesn't sanitize it.

Your API returning it doesn't sanitize it.

This leads to a security concept worth remembering:

Trust the provenance, not the transport.

Ask:

Where did this data originally come from?

Not:

"Which API returned it?"

If users, third-party APIs, URL parameters, imported files, GitHub data, CMS content, or another untrusted source can influence the value, treat it accordingly.

4. XSS Is Much More Interesting Than `alert("hacked")`

Most beginner explanations of Cross-Site Scripting show:

<script>alert("hacked")</script>

And honestly...

that makes XSS look almost adorable XD

Nobody cares if an attacker can display a popup saying "hacked."

The real problem is that malicious JavaScript may execute inside your application's origin and user context.

Depending on the application and its defenses, that can potentially allow an attacker to:

Read data accessible to JavaScript
Manipulate the interface
Make authenticated actions as the victim
Read browser storage accessible to JavaScript
Exfiltrate accessible information
Display phishing interfaces inside your legitimate application

Imagine logging into a trusted website...

and the website itself shows you a fake:

Session expired. Please enter your password again.

Except that UI was injected by an attacker.

Suddenly alert("hacked") doesn't seem like a particularly useful demonstration :')

5. Learn to Think in Sources and Sinks

Here's a security concept I wish frontend tutorials introduced much earlier.

Source

Where potentially untrusted data enters.

Examples:

URL parameters
Form inputs
Third-party APIs
Database content originally supplied by users
GitHub/API responses
localStorage
postMessage
CMS content

Sink

Somewhere that data becomes dangerous depending on how it's used.

For example:

<div [innerHTML]="content"></div>

The important question becomes:

SOURCE
   ↓
transformations
   ↓
more transformations
   ↓
SINK

Can an attacker control the source?

If yes:

What happens when their input reaches the sink?

That way of thinking is far more useful than memorizing a list of dangerous functions.

6. Your Framework Is Probably Protecting You More Than You Realize

Modern frameworks provide useful security defaults.

For example, Angular escapes/interprets interpolated values safely in normal templates.

Something like:

<p>{{ username }}</p>

is fundamentally different from deliberately injecting arbitrary HTML.

Frameworks are trying to help.

Then sometimes developers do this:

bypassSecurityTrustHtml(content)

Angular:

I don't trust this HTML.

Developer:

Don't worry bro.

Angular:

...okay ._.

The name bypassSecurityTrustHtml is practically Angular asking you to sign a waiver.

There are legitimate situations where trusted HTML needs special handling.

But bypassing framework security means you have accepted responsibility for establishing that the value is actually safe.

Prevention

Prefer normal framework rendering whenever possible.

If you genuinely need user-controlled rich HTML, use a well-maintained sanitizer designed for that purpose and configure it for your threat model rather than trying to remove suspicious strings yourself.

Do NOT invent:

html.replace('<script>', '')

and declare victory XD

Attack payloads have considerably more creativity than that.

Learn next

Study:

Cross-Site Scripting (XSS)
DOM-based XSS
Output encoding
HTML sanitization
Angular security model / React escaping behavior
OWASP XSS Prevention Cheat Sheet
DOMPurify or an equivalent maintained sanitizer when arbitrary HTML must be rendered

7. Frontend Validation Is Not Security Validation

You build a beautiful Angular form:

name: new FormControl('', [
  Validators.required,
  Validators.maxLength(100)
])

Fantastic.

Users cannot submit names longer than 100 characters.

Except...

attackers are under no contractual obligation to use your Angular form XD

They can directly send:

POST /api/users

with whatever payload they want.

Frontend validation is still important.

It gives immediate feedback.

Reduces accidental invalid requests.

Makes forms pleasant to use.

But:

Client validation improves user experience. Server validation establishes trust.

Your backend must validate the request again.

Types.

Lengths.

Formats.

Allowed values.

Required properties.

Unexpected properties where relevant.

Business constraints.

And validation should happen before untrusted data reaches sensitive operations.

Learn next

Study:

DTO validation
Schema validation
Input validation
Allowlisting vs blocklisting
NestJS ValidationPipe
class-validator
OWASP Input Validation Cheat Sheet

8. Let's Talk About `localStorage`

Ah yes.

The internet's favourite security debate :')

You'll often hear:

NEVER STORE TOKENS IN LOCALSTORAGE!!!!

And then:

COOKIES ARE SECURE!!!!

Security is rarely that simple.

localStorage is accessible to JavaScript running on the same origin.

Therefore, if malicious JavaScript successfully executes through an XSS vulnerability, values accessible through localStorage may also become accessible to that script.

An HttpOnly cookie, by contrast, cannot be directly read through JavaScript.

That's useful protection against token theft through JavaScript.

But cookies introduce considerations of their own.

For authentication cookies, you need to understand things such as:

HttpOnly
Secure
SameSite
CSRF
Cookie scope
Session expiration
Session invalidation

The lesson isn't:

localStorage bad.

cookies good.

The lesson is:

Understand what you're protecting against.

That's threat modeling.

Questions worth asking

If authentication credentials are stored here:

Can JavaScript access them?
What happens during an XSS attack?
Can another origin cause authenticated requests?
How does logout invalidate the session?
What happens when credentials expire?
Can compromised credentials be revoked?

Those questions lead to better architecture than memorizing Twitter security advice XD

Learn next

Study:

Cookie-based authentication
Session authentication
HttpOnly, Secure, and SameSite
CSRF
XSS
Token rotation
Session invalidation
OWASP Session Management Cheat Sheet

9. Your `.env` File Does Not Make Frontend Secrets Secret

This one hurts because .env feels extremely secure.

Look at it.

It even has a dot at the beginning.

Very mysterious :0

Suppose:

SUPER_SECRET_API_KEY=abc123

Then your frontend build includes that value.

Congratulations.

Your secret is now...

public :')

If the browser needs a value to execute your application, assume the user can obtain that value.

Minification doesn't change that.

Obfuscation doesn't create a security boundary.

Renaming:

SECRET_API_KEY

to:

x7Q_a19

does not defeat someone determined to inspect your application XD

Important distinction

Not every API key is necessarily secret.

Some services intentionally provide publishable client keys designed to exist in browser applications.

The important question is:

What authority does possession of this value provide?

If the key grants privileged server-side access, signs trusted requests, bypasses authorization, or gives access to private infrastructure...

it does not belong in frontend code.

Prevention

Keep actual secrets server-side.

Frontend:

Browser
   ↓
Your Backend
   ↓
Privileged External Service

The backend keeps the secret and performs authorization before accessing privileged services.

Learn next

Study:

Public vs secret API keys
Environment variables in frontend build systems
Backend-for-Frontend patterns
Secret management
API key restrictions
Least privilege

And remember:

Anything shipped to the browser should be treated as observable by the user.

10. Rate Limiting Is Not Disabling a Button for Five Seconds

Suppose your frontend does:

if (requestInProgress) {
  return;
}

Useful.

But that's UI throttling.

Not security rate limiting.

Again...

the attacker doesn't need your UI :')

They can directly automate requests against the endpoint.

This matters particularly for operations like:

Login attempts
Password resets
Expensive searches
Email sending
File processing
Administrative actions
Expensive third-party API calls

Without rate limiting, one endpoint can potentially become a resource exhaustion or abuse mechanism.

And authentication alone doesn't magically solve this.

Authenticated accounts can be:

Compromised
Automated
Buggy
Malicious

Prevention

Rate limiting belongs at a trusted server or infrastructure boundary.

Depending on the architecture, that could mean:

Application middleware/guards
API gateway
Reverse proxy
CDN/WAF
Distributed rate limiter

For distributed systems, you also need to think about whether counters are shared across instances.

Learn next

Study:

Rate limiting
Token bucket
Sliding-window algorithms
HTTP 429 Too Many Requests
NestJS throttling
Reverse proxies
Distributed rate limiting

11. Third-Party JavaScript Is Part of Your Security Boundary

Analytics.

Chat widgets.

A/B testing.

Payment SDKs.

Random npm packages.

Convenient scripts copied from somewhere at 2 AM because Stack Overflow said it works XD

Every script executing in your page deserves scrutiny.

If third-party JavaScript executes with access to your application's origin, you're trusting more than your own code.

That doesn't mean:

NEVER USE THIRD-PARTY JAVASCRIPT.

It means:

Know who you're trusting.

This is also why dependency security matters.

Your application can contain perfectly secure code...

and still inherit vulnerabilities through its software supply chain.

Prevention

Minimize unnecessary dependencies.
Keep dependencies updated deliberately.
Review high-risk dependencies.
Avoid casually loading remote scripts.
Use integrity/security mechanisms where appropriate.
Monitor dependency advisories.
Remove abandoned packages when feasible.

Learn next

Study:

Software supply-chain security
Dependency auditing
npm audit and its limitations
Subresource Integrity (SRI)
Content Security Policy
Lockfiles
OWASP Software Supply Chain guidance

12. Content Security Policy: Assume Something Eventually Goes Wrong

Imagine you've done everything correctly.

Then six months later someone introduces an XSS vulnerability.

Defense-in-depth asks:

Can we make exploitation harder even after the first defense fails?

That's where browser security mechanisms such as Content Security Policy (CSP) become interesting.

A well-designed CSP can restrict which scripts, styles, frames, and other resources the browser is allowed to execute or load.

It isn't:

CSP = true

A weak policy can provide little protection.

A badly configured policy can break your application.

And CSP should not replace proper output handling or sanitization.

It's another layer.

Other important browser-side defenses include appropriate security headers and policies around framing, MIME handling, referrers, permissions, and transport.

Learn next

Study:

Content Security Policy
CSP nonces and hashes
Security headers
Clickjacking
frame-ancestors
HSTS
Referrer Policy
Permissions Policy

MDN and OWASP are excellent places to learn these properly.

So... How Do I Actually Think About Frontend Security?

After discovering all of this, it can become tempting to look at every line like:

IS THIS A VULNERABILITY??? :0

That's not particularly productive either XD

Instead, I've started using a simpler mental model.

Follow the data.

Whenever important data enters the system, ask:

1. Where did it originate?

User?

URL?

Database?

GitHub?

Third-party API?

Browser storage?

CMS?

2. Who controls it?

Us?

An administrator?

Any authenticated user?

Anyone on the internet?

Another service?

3. Where do we start trusting it?

Did the backend validate it?

Did we verify authorization?

Was HTML sanitized?

Are we merely assuming it's trustworthy because it came from our own API?

4. Where does it go?

HTML?

Database?

URL?

DOM?

Logs?

External API?

Another user?

5. What happens if an attacker controls it?

This is the fun question :')

Could they:

Execute JavaScript?
Modify another user's data?
Perform an admin operation?
Leak credentials?
Exhaust resources?
Inject misleading content?
Access something outside their permissions?

6. Where is the actual security boundary?

If your answer is:

"The button is hidden."

we need to talk XD

My Frontend Security Checklist

When reviewing frontend-heavy applications now, these are some of the questions I'd ask.

Authentication & Authorization

Are sensitive operations authorized on the backend?
Are sessions invalidated correctly?
Are credentials stored according to an explicit threat model?
Are admin endpoints independently protected?

Input & Output

Is untrusted input validated server-side?
Is dynamic HTML actually necessary?
Are framework security protections being bypassed?
Is dangerous output encoded or sanitized appropriately?

Browser

Are authentication cookies configured correctly?
Is there a sensible CSP?
Are sensitive values unnecessarily exposed to JavaScript?
Can the application be embedded where it shouldn't be?

API

Are expensive/sensitive endpoints rate-limited?
Does the backend assume the frontend already validated something?
Can users modify IDs or parameters to access resources belonging to someone else?
Are authorization checks performed against the requested resource?

Secrets

Does any real secret reach the frontend bundle?
Are external service credentials scoped to minimum required privileges?
Can exposed client keys be restricted by origin, API, quota, or permissions?

Dependencies

Do we actually need every dependency?
Are critical packages maintained?
Are third-party scripts necessary?
Are security advisories being monitored?

You don't need to memorize every vulnerability ever discovered.

You need to develop the habit of asking:

What assumption am I making about trust here?

What Should a Beginner Actually Study?

If you're reading this thinking:

Cool.

Everything is dangerous now.

Thanks :')

Don't randomly consume cybersecurity content for six months.

Start with web security fundamentals.

I'd learn roughly in this order:

1. HTTP fundamentals

Understand:

Requests and responses
Headers
Cookies
Origins
CORS
HTTPS

2. Authentication & authorization

Understand:

Sessions
Cookies
Tokens
RBAC
Server-side authorization

3. XSS

Learn:

Stored XSS
Reflected XSS
DOM-based XSS
Sources and sinks
Encoding vs sanitization

4. CSRF

Especially if you're using cookie-based authentication.

5. Input validation

Understand why both frontend and backend validation exist.

6. Browser security

Learn:

Same-Origin Policy
CORS
CSP
Secure cookies
Browser storage

7. API security

Learn:

Authorization
Rate limiting
Object-level access control
Validation
Abuse prevention

8. OWASP

Don't just memorize the OWASP Top 10.

Use it as a map of categories you should understand.

Two resources I'd keep returning to are:

OWASP Cheat Sheet Series

https://cheatsheetseries.owasp.org/

and:

MDN Web Security

https://developer.mozilla.org/en-US/docs/Web/Security

For practical exercises, PortSwigger's Web Security Academy is also extremely useful:

https://portswigger.net/web-security

Read something.

Break something in a legal training environment.

Understand why it broke.

Fix it.

That's much more effective than memorizing vulnerability names.

The Biggest Thing That Changed for Me

A while ago, when reviewing frontend code, I'd mostly ask:

Does this work?

Then:

Is this clean?

Is this maintainable?

Is this performant?

I'm slowly learning that there's another question that needs to exist alongside all of them:

What happens if somebody intentionally uses this in a way we didn't expect?

That's security thinking.

A form isn't only something a user fills out.

It's an input boundary.

An API response isn't automatically trusted data.

A hidden button isn't authorization.

A disabled button isn't protection.

An environment variable isn't automatically a secret.

A framework security escape hatch isn't something to casually bypass.

A successful request doesn't mean the request should have been allowed.

And a feature working exactly as intended doesn't mean it's safe.

That's probably the uncomfortable part of learning security.

Your code can be:

✓ Working

✓ Clean

✓ Tested

✓ Fast

✓ Beautiful

and still be:

✗ Please don't deploy this XD

Final Thought

I don't think becoming better at application security means memorizing every attack payload.

And I definitely don't think every frontend developer needs to become a penetration tester.

But if you're building applications that handle real users, real accounts, real data, or real permissions...

you need to understand trust.

Where it begins.

Where it ends.

And where you're accidentally creating it.

Because many security vulnerabilities aren't created by developers writing obviously dangerous code.

They're created by completely reasonable assumptions:

"The frontend already checked it."

"Only admins can see this button."

"It came from our API."

"It's inside .env."

"The framework handles security."

"The user can't send that value."

Individually, each sentence sounds harmless.

Until someone asks:

"...but what if that's not true?"

._.

That's the question I'm trying to get better at asking.

I'm still learning security.

Still finding assumptions in my own code.

Still reading documentation.

Still discovering browser behavior that makes me go:

"WAIT... it can do WHAT?!" :0

And probably still going to write something someday that a security engineer looks at and quietly closes their laptop XD

But now, when I read frontend code, I don't only see components, requests, forms, and state.

I see trust boundaries.

And once you start seeing those...

normal frontend code starts looking very different :))

Webhooks Aren't Enough: How We Designed Reliable GitHub Data Synchronization

Tarunya Kesharwani — Fri, 17 Jul 2026 08:29:00 +0000

When we started thinking about keeping repository data updated in WebiU, the first solution seemed pretty obvious:

GitHub has webhooks.

Repository changes.

GitHub sends an event.

We update our database.

Done :))

Simple.

Clean.

Real-time.

What could possibly go wrong?

Well...

Apparently, quite a lot XD

Because somewhere between:

"Let's add GitHub webhooks."

and:

"Let's make sure our database actually represents what exists on GitHub."

I learned something important:

Real-time synchronization and reliable synchronization are two completely different problems.

And that realization changed how we designed the entire synchronization system behind WebiU.

The Original Problem: GitHub Was Becoming Our Data Source

WebiU started with a much simpler architecture.

A lot of project information could live inside static files.

That works perfectly well when your data changes occasionally.

But GitHub repositories definitely don't behave like that :')

Repositories are created.

Repositories are renamed.

Descriptions change.

Topics change.

Contributors join.

Repositories get archived.

Metadata evolves constantly.

Once WebiU started moving toward becoming an Open Source Intelligence Platform, keeping that information manually synchronized stopped making sense.

So we needed a system where GitHub remained the source of truth...

while WebiU maintained its own persistent representation of that data.

And that creates a surprisingly interesting problem:

How do you keep two systems synchronized when only one of them is actually authoritative?

The Obvious Solution: Just Use Webhooks

GitHub webhooks are almost perfect for this.

Something changes on GitHub.

GitHub sends an HTTP request to your backend.

Your backend processes the event.

Your database gets updated.

Instead of constantly asking GitHub:

"Anything changed?"

"Anything changed now?"

"How about now?"

"...now?" ._.

GitHub simply tells you when something happens.

This is event-driven architecture in its simplest form.

And compared to repeatedly polling hundreds of repositories, it has some obvious advantages.

Fewer unnecessary API requests.

Lower latency.

Near real-time updates.

Better use of GitHub API rate limits.

Everything looks great.

Until you ask one slightly uncomfortable question:

What happens if we miss an event?

Webhooks Tell You What Happened.

They Don't Prove Your Current State Is Correct.

Imagine GitHub sends a webhook.

Your server is temporarily unavailable.

The request fails.

Or your application receives the webhook but crashes while processing it.

Or the database transaction fails.

Or someone accidentally removes a webhook configuration.

Or a repository existed before your webhook system was even deployed.

Now GitHub knows one thing.

Your database knows another.

And neither system is going to magically fix that difference for you :')

This is called data drift.

Your local representation slowly starts becoming different from the actual source of truth.

And the dangerous part is that your application might continue working perfectly.

No errors.

No crashes.

No giant red warning saying:

HELLO. YOUR DATABASE IS WRONG NOW. XD

It simply serves outdated information.

That's much harder to notice.

Real-Time Does Not Mean Correct

This was probably the biggest mental shift for me while working on synchronization.

Webhooks optimize for freshness.

They tell us about changes quickly.

But freshness and correctness aren't the same thing.

You can have a system receiving updates within milliseconds...

and still have incorrect data because of one event you missed three weeks ago.

That means relying entirely on webhooks creates an architectural assumption:

Every important event will always be delivered and successfully processed.

That's a very strong assumption.

And distributed systems generally have a habit of destroying strong assumptions XD

So instead of asking:

How do we receive updates quickly?

We started asking:

How do we guarantee that our system eventually returns to the correct state?

That question led us to reconciliation.

Enter Scheduled Reconciliation

The idea behind reconciliation is surprisingly simple.

Every once in a while, don't trust your own database.

Go back to the source of truth.

Compare reality with what you think reality looks like.

Then repair the differences.

In our case:

GitHub represents the authoritative repository state.

WebiU maintains a persistent local representation.

So periodically, the system can fetch the actual repository state from GitHub and compare it against what exists locally.

If everything matches?

Great :))

Move on.

If something doesn't?

Now we know drift has occurred.

And the system can recover.

Webhooks + Reconciliation

This is where the architecture started making much more sense to me.

Webhooks and scheduled synchronization aren't competing approaches.

They solve different problems.

Webhooks give us:

Fast updates
Event-driven processing
Fewer unnecessary API requests
Near real-time synchronization

Reconciliation gives us:

Recovery from missed events
Drift detection
Eventual correctness
Protection against historical inconsistencies

Together, they create something much stronger.

The architecture becomes roughly:

GitHub changes

→ Webhook event

→ Backend processes event

→ Database updates immediately

Then, separately:

Scheduled reconciliation

→ Fetch authoritative GitHub state

→ Compare against persisted state

→ Detect differences

→ Repair inconsistencies

The webhook path handles the normal case.

The reconciliation path handles the:

"Something somewhere went wrong three days ago and nobody noticed." XD

case.

And those cases matter more than I originally expected.

Idempotency Suddenly Matters

Once you have multiple synchronization paths, another problem appears.

The same repository update might arrive through a webhook...

and later be discovered again during reconciliation.

Should the system update everything twice?

Create duplicate records?

Trigger duplicate downstream work?

Hopefully not :')

This is where idempotency becomes important.

An operation should be safe to perform multiple times without creating incorrect results.

For example:

Synchronize repository X with GitHub.

Whether that operation runs once or five times, the final state should still represent GitHub correctly.

This sounds obvious when written in one sentence.

Designing your code so that it actually behaves this way is slightly less obvious XD

But once synchronization systems become asynchronous, retryable, and event-driven, idempotency stops being a nice architectural word.

It becomes a survival mechanism.

Failures Should Become State

Another interesting lesson came from thinking about failed synchronization.

The naive approach is:

Synchronization fails.

Log the error.

Done.

But logs are mostly useful to developers who already know something is wrong.

What about the system itself?

If a repository failed synchronization yesterday, shouldn't the application know that?

Instead of treating synchronization failures as temporary console messages, we started representing synchronization state explicitly.

A repository can have information about whether it is synchronized correctly.

Whether synchronization failed.

Why it failed.

Where the latest reconciliation came from.

This turns operational problems into queryable application state.

And that opens the door to much better observability.

Instead of searching through logs wondering:

"Which repository is broken?" ._.

The system itself can answer that question.

The Database Became More Than Storage

This was another shift in how I thought about persistence.

Initially, it's easy to think:

Database = place where data lives.

But in a synchronization-heavy system, the database also becomes a record of what the application believes about the outside world.

That means metadata becomes important.

When was this repository last synchronized?

Was the synchronization successful?

Where did this update come from?

Is this repository still active?

Did reconciliation detect drift?

Suddenly, your persistence model isn't just representing repositories.

It's representing the health of your relationship with the external system.

I definitely wasn't thinking about databases like that when I first started building CRUD applications xD

GitHub API Rate Limits Still Matter

Of course, reconciliation introduces its own problem.

Remember why we didn't want to poll GitHub constantly in the first place?

Rate limits.

2err -> 20err !!!" width="447" height="447">

If you have hundreds of repositories and periodically fetch everything from GitHub without thinking about efficiency...

Congratulations.

You've reinvented aggressive polling with extra steps XD

So reconciliation needs to be intentional.

Not every piece of data needs the same synchronization frequency.

Not every repository needs to be refreshed constantly.

Bulk operations can reduce unnecessary requests.

Cached data can prevent repeated work.

The system needs to understand which information is actually worth refreshing.

This is where architecture becomes less about:

"Can we build this?"

and more about:

"Can we build this without creating another problem somewhere else?"

That question keeps appearing suspiciously often in software engineering :')

Synchronization Is a Consistency Problem

Before working on this system, I mostly thought about GitHub integration as an API problem.

Call endpoint.

Get JSON.

Save JSON.

Done.

But once you're maintaining persistent state, it becomes something else entirely.

It's a consistency problem.

You have:

An external source of truth
Your local representation
Events arriving asynchronously
Operations that can fail
Network requests that can time out
Rate limits
Retries
Historical data
Multiple synchronization mechanisms

Now you're not simply consuming an API.

You're designing how two systems agree with each other over time.

That is a much more interesting problem.

And also a much better way to accidentally spend an entire evening staring at architecture diagrams :')

The Architecture We Ended Up With

At a high level, the synchronization strategy became:

1. PostgreSQL for persistent repository state

WebiU keeps a local representation of repository information rather than fetching everything directly from GitHub for every request.

2. GitHub webhooks for fast updates

When important events occur, GitHub can notify the backend and allow the system to react quickly.

3. Scheduled reconciliation for correctness

The system periodically compares persisted state against GitHub to detect and repair drift.

4. Synchronization metadata for observability

Repositories can expose their synchronization status instead of hiding failures inside logs.

5. Idempotent synchronization operations

Updates should remain safe even when the same state is processed multiple times.

Together, these mechanisms create something much more resilient than:

GitHub webhook → database update.

Because production systems need to account for what happens when the happy path isn't so happy XD

What I'd Do Differently Now

One thing I'm slowly learning is that the first architecture you imagine is usually optimized for the happy path.

The more you work on production systems, the more you start designing for everything surrounding that path.

What happens when this fails?

Can it retry?

What happens if the retry runs twice?

How do we detect stale data?

Can the system repair itself?

How do we know it's broken?

What happens when the external API disappears for ten minutes?

Those aren't questions I naturally asked when I was building my first React applications.

Back then, my biggest architectural concern was probably:

"Should this component go inside the components folder or the pages folder?" XD

Now I find myself thinking about synchronization, consistency, persistence, failure recovery, and observability.

And I'm still very much learning all of it.

But that's probably been one of the most interesting parts of working on WebiU through Google Summer of Code.

The problems keep getting deeper.

And every time I think:

"Okay, I understand this architecture now."

another edge case quietly walks into the room :')

The Biggest Lesson

If there's one thing I'd take away from building this system, it's this:

Don't design only for how data gets updated. Design for how your system recovers when it doesn't.

Webhooks are excellent.

We use them because they solve an important problem.

But they aren't a complete synchronization strategy.

Reliable systems need a way to question their own state.

To compare it against reality.

To detect when something went wrong.

And ideally...

to fix themselves without waiting for a developer to discover three weeks later that something has been broken the entire time XD

I'm still learning.

Still designing.

Still finding edge cases I didn't know existed.

Still occasionally looking at a simple feature and realizing it has somehow become a distributed systems problem :')

But I think that's the part of software engineering I'm starting to enjoy the most.

The code is one part.

Understanding how the entire system behaves when things go wrong?

That's where things start getting really interesting :))

When a Static Website Isn’t Enough: Building an Open Source Intelligence Platform

Tarunya Kesharwani — Thu, 09 Jul 2026 09:15:26 +0000

The Architecture Decisions That Turned a Static Website into an Open Source Intelligence Platform

Open source organizations grow in a very... interesting way :)

It usually starts simple.

A homepage.

A few project cards.

Contributor information.

Maybe a page for programs like Google Summer of Code.

Everything feels clean.

Predictable.

Manageable.

You look at it and think,

"Yeah... this is easy. We got this XD"

And honestly?

At the beginning, it is easy.

Until one day...

it just isn't anymore :')

As repositories grow, contributors increase, and GitHub activity keeps changing every single day, something slowly starts breaking.

Not the code.

The process.

That was exactly the situation we walked into while working on WebiU 2.0.

At first, I thought we were redesigning a website.

Turns out...

we were redesigning how the entire system thinks ._.

The Problem with Static Data

Static websites are amazing.

They're fast.

Easy to deploy.

Simple to reason about.

Honestly, I used to love them because everything felt under control :)

But open source organizations?

They are not static.

Repositories evolve constantly.

Contributors join... and sometimes disappear.

Stars go up.

Forks change.

Issues open.

Pull requests get merged.

New projects suddenly appear out of nowhere.

And then you realize something slightly terrifying:

Every single one of those changes needs to be reflected on the website.

Manually.

At first, it's manageable.

Then it becomes annoying.

Then it becomes... impossible XD

Not because people don't care.

But because the system itself doesn't scale with reality.

And slowly...

the website stops reflecting what's actually happening.

Which is probably the worst thing an open source platform can do :0

The Real Problem Wasn't the Frontend

Naturally, my first instinct was:

"Okay, let's improve the UI."

Better layouts.

Cleaner components.

Filters.

Search.

Animations maybe? xD

But something felt off.

No matter how much we improved the frontend...

the core problem didn't go away.

That's when it hit me:

This wasn't a frontend problem at all.

It was a data problem.

And once you start asking data questions...

things get serious real fast XD

Where does the data come from?
How often is it updated?
How do we know it's correct?
What happens if GitHub is slow?
What happens if we hit API rate limits?
How do we keep things fast and accurate?

At that point, you're no longer thinking like a frontend developer.

You're thinking like someone designing a system.

And honestly...

that shift was both exciting and slightly scary :')

Treating GitHub as a Data Source Instead of a CMS

Originally, GitHub was basically our source of truth.

But the website still relied heavily on static data.

Which works...

until it doesn't.

When you're dealing with a few repositories, it's fine.

When you're dealing with dozens...

or eventually hundreds...

things start getting messy real quick XD

So we changed how we thought about GitHub.

Instead of treating it like a place where people browse code...

we started treating it like a live data source.

And suddenly, everything looked different.

Repository metadata.

Contributor information.

Languages.

Topics.

Commit activity.

Releases.

Project health.

All of this wasn't just "information" anymore.

It became data we could build on.

But here's the catch...

Once you think like this, your problem changes.

You're no longer asking:

"How do we display this?"

You're asking:

"How do we collect, organize, and keep this data reliable?"

And yeah...

that's where things start getting interesting XD

Why Scalability Changes Everything

Scaling sounds like a big word.

But in reality, it just means:

"Things are getting out of hand... in a good way" :)

A few repositories?

Easy.

Hundreds?

Not so easy.

At first, the obvious solution was:

"Just fetch everything from GitHub whenever we need it."

Simple, right?

Yeah...

until you remember GitHub has API rate limits :')

And suddenly:

Requests become slower
Pages take longer to load
You depend entirely on an external service
Performance becomes unpredictable

Not exactly ideal XD

That's when we realized something important:

The website shouldn't be discovering data every time.

It should be serving data.

That one realization changed everything.

Moving Toward a Persistence Layer

This was probably one of the biggest "wait... what?" moments for me :0

Instead of fetching everything live...

we store it.

Yeah.

A database.

Sounds obvious now.

But at that moment, it felt like we were crossing into a completely different level of engineering XD

Once we introduced persistent storage, things started unlocking:

Historical analytics
Better search
Relationships between contributors and repositories
Admin tools
Custom metadata
Caching
Background jobs

And suddenly I was like...

"Wait... weren't we just building a website?" :')

This is where I really started understanding something important:

GitHub doesn't have to be your runtime dependency.

It can be one of your data sources.

And that shift?

It changes everything.

Search Is More Than a Search Box

Search sounds simple.

Until you actually try to build it XD

At first, I thought:

"Just search by repository name. Done."

Yeah... no :)

Real search is way more complex.

People want to search by:

Language
Topics
Maintainers
Activity
Contribution opportunities
Project health

And suddenly you're not building a search box.

You're building a data system.

Good search isn't about UI.

It's about how well your data is structured underneath.

And honestly...

this was one of those moments where I realized:

Frontend is just the surface.

The real magic happens underneath :)

Analytics Need Structure

Another thing I underestimated...

analytics don't just "appear" XD

You don't magically get insights.

You have to design for them.

Questions like:

Which repositories are most active?
Which contributors are working across multiple projects?
Which technologies are most common?
How has the organization grown over time?
Which projects need more maintainers?

These sound simple.

But without structured data?

They're painful.

With the right architecture?

They're almost free :)

That realization felt like unlocking a new level in engineering XD

Architecture Is Mostly About Trade-offs

This is something I'm still learning every day.

Every decision feels right...

until it introduces new problems XD

Static files?

Simple.

Databases?

Powerful... but complex.

Live API requests?

Fresh data.

Persistent storage?

Fast... but needs synchronization.

Search?

Useful... but needs indexing.

Caching?

Fast... but cache invalidation is... yeah... let's not talk about that :')

There is no perfect architecture.

Only trade-offs.

And honestly...

engineering feels less like "finding the right answer"

and more like

"choosing which problems you're okay dealing with" XD

Looking Ahead

WebiU is slowly becoming something much bigger than we initially imagined.

It's no longer just a project showcase.

It's evolving into an Open Source Intelligence Platform.

A place where:

Repository data
Contributor insights
Project discovery
Analytics
Admin workflows

all come together.

And the interesting part?

This evolution isn't happening because we're adding more pages.

It's happening because we're improving what's underneath.

The architecture.

The system.

The thinking.

Final Thoughts

When I first started working on this project, I thought I was going to improve a website.

Now...

I feel like I'm learning how to design systems.

And honestly?

I'm still figuring things out.

Still reading docs.

Still asking questions.

Still getting confused sometimes XD

But something has definitely changed.

I no longer look at software as just "pages connected together."

I look at it as systems.

Flows.

Data.

Trade-offs.

And yeah...

that shift has been one of the coolest parts of this journey :)

Still learning.

Still building.

Still breaking things sometimes xD

But slowly...

starting to think like an engineer who understands why things work.

And not just how to build them.

GitHub
https://github.com/TarunyaProgrammer

LinkedIn
https://linkedin.com/in/tarunyakesharwani

Portfolio
https://tarunyaportfolio.vercel.app

Before Writing Code, I Reviewed 104 Pull Requests

Tarunya Kesharwani — Wed, 10 Jun 2026 21:46:35 +0000

Before Writing Code, I Reviewed 104 Pull Requests

My Community Bonding Journey as a GSoC 2026 Contributor for WebiU

Sometimes the most important code you write during GSoC isn't written during GSoC at all.

When people think about Google Summer of Code, they usually imagine coding.

Building features.

Opening pull requests.

Writing thousands of lines of code.

Getting things merged.

I thought the same.

Then my GSoC journey started with something completely different.

Reviewing 104 pull requests.

Not writing them.

Reviewing them.

And honestly...

I didn't expect that experience to completely change how I think about software engineering.

From Contributor to GSoC Contributor

A few months ago, I was just another contributor trying to understand an unfamiliar codebase.

WebiU, the project I now work on under Google Summer of Code 2026, is an open-source platform developed by C2SI to showcase repositories, contributors, projects, research work, publications, and community activity.

Like most contributors, I started small.

A few issues.

A few pull requests.

A few discussions.

Then more discussions.

Then architectural discussions.

Then feature planning.

Then roadmap discussions.

And somehow...

Before I realized it, I had become deeply involved in the project.

By the time proposal season arrived, I wasn't proposing random ideas anymore.

I was proposing solutions to problems I had already experienced firsthand.

Problems like:

GitHub API rate limits
Slow request-time data fetching
Scalability bottlenecks
Missing persistence layers
Future infrastructure concerns
Long-term maintainability

The proposal I eventually submitted focused on transforming WebiU from a request-driven GitHub data platform into an event-driven repository intelligence system.

At that point, it sounded ambitious.

What happened next was even more interesting.

The 104 Pull Request Audit

During Community Bonding, one of the first major tasks wasn't coding.

It was auditing pull requests.

A lot of them.

104 open pull requests.

Damnnn.

That number sounds much smaller until you actually start reviewing them.

Some were active.

Some were outdated.

Some solved issues that no longer existed.

Some duplicated each other.

Some conflicted with the future direction of the project.

And some were genuinely good contributions that had simply been sitting there waiting for attention.

The challenge wasn't technical.

The challenge was human.

Every pull request represented somebody's effort.

Someone had spent hours.

Maybe days.

Maybe weeks.

Trying to contribute.

Closing a pull request suddenly feels very different when you realize there's a real person on the other side of it.

For the first time, I experienced open source from the maintainer's perspective instead of the contributor's.

And that perspective changes everything.

The Funny Side of Open Source

Not every review was serious.

Thankfully.

Because after reading pull request number 63, your brain starts asking difficult questions like:

"Why am I doing this to myself?"

One of my favorite moments was opening a pull request discussion expecting serious implementation reasoning...

...only to find random laughing reactions in the middle of a completely serious technical conversation.

There we were discussing architecture decisions...

And somebody was apparently having the time of their life.

Those little moments remind you that behind every GitHub profile is an actual human being.

Open source communities are built by people.

Not repositories.

What Reviewing 104 Pull Requests Actually Teaches You

Reviewing code teaches lessons that writing code never will.

As contributors, we mostly see our own work.

As reviewers, we see everybody's work.

Different coding styles.

Different problem-solving approaches.

Different levels of experience.

Different interpretations of the same issue.

You start noticing patterns.

You start seeing why maintainers ask for seemingly "small" changes.

You begin understanding how tiny implementation details can become future technical debt.

Most importantly, you start appreciating how difficult maintaining a project actually is.

After reviewing that many pull requests, I became significantly more careful when creating my own.

Because now I understood what reviewers see.

Conversations That Changed The Project

Once the pull request audit was largely complete, Community Bonding shifted into something else.

Conversations.

Lots of conversations.

Google Meets.

Slack threads.

GitHub discussions.

Private architecture reviews.

Roadmap planning sessions.

Shoutout to Mahendra Bhaiya and Utkarsh Bhaiya here.

One thing I genuinely appreciated was how direct and practical every discussion was.

Nobody cared about fancy architecture diagrams.

Nobody cared about buzzwords.

Nobody cared about building something that simply looked impressive.

Everybody cared about one thing:

Building something that would actually work.

And that mindset changed how I viewed my own proposal.

The Proposal Was Just The Beginning

When I originally wrote my proposal, I focused heavily on architecture.

Webhooks.

Event-driven systems.

Background workers.

Caching.

Repository intelligence.

Persistent storage.

Queue-based processing.

All the fun distributed systems stuff.

The proposal aimed to move WebiU away from this:

Frontend
   ↓
Backend
   ↓
GitHub API

And toward this:

GitHub Events
      ↓
Webhook Layer
      ↓
Queue
      ↓
Workers
      ↓
Database
      ↓
Cache
      ↓
Frontend

At the time, it felt like the perfect plan.

Then mentor discussions began.

And oooh boy...

The proposal started getting challenged.

In a good way.

The people helping select the proposal were often the same people questioning parts of it the hardest.

Looking back, many of our meetings felt less like mentor meetings and more like architecture review boards.

And honestly?

That's exactly how it should be.

Nobody cared about protecting the proposal.

Everybody cared about improving the project.

Defining The Real P0 Priorities

One lesson became obvious very quickly.

Successful projects are not built by solving every problem.

They are built by solving the right problems first.

Together, we started identifying the actual P0 priorities.

The things that absolutely had to be done before anything else.

1. Deployment Strategy

Before building features, we needed deployment clarity.

Where does the frontend live?

Where does the backend live?

How do we keep costs low?

How do we keep maintenance manageable?

Turns out deployment decisions affect architecture far more than most people realize.

2. Long-Term Cache Strategy

Caching sounds simple until you have to maintain it.

Then suddenly you're discussing:

Cache invalidation
Data freshness
Expiration policies
GitHub API limits
Future scalability

And you realize there are entire careers built around solving these problems.

3. GitHub API Dependency

One of the biggest architectural concerns was reducing dependency on live GitHub API requests.

Every design discussion eventually came back to the same question:

How do we serve more data while making fewer GitHub requests?

That question influenced nearly every major decision.

4. Commitments To Project Leadership

This was probably one of the most eye-opening discussions.

Mentors don't just build features.

They are accountable for outcomes.

They make commitments.

They manage expectations.

They balance technical decisions against practical constraints.

Understanding that changed how I approached every discussion moving forward.

The Maintainer Access Moment

At some point, I noticed something unusual.

I wasn't only contributing anymore.

I was helping review work.

Helping make decisions.

Helping plan execution.

Helping close pull requests.

Helping shape project direction.

That's a level of trust I don't take lightly.

Because every merge.

Every review.

Every approval.

Every decision.

Eventually affects somebody else.

And that's a responsibility worth taking seriously.

Building The Roadmap

Once priorities became clear, I started planning the implementation roadmap.

One thing reviewing 104 pull requests taught me is this:

Large pull requests are painful.

Painful to review.

Painful to test.

Painful to merge.

Painful to maintain.

So instead of building everything at once, we broke the project down into focused phases.

Infrastructure Cleanup
Authentication Foundation
Deployment Preparation
Backend Improvements
Admin Features
Webhook Foundations
Repository Intelligence Systems

Each PR would have a single responsibility.

Each merge would move the project one step forward.

Simple.

Predictable.

Reviewable.

Maintainable.

Accountability

One message from GSoC's Community Bonding period stuck with me.

Mentors guide.

Contributors execute.

The responsibility ultimately belongs to the contributor.

And honestly, I think that's one of the best lessons GSoC teaches.

So I've been documenting everything.

Meeting notes.

Decisions.

Roadmaps.

Discussions.

Trade-offs.

Reasoning.

Not because anyone asked me to.

Because future contributors deserve context.

And because six months later, nobody remembers why a decision was made unless somebody writes it down.

What Comes Next

The funny thing is...

The coding phase has barely started.

The audits are done.

The architecture discussions are done.

The deployment direction is mostly finalized.

The priorities are clear.

Now comes the difficult part.

Execution.

Over the next few months, the goal is to transform WebiU into something faster, more scalable, easier to maintain, and less dependent on request-time GitHub API calls.

But regardless of what gets built next, one lesson will stay with me.

Open source isn't just about code.

It's about responsibility.

Responsibility toward contributors.

Responsibility toward maintainers.

Responsibility toward the people who trust your decisions.

And somehow...

That lesson started with reviewing 104 pull requests.

A Small Surprise

Over the last few weeks, quite a few people have messaged me asking questions like:

How did you write your proposal?
How detailed was it?
What architecture did you propose?
What actually gets someone selected?

And honestly...

When I was applying, I had the exact same questions.

I remember spending hours searching for accepted proposals, architecture documents, timelines, and implementation plans.

So instead of gatekeeping it, let's do the opposite.

Here's the exact proposal that got me selected for Google Summer of Code 2026.

Read it.

Critique it.

Learn from it.

Improve upon it.

Disagree with it.

That's how engineering gets better.

Proposal

https://drive.google.com/drive/folders/1xY4t65HgWwPl6TlEChYB4cvcGIL7i2eQ?usp=sharing

Just remember:

The proposal got me selected.

The real work started after that.

Let's Connect

If you're interested in:

Google Summer of Code
Open Source
Angular
NestJS
System Design
Distributed Systems
Building in Public

Feel free to reach out.

GitHub

https://github.com/TarunyaProgrammer

https://linkedin.com/in/tarunyakesharwani

Portfolio

https://tarunyaportfolio.vercel.app

DEV.to

Tarunya KesharwaniFollow

GSoC contributor building with Angular, NestJS & TypeScript. Interested in OSS, scalable systems, PR reviews, architecture, and developer tooling.

I'm always happy to discuss open source, review ideas, exchange feedback, or just talk about building things on the internet.

And if you're contributing to WebiU...

There's a decent chance I've already broken the thing you're trying to fix.

Stop Watching 40-Hour Tutorials: Here's How I'd Learn MERN Today

Tarunya Kesharwani — Thu, 04 Jun 2026 16:27:16 +0000

Every few weeks, I see someone asking:

"How do I learn MERN Stack?"

And almost every time, the advice looks something like:

Learn HTML
Learn CSS
Learn JavaScript
Watch a 40-hour React course
Watch a 20-hour Node.js course
Watch a MongoDB course
Build a project

Six months later, many people are still stuck in tutorial hell :')

If I had to learn MERN again from absolute zero, I would do things very differently.

Not because tutorials are bad.

But because most people spend far too much time watching and far too little time building xD

Step 1: Finish JavaScript Basics First

Before touching React, Express, MongoDB, or anything else...

Make sure you understand JavaScript properly.

If JavaScript feels confusing, React will feel even worse ._.

Do not rush this step.

Seriously.

You'll thank yourself later :))

Step 2: Learn Basic Git & GitHub

You do NOT need to become a Git wizard.

Just learn the basics.

Most beginners think they need to master Git before writing code.

You don't.

Learn enough to avoid accidentally deleting your work XD

The advanced stuff can come later.

Step 3: React — Don't Overdo Tutorials

This is where many people lose months T_T

If you want a deep, hands-on understanding of React, then watch the freeCodeCamp course.

But here's the thing:

You do NOT have to finish an 11-hour course before building.

A lot of people spend weeks collecting React tutorials...

and somehow never build a React project :')

That's the trap.

Watch.

Build.

Get stuck.

Repeat.

Step 4: Build React Projects

The goal isn't to make them perfect.

The goal is to get stuck.

Because getting stuck is where the real learning starts.

Nobody remembers the tutorial they watched.

Everybody remembers the bug that ruined their entire Saturday XD

Step 5: Node.js - Don't Spend Weeks Memorizing Modules

This might sound controversial.

But don't spend weeks trying to memorize Node.js APIs.

Nobody remembers every method from:

fs
path
stream
crypto
os

And if someone claims they do...

they're probably lying :))

Most developers check docs constantly.

I still do.

Step 6: Learn Express

This is where backend development starts becoming fun :D

Routes start talking to databases.

APIs start returning actual data.

Frontend and backend finally become friends instead of strangers XD

Step 7: Learn Axios

A surprisingly important skill.

This is usually the moment where people go:

"WAIT... my frontend can actually talk to my backend?!"

And suddenly things start feeling like real software :')

Step 8: Learn Testing

Most tutorials completely skip testing.

Then people join a real project and see hundreds of test files.

Their reaction is usually something like:

"What fresh hell is this?" XD

Learn the basics.

Future you will be grateful.

Step 9: MongoDB — Learn the 20% That Gives 80% Results

Many beginners overcomplicate MongoDB.

Honestly?

Just learn CRUD.

No, seriously.

Just CRUD.

Create.

Read.

Update.

Delete.

That's enough to build a shocking number of projects :))

Don't spend three weeks studying database theory before writing your first query.

Step 10: Build a Full MERN Project

Now combine everything.

React + Express + MongoDB.

At this stage you'll discover what you actually don't know.

And trust me...

that list will be longer than expected XD

Which is completely normal.

Step 11: Join Open Source and Get Scared Like Crazy

Seriously.

This was one of the biggest learning accelerators for me.

Find an organization.

Clone their repository.

Run the project.

Watch it fail.

Read the README.

Miss a step.

Watch it fail again.

See 500 folders.

See 20,000 lines of code.

Question your life choices.

Question your career choices.

Question reality itself.

Then slowly figure things out :')

That's where the real growth starts.

Not in tutorials.

Not in courses.

Not in roadmap videos.

In confusion XD

Lots and lots of confusion.

Click the image to explore some of the issues I've worked on in open source :))

The Biggest Mistake Beginners Make

They keep preparing.

Another course.

Another tutorial.

Another roadmap.

Another "complete guide."

Another YouTube playlist.

Another productivity system.

Another Notion page.

Another bookmark folder.

At some point you have to stop preparing and actually build something ¯(ツ)/¯

You won't feel ready.

Build anyway.

Resources I'd Actually Recommend

Instead of collecting hundreds of bookmarks, I'd focus on a handful of high-quality resources and repeatedly use them while building projects.

Express.js

Express Documentation
- https://expressjs.com/

Axios

Axios Documentation
- https://axios-http.com/docs/intro

MongoDB

MongoDB Documentation
- https://www.mongodb.com/docs/
MongoDB University
- https://learn.mongodb.com/

Testing

Final Advice

If I could give only one piece of advice:

Stop optimizing your learning roadmap and start building.

Most developers don't have a knowledge problem.

They have an execution problem.

Build projects.

Join open source.

Get stuck.

Figure things out.

That's where the real learning happens.

Let’s Connect

If you're also learning, building, or exploring software engineering beyond tutorials, feel free to connect.

LinkedIn: https://www.linkedin.com/in/tarunyakesharwani/
X/Twitter: https://x.com/TarunyaKesh
GitHub: https://github.com/TarunyaProgrammer

I regularly write about:

Open Source
GSoC
Angular
React
NestJS
TypeScript
Backend Engineering
Software Architecture

Still learning.

Still breaking things.

Still Googling error messages.

Still reading documentation.

Still wondering why the code worked yesterday but not today XD

And still convinced that building beats watching :))

Open Source Changed How I Think About Software Engineering

Tarunya Kesharwani — Thu, 07 May 2026 20:33:49 +0000

A few months ago, I thought software engineering was mostly about building features that worked.

If the app ran, the API responded, and the UI looked decent — I considered the job done.

Then I started contributing to open source.

And honestly, it completely changed the way I look at software development.

Suddenly, I realized how much tutorials usually skip.

Not just coding.

But things like:

understanding someone else’s code,
writing maintainable features,
reviewing pull requests,
handling feedback,
debugging strange edge cases,
and building software with other people.

“Working” Code Isn’t Always Good Code

One of the biggest mindset shifts for me was realizing that real engineering is full of tradeoffs.

Earlier, I used to think:

“If it works, it’s done.”

Now I catch myself thinking:

“Will this still make sense 6 months later?”

Things I barely paid attention to before suddenly started becoming important:

readability
architecture
API design
state management
scalability
maintainability
collaboration
PR review quality

And the more I learned, the more I realized software engineering is much bigger than just writing code.

Open Source Taught Me More Than Tutorials

Reading other people’s code teaches you things tutorials usually can’t.

You start noticing:

why naming matters,
why maintainers reject “working” code,
why folder structures matter,
and why small engineering decisions become important at scale.

Even a small PR review comment can sometimes teach more than an entire tutorial video.

That honestly surprised me.

What I’m Learning Right Now

Currently, I’m exploring:

Angular
React
NestJS
TypeScript
RxJS
Redis
backend systems
system design
OSS workflows

Recently, being selected as a GSoC contributor pushed me even deeper into understanding how collaborative software development actually works in real projects.

And I still feel like I’m only scratching the surface.

What I’ll Write About Here

I want this blog to become a place where I document:

lessons from open source,
frontend/backend engineering,
debugging experiences,
architecture ideas,
developer tooling,
PR review insights,
and mistakes I make while building projects.

Not as an expert.

Just as someone genuinely trying to understand how real software gets built.

Still learning.

Still curious.

Still occasionally overthinking architecture decisions.

Let’s Connect

If you're also learning, building, or exploring software engineering beyond tutorials, feel free to connect.

LinkedIn: TarunyaKesharwani
X/Twitter: TarunyaKesh
GitHub: TarunyaProgrammer

DEV Community: Tarunya Kesharwani

The Security Problems Hiding Inside ‘Normal’ Frontend Code

1. The Browser Is Not Your Trusted Environment

So what should you do?

Learn next

2. Disabled Buttons Are Also Not Security XD

The rule

3. “But The Data Came From Our API!”

Trust the provenance, not the transport.

4. XSS Is Much More Interesting Than alert("hacked")

5. Learn to Think in Sources and Sinks

Source

Sink

6. Your Framework Is Probably Protecting You More Than You Realize

Prevention

Learn next

7. Frontend Validation Is Not Security Validation

Learn next

8. Let's Talk About localStorage

Questions worth asking

Learn next

9. Your .env File Does Not Make Frontend Secrets Secret

Important distinction

Prevention

Learn next

10. Rate Limiting Is Not Disabling a Button for Five Seconds

Prevention

Learn next

11. Third-Party JavaScript Is Part of Your Security Boundary

Prevention

Learn next

12. Content Security Policy: Assume Something Eventually Goes Wrong

Learn next

So... How Do I Actually Think About Frontend Security?

Follow the data.

1. Where did it originate?

2. Who controls it?

3. Where do we start trusting it?

4. Where does it go?

5. What happens if an attacker controls it?

6. Where is the actual security boundary?

My Frontend Security Checklist

Authentication & Authorization

Input & Output

Browser

API

Secrets

Dependencies

What Should a Beginner Actually Study?

1. HTTP fundamentals

2. Authentication & authorization

3. XSS

4. CSRF

5. Input validation

6. Browser security

7. API security

8. OWASP

The Biggest Thing That Changed for Me

Final Thought

Webhooks Aren't Enough: How We Designed Reliable GitHub Data Synchronization

The Original Problem: GitHub Was Becoming Our Data Source

The Obvious Solution: Just Use Webhooks

Webhooks Tell You What Happened.

They Don't Prove Your Current State Is Correct.

Real-Time Does Not Mean Correct

Enter Scheduled Reconciliation

Webhooks + Reconciliation

Idempotency Suddenly Matters

Failures Should Become State

The Database Became More Than Storage

GitHub API Rate Limits Still Matter

Synchronization Is a Consistency Problem

The Architecture We Ended Up With

1. PostgreSQL for persistent repository state

2. GitHub webhooks for fast updates

3. Scheduled reconciliation for correctness

4. Synchronization metadata for observability

5. Idempotent synchronization operations

What I'd Do Differently Now

The Biggest Lesson

4. XSS Is Much More Interesting Than `alert("hacked")`

8. Let's Talk About `localStorage`

9. Your `.env` File Does Not Make Frontend Secrets Secret