devbeyondbeginner

The Hidden Trap of Array.prototype.fill()

bipin gosain — Sat, 25 Oct 2025 09:27:17 GMT

🚀 TLDR;

If your initialisation involves populating an array with non-primitive types (arrays, objects, sets, etc.), never use fill() as it creates a single instance of the array/object passed to it, and fills values of the array with its reference.

Use Array.from() with a mapping function to guarantee that every element is a unique, independent instance.

For your next interview problem or complex project, remember this rule—it might save you hours of painful debugging! Happy coding!

When solving the Top K frequent problem using the bucket approach, I needed an array of N+1 unique slots, where N is the maximum possible frequency (nums.length). Each slot must be an independent array.

My initial line of code looked like this:

JavaScript

const maxFrequency = nums.length;
const buckets = new Array(maxFrequency + 1).fill([]);

🧐 What Actually Happens: Shared References

The core issue is that fill() only accepts a single value as an argument. When that value is a non-primitive type (like an array or an object), JavaScript does the following:

It creates one single empty array in memory: [].
It then puts a reference to this single, same array into every single index of the buckets array.

The Crux: When my frequency map told me to place a number with frequency 3 into buckets[3], I wrote:

JavaScript

buckets[3].push(num); // I thought I was only affecting bucket 3...

But because buckets[3], buckets[0], buckets[1], and all the others were all pointing to the exact same array object in memory, every bucket got the number! My entire bucket structure was completely corrupted. This is why my "Top K" solution was not working correctly for all test cases.

✅ The Solution: `Array.from({ length }, () => [])`

The correct way to initialize an array where every element needs to be a unique instance of an object (like a unique bucket array) is to use the Array.from() method with a mapping function.

JavaScript

const maxFrequency = nums.length;
const buckets = Array.from({ length: maxFrequency + 1 }, () => []);

💡 Why This Works: The Map Function Creates Unique Instances

Array.from() is designed to create a new array from an iterable or array-like object (like { length: N }). Critically, the second argument is a map function that is executed for every index.

The map function here is () => []. For each of the N+1 positions:

Array.from() executes () => [].
The function returns a brand new, unique empty array instance.

Method	Creates	Resulting References	Impact on Buckets
`fill([])`	One `[]`	All elements point to the same array.	Modifying one bucket affects all buckets.
`Array.from(..., () => [])`	N `[]` instances	Each element points to a unique array.	Modifying one bucket affects only that one bucket.

Switching to Array.from() instantly fixed the issue. My buckets were properly isolated, my logic worked, and I finally got that sweet "Accepted" status.

Introduction to AWS CDK: When to Use It Over Terraform

bipin gosain — Wed, 03 Sep 2025 05:40:29 GMT

When I first started automating infrastructure on AWS, I didn’t want to deal with writing giant YAML or JSON templates by hand. That’s where the AWS Cloud Development Kit (CDK) clicked for me. CDK lets me write infrastructure in TypeScript, which is the same language I use for most of my application code. It feels natural, it’s expressive, and I get to use the full power of a programming language — loops, conditions, functions — to define my infra.

What is CDK?

At its core, CDK is an Infrastructure as Code (IaC) framework. Instead of manually writing CloudFormation templates, you define your resources (like S3 buckets, Lambda functions, DynamoDB tables) using code. CDK then compiles that into CloudFormation under the hood and handles the deployment.

So in short:

I write infra in code.
CDK converts it into CloudFormation.
CloudFormation applies it to AWS.

That abstraction layer is what makes CDK so convenient.

How Does Terraform Fit In?

I haven’t used Terraform myself, but I often hear it compared with CDK. The way I see it:

Terraform is a widely used, declarative tool that works across multiple cloud providers.
CDK is tightly integrated with AWS and gives you the flexibility of coding infra in a real language.

If your team works across AWS + Azure + GCP, Terraform might make more sense. But if you’re deep in AWS (like me), CDK feels like a natural extension of app development.

CDK in 5 Basic Commands

The workflow with CDK is super simple. Most of the time I only use these five commands:

cdk init – start a new project (I usually pick TypeScript).
cdk synth – see the CloudFormation template CDK generates.
cdk diff – check what’s about to change in your infra before deploying.
cdk deploy – apply the changes to AWS.
cdk destroy – tear it all down if you don’t need it anymore.

That’s basically the lifecycle — define → preview → deploy → clean up.

Why I Prefer CDK

For me, CDK works best when:

I want my infra and application logic in the same language.
I need dynamic infra generation (like looping through configs to create multiple S3 buckets).
I want strong AWS-native support without extra layers.

The productivity boost I get from not context-switching between TypeScript and HCL/YAML is huge.

Skills Every MERN Stack Engineer Should Know (Beyond Just React & Express)

bipin gosain — Sat, 30 Aug 2025 07:02:41 GMT

Hey folks 👋,
One thing I’ve noticed is that when people say they “know MERN,” it often just means basic React + a couple of Express routes. But in real projects, that’s only the starting point.

If you want to actually thrive as a MERN engineer, here are a few skills worth investing in (beyond the basics):

1. State Management That Scales

useState and useEffect will only get you so far. For bigger apps, tools like Redux Toolkit, React Query, or Zustand make state predictable, manageable, and easier to debug.

2. Authentication & Authorization

Almost every app needs login and permissions. Learn JWTs, sessions, OAuth, role-based access, and how to integrate with services like Auth0 or Firebase.

3. MongoDB Beyond CRUD

Knowing find() isn’t enough. You should understand:

Schema design (when to embed vs reference)
Indexes & Aggregations for performance
Transactions when multiple collections are involved

4. Writing Better APIs

It’s not just app.get("/"). Think about:

API versioning (/v1, /v2)
Input validation
Rate limiting and error handling
Maybe even exploring GraphQL

5. Deployment & DevOps Basics

You’ll need to ship your app somewhere. At minimum:

Dockerize your app
Deploy to AWS, Vercel, or Netlify
Automate with CI/CD pipelines

6. Security & Performance

Real-world apps break if you don’t care about these:

Preventing XSS, CSRF, and SQL/NoSQL injections
Optimizing React with lazy loading & memoization
Using Redis or caching layers

7. Testing (Don’t Skip This)

Jest, React Testing Library, and Supertest can save you hours of debugging and help build trust in your code.

Wrapping Up

Being a MERN engineer is not about “just React and Express.” It’s about building scalable, secure, production-ready systems. Once you get comfortable with these extra skills, you’ll realize how much more confident you feel tackling real projects.

That’s my take — curious to know, what advanced MERN skill has helped you the most? 🚀

devbeyondbeginner

The Hidden Trap of Array.prototype.fill()

🚀 TLDR;

🧐 What Actually Happens: Shared References

✅ The Solution: Array.from({ length }, () => [])

💡 Why This Works: The Map Function Creates Unique Instances

Introduction to AWS CDK: When to Use It Over Terraform

What is CDK?

How Does Terraform Fit In?

CDK in 5 Basic Commands

Why I Prefer CDK

Skills Every MERN Stack Engineer Should Know (Beyond Just React & Express)

1. State Management That Scales

2. Authentication & Authorization

3. MongoDB Beyond CRUD

4. Writing Better APIs

5. Deployment & DevOps Basics

6. Security & Performance

7. Testing (Don’t Skip This)

Wrapping Up

✅ The Solution: `Array.from({ length }, () => [])`