DEV Community: Yash Chavan

Git is Not Magic- Part 2: Where Are You in the Timeline?

Yash Chavan — Sat, 07 Feb 2026 13:20:35 +0000

Remember that question from Part 1?

"Where exactly are YOU in this timeline?"

Let's answer it.

The Pointer Called HEAD

Now that we know our commits form a linked list pointing backward through time, there's one crucial piece missing: where are we right now?

Think back to our Polaroid album. You've got all these photos laid out, but you need to know which photo represents "now", which step of the cake you're currently working on. Are you still layering cream? Or have you moved on to adding decorations?

In Git, this "you are here" marker is called HEAD.

HEAD is just a pointer. That's it. It points to whichever commit you're currently looking at. Most of the time, it points to your latest commit, the present moment in your project's timeline.

commit 0 <- commit 1 <- commit 2 <- commit 3
                                      ↑
                                     HEAD

When you make a new commit, HEAD moves forward with you:

commit 0 <- commit 1 <- commit 2 <- commit 3 <- commit 4
                                                  ↑
                                                 HEAD

But here's where it gets interesting: HEAD can move backward too.

You can literally tell Git "take me back to commit 2" and suddenly you're looking at your code exactly as it was back then. It's like picking up an old Polaroid from your album and saying "I want to see what the cake looked like at this stage."

This is what git checkout does it moves HEAD to wherever you tell it to go.

Now here's where HEAD becomes really interesting: it doesn't just point to commits. Most of the time, HEAD points to a branch, and the branch points to a commit. When you make a new commit, the branch moves forward, and HEAD moves with it.

Keep this in mind as we talk about branches next.

Branches: Multiple Timelines

Now let's make things spicy.

What if while making your 3-layered cake, you had a sudden idea: "What if I made a chocolate version too?" You don't want to mess up your original vanilla cake, but you want to try this new idea.

So you take a Polaroid of where you are now, and start a separate album for the chocolate version. Both cakes start from the same point, but now they evolve differently.

This is what branches are.

A branch is just a label that points to a commit. That's literally all it is. And when you create a new branch, you're creating a new timeline that splits off from the current one.

                    ← commit 4 (chocolate-version)
                   /
commit 0 <- commit 1 <- commit 2 <- commit 3 (main)

You can work on chocolate-version, make commits, mess things up, experiment freely - and your main branch stays untouched. Your original vanilla cake is safe.

Merging: Bringing Timelines Together

After experimenting, you realize the chocolate version turned out amazing. You want to bring those changes back into your main cake recipe.

This is called merging.

When you merge, you're telling Git: "Take everything that happened in this alternate timeline and combine it with my current timeline."

commit 0 <- commit 1 <- commit 2 <- commit 3 <- commit 5 (merge commit)
                   \                           /
                    ← commit 4 (chocolate-version)

Git creates a special merge commit that has two parents one from each timeline. It's like saying "this point in history came from both paths."

Most of the time, Git is smart enough to figure out how to combine changes automatically. But sometimes there are merge conflicts situations where Git can't decide which change to keep. This happens when both timelines modified the same part of the same file differently.

It's like if in your chocolate timeline you added dark chocolate frosting, but in your main timeline you already added vanilla frosting to the same layer. Git stops and asks: "Which one do you want?"

You have to manually resolve the conflict pick one, combine them, or do something else entirely. Then you tell Git "okay, I've decided" and complete the merge.

Rebasing: Rewriting History

But what if you don't want that messy merge commit? What if you want your timeline to look clean, like the chocolate experiment happened after the main branch, not alongside it?

This is where rebase comes in.

Rebasing is like saying: "Take all my experimental commits, and pretend they started from a different point in time."

Before rebase:
                    ← commit 4 (chocolate-version)
                   /
commit 0 <- commit 1 <- commit 2 <- commit 3 (main)

After rebase:
commit 0 <- commit 1 <- commit 2 <- commit 3 <- commit 4' (chocolate-version)
                                     (main)

Notice commit 4 became commit 4', it's technically a new commit with the same changes but a different starting point. You've rewritten history.

Rebasing makes your history linear and clean. But here's the golden rule: never rebase commits that you've already shared with others [yes a rule to memorize]. Because you're literally changing history, and if someone else was working off the old history, you'll create a mess.

Think of it like this: merging is honest (it shows both timelines happened), rebasing is tidy (it pretends only one timeline happened).

You've Got the Power Now

Let's recap:

HEAD is just a pointer showing where you are. Branches are just labels, letting you create parallel universes for your code. Merging brings timelines together honestly. Rebasing rewrites history to keep things tidy.

You're not just taking Polaroids anymore, you're organizing entire photo albums, creating alternate storylines, and deciding how they come together.

But here's the thing:

So far, this has all been happening on your machine. Your Polaroids. Your albums. Your timelines.

What happens when you want to share these with your team? When you and a teammate both have photo albums of the same project?

How do you keep them in sync?

How does "your timeline" become "our timeline"?

That's Part 3.

Git Is Not Magic: Part 1: The Polaroid Analogy

Yash Chavan — Mon, 26 Jan 2026 07:31:41 +0000

Git is something each one of us in today’s world has to learn and well for most, it’s memorizing the command and using them like a type of flow:

add → commit → pull → push

…without understanding what Git actually is, or how it works, which keeps most of us scared of doing anything with Git.

IT DOESNT HAVE TO BE THAT WAY.

Let go on a very simple journey to understand Git, and get you from “Git scared” to “Git confident”, starting from the crux of it.

What is Git?

The technical definition of Git is:

“Git is a distributed version control software system”

But that’s very vague WHAT DOES IT EVEN MEAN!?

So lets take a step back and understand the technicalities ,

Git as we all know, keep track of our files, and the changes we make to them hence version control system,

But then what the “distributed” part is? ,

That means you don’t just have the latest code, you have the entire history on your own machine.

When you use GitHub, GitLab, or Bitbucket, you’re just syncing your copy of history with someone else’s copy of history.

You are not “sending code to a server”.

You are syncing timelines.

(And fun fact: it doesn’t even have to be GitHub — but that’s a story for another blog.)

Still feels a bit technical, right?

So let’s make it visual.

Taking Polaroids

Imagine we are baking a 3 layered cake, and you want to keep track of each step of the cake.

Every time we finish a step we pull out our Polaroid and click a photo, starting with setting the first base,*click* cutting it as we want,*click* layering it with basic cream, and so forth till we finish the entire cake

With each click, we are seeing the cake getting created out of nothing and we create a timeline for the cake creation.

This is what Git is like, where each photo is the commit we do, and just like the cake following our commits tells us the story of how we created our project from nothing.

Committing History

With every commit we do, we are creating the history of our project [ yes the same one we talked about during the distributed part ] and like the threads of the Polaroid, we can follow this history to find the origin.

Now in our tech world this is now it would look like

commit 0 <- commit 1 <- commit 2 <- present

Doesn’t this look familiar …. that’s right its a linked list, just reversed,

So every commit is like a node, and the arrow is the “next” pointer - except it points to the past and each node holds the snapshot of your code at that point of time.

So your Polaroid album is secretly a linked list.

You don’t need to think of Git like this all the time, but knowing this once removes a lot of fear.

You're Not Scared Anymore, Are You?

Let's recap what we've learned:

Git isn't magic. It's just Polaroids. Each commit is a snapshot of your project at a moment in time, and these snapshots form a linked list pointing backward through history. That's it.

When you do git add and git commit, you're not performing some mystical ritual — you're just taking a photo and adding it to your timeline.

The "distributed" part? That just means everyone has their own complete photo album, their own copy of the entire history. You're not dependent on some server in the cloud. You are the source of truth.

But wait.

If commits are snapshots in time, and they form this chain going backward through history...

Where exactly are YOU in this timeline?

Think about it. You've got this entire chain of commits stretching back to the beginning. But right now, as you're working on your code — which snapshot are you standing on?

And here's the real question: Can you move?

Next time you make a commit, don't think of it as "saving to Git." Think of it as "clicking a Polaroid."

You're building a timeline. You're creating history.

But who's holding the camera?

[Part 2 coming soon]

The Great OOP Illusion in JS

Yash Chavan — Mon, 15 Sep 2025 03:50:09 +0000

OOP is probably one of the first things we learn as programmers — in school, from tutorials, or when brushing up for that promotion and diving into design patterns. We’re taught about classes as blueprints, and objects as their instances. It feels universal: Java, C++, Python… OOP everywhere.

So naturally, when we start writing JS, we expect the same rules to apply. Classes, objects, inheritance — the works.

But here’s the twist: JavaScript fakes OOP really well — but under the hood, it’s something very different.

Let’s peel back that facade and see the truth of OOP in JS, using the very common example of a Human.

The Example Problem

Usually when OOP is taught, we pick a real-life analogy to make sense of it. So let’s do the same here.

We want to represent a Human. A Human has a name, an age, can greet() others and also grows old celebrating with happyBirthday().

But here’s the catch: let’s forget OOP exists for a moment. How would we build this the JavaScript way?

Creating a Human

Lets keep it stupid simple, and just create a Human.

let human1 = {
  name: "Adam",
  age: 25,
  greet: function () {
    console.log(`Hi, I’m ${this.name}, ${this.age} years old.`);
  },
  happyBirthday: function () {
    this.age++;
    console.log(`It’s my birthday! I’m now ${this.age}.`);
  }
};

human1.greet();        // Hi, I’m Adam, 25 years old.
human1.happyBirthday(); // It’s my birthday! I’m now 26.

That’s it we have created our Human, but this gives us only one Human. If we want more, we’d have to copy-paste this whole object. Too much effort, so lets reduce this and make a Human Factory

Factory Pattern

function createHuman(name, age) {
  return {
    name,
    age,
    greet: function () {
      console.log(`Hi, I’m ${this.name}, ${this.age} years old.`);
    },
    happyBirthday: function () {
      this.age++;
      console.log(`It’s my birthday! I’m now ${this.age}.`);
    }
  };
}

const human1 = createHuman("Bob", 30);
human1.greet();            // Hi, I’m Bob, 30 years old.
human1.happyBirthday();    // It’s my birthday! I’m now 31.

dusts hands off — now I can create as many Humans as I like. Pretty neat.

But wait… problem spotted! Every Human gets its own copy of greet and happyBirthday. If I make 1,000 Humans, that’s 1,000 duplicate functions sitting in memory. Yikes.

Surely JavaScript has some secret sauce for this.

The Secret Sauce Revealed

Turns out JS does has a Secret sauce, instead of cloning methods for every object, JavaScript quietly gives each object a hidden backstage link. Through this link, objects can borrow methods from a shared place — no duplication needed.

const humanMethods = {
  greet: function () {
    console.log(`Hi, I’m ${this.name}, ${this.age} years old.`);
  },
  happyBirthday: function () {
    this.age++;
    console.log(`It’s my birthday! I’m now ${this.age}.`);
  }
};

function createHuman(name, age) {
  let human = Object.create(humanMethods); // <-- the hidden link
  human.name = name;
  human.age = age;
  return human;
}

const h1 = createHuman("Charlie", 22);
h1.greet();            // Hi, I’m Charlie, 22 years old.
h1.happyBirthday();    // It’s my birthday! I’m now 23.

This hidden link is nothing but a hidden property called __proto__, which every JavaScript object has.

👉And remember, in JavaScript everything is an object (well… except a few primitives, but even they behave like objects when needed. And no — not class instance objects, just plain JS objects).

When JS runs and can’t find a property directly on your object, it doesn’t panic. Instead, it follows this hidden __proto__ trail, looking for the property in the linked object. That’s how greet and happyBirthday magically work without being duplicated.

Pretty neat, right?

Walks in the `new` Approach

But wiring up these hidden links with Object.create still feels a bit manual. Wouldn’t it be nice if JavaScript gave us a cleaner way to do it?

Turns out, functions themselves carry a secret power: they’re objects too, and each one has its own “backstage” property called prototype. And when you combine that with the new keyword… boom, you get a much cleaner way to wire things up.

function Human(name, age) {
  this.name = name;
  this.age = age;
}

Human.prototype.greet = function () {
  console.log(`Hi, I’m ${this.name}, ${this.age} years old.`);
};

Human.prototype.happyBirthday = function () {
  this.age++;
  console.log(`It’s my birthday! I’m now ${this.age}.`);
};

const h1 = new Human("Dave", 40);
h1.greet();            // Hi, I’m Dave, 40 years old.
h1.happyBirthday();    // It’s my birthday! I’m now 41.

Much cleaner! Now the “hidden link” is managed automatically by new.

*👉 Curious about how this hidden link (aka prototypes) really work under the hood?

💬 Drop a comment below if you’d like me to write a full breakdown of prototypes in my next blog.

Feels like a class, right? But don’t be fooled. Human is just a function, and new Human() creates a plain JS object linked to Human.prototype. Still no real classes yet.

The Final Facade - Classes

So far, we’ve gone from copy-pasting objects → factory functions → constructor functions with prototypes. Each step got us closer to something that looked like OOP, while still being powered by JavaScript’s hidden prototype magic.

And then ES6 came along and said:

“Hey devs, I see you’re faking classes anyway… why not make it look familiar?”

Enter class.

class Human {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  greet() {
    console.log(`Hi, I’m ${this.name}, ${this.age} years old.`);
  }

  happyBirthday() {
    this.age++;
    console.log(`It’s my birthday! I’m now ${this.age}.`);
  }
}

const h1 = new Human("Eve", 28);
h1.greet();           // Hi, I’m Eve, 28 years old.
h1.happyBirthday();   // It’s my birthday! I’m now 29.

Now it really looks like OOP. The same familiar feeling like with JAVA, C++, Python…

But here’s the kicker:

👉 class in JavaScript doesn’t invent a new OOP system. It’s pure syntactic sugar.

Behind the curtain, that class Human is still just a constructor function. Its methods? Still attached to Human.prototype. The “hidden link” we talked about? Still doing the heavy lifting.

The only real difference is how nice it looks when you type it.

So yeah, JS gives us the full OOP costume — but don’t be fooled. The foundation is still prototypes, all the way down.

console.log(typeof Human); // function

Why this Matters

Today, with GenAI and agentic tools writing much of our code, it’s tempting to skip fundamentals. But when things break — or when something new comes up — understanding what’s really happening under the hood is the difference between struggling and thriving as a developer.

JavaScript’s OOP is a perfect example. It looks familiar, but it’s fundamentally different. Once you see past the illusion, you gain a deeper mastery of the language, and that’s what truly makes you a better engineer.

Demystifying Next.js: A Fresh Perspective on the Meta-Framework Enhancing React.js

Yash Chavan — Thu, 24 Aug 2023 13:35:30 +0000

Embarking on the journey of web development, I was naturally drawn to the booming world of Next.js. A framework that purportedly makes React.js even better – an enticing prospect. However, unlike my relatively smooth experience with web and React.js, Next.js initially proved to be a challenge to comprehend. The concept eluded me, and there was a certain resistance to embracing something new. This blog is an encapsulation of how I eventually embraced Next.js, offering a fresh perspective that might help others look at this framework in a different light.

It's not a Replacement

One BIG misconception I had when I started to learn NEXT.js is that it replaces React.js, ie how I work with React and is a complete change of flow, mostly because of how it was marketed by people in tech and just the general notion of NEXT.js is so much better than just REACT.

Next.js: The Meta-Framework

What's Next.js's deal? The term "Meta-Framework" seemed bewildering at first. Let's demystify it in simple terms.

What is a Meta-Framework?

if we go on to google it or the new age GPT-ing it will tell you something on the line of

A meta-framework is a higher-level framework that provides a structure, guidelines, or common patterns for creating other frameworks. In other words, it's a framework for creating frameworks. Meta-frameworks are designed to simplify and standardize the process of developing specialized frameworks for specific purposes. ...

and it goes on to explain this over 15 paragraphs.

But to keep things simple Meta-Frameworks are just a structure added over an existing system

Still confused?

Meta-Frameworks make doing the same things a bit easier and in most cases just delegate the task via abstraction, like say routing in React ( the whole adding router-dom and creating the router and routes and everything) taken care of, image optimization and other list of things which NEXT markets.

BUT, Next.js doesn't just stop there, unlike what I hope most people think about NEXT.js

It's not a Frontend Framework

And I know it sounds confusing React is a Frontend Library, and Next is a Meta-Framework based around it, so it must be a frontend Framework. and I was the same until I tried to understand how NEXT works and how it is making React better performant and demystifying concepts like SSG

Understanding Next.js

I learned NEXT.js is a Backend Framework that just utilizes React.js to provide a frontend, I know it might sound confusing but let me make it more clear.

What NEXT does is uses build tools to convert your React js Frontend Pages into a well-optimized website and it does all of this based on the Backend which is an actual abstraction this Meta-Framework introduces, and which allows us to use tech like SSG as on the build time we can decide if we have to fully build the page*(Static Site Generation)* or just provide the js build like how React.js does it (client-side rendering) or have the page build on request*(Server-side Rendering)*

Clarity Emerges

This explains a lot of things and answers a lot of questions I had about the framework, like why can I write APIS, do I need to write a separate Backend then? how will the database connection work for multiple users if I decide to go RESTful with the API other stupid questions I had talking to the community was helpful.

Conclusion

I hope this writing, which started as a puzzle has transformed into a revelation and was able to help clear some misconceptions and give a new perspective to understanding how NEXT.js works and where it fits in this large world of Web development.

Next.js is no mere substitute for React.js; it's a dynamic companion that amplifies and enriches the React experience.

Here’s to embracing change, propelling innovation, and coding a luminous tomorrow.

Happy coding, and welcome to the remarkable world of Next.js!

Introduction to Fullstack JS

Yash Chavan — Wed, 21 Jun 2023 07:07:51 +0000

Welcome to the fascinating world of Fullstack JavaScript (JS) development! In this blog post, we'll embark on an exciting journey to explore the fundamentals, tools, and possibilities that Fullstack JS has to offer. Whether you're a beginner just starting or an experienced developer looking to expand your skill set, this guide will provide you with a solid foundation and ignite your passion for Fullstack JS development.

What is Fullstack JavaScript?

Fullstack JavaScript refers to the practice of using JavaScript not only on the front end but also on the back end of web applications. Traditionally, JavaScript was primarily used for client-side programming, handling interactivity and user interfaces. However, with the advent of Node.js, JavaScript became capable of running on servers, enabling developers to build end-to-end applications using a single language.

Why Choose Fullstack JavaScript?

There are several compelling reasons why Fullstack JS has gained popularity among developers:

Consistency: By utilizing JavaScript for both frontend and backend development, you achieve consistency in code syntax and structure, making it easier to maintain and understand your application as a whole.
Efficiency: With a shared codebase, Fullstack JS allows for more efficient development processes. You can reuse components, libraries, and even some business logic between the front end and back end, saving valuable time and effort.
Rapid Prototyping: JavaScript's vast ecosystem of libraries and frameworks, such as React, Angular, and Express, empowers Fullstack JS developers to quickly prototype and build feature-rich applications with ease.
JavaScript Mastery: If you're already familiar with JavaScript, transitioning to Fullstack JS will leverage your existing knowledge, enabling you to leverage your skills and become a more versatile developer.

Essential Tools and Technologies

To embark on your Fullstack JS journey, it's essential to familiarize yourself with the core tools and technologies used in this domain. Some key components you'll encounter include:

Node.js: An open-source, server-side runtime environment that allows you to run JavaScript on servers.
Express.js: A fast and minimalist web application framework for Node.js, ideal for building robust APIs and backend services.
React (any other framework also works): A popular JavaScript library for building user interfaces. React enables you to create dynamic, interactive front-end applications efficiently.
MongoDB: A powerful NoSQL database that seamlessly integrates with Node.js, allowing you to store and retrieve data for your applications.

The Learning Path Ahead

Throughout this blog series, we'll dive deeper into Fullstack JS development, covering topics such as:

Setting up your Fullstack JS development environment
Building RESTful APIs with Node.js and Express.js
Creating dynamic frontend interfaces with React
Database integration and management with MongoDB
Authentication and security best practices
Deploying Fullstack JS applications to production

By the end of this series, you'll have a comprehensive understanding of Fullstack JS development and be equipped with the skills to create robust, scalable, and modern web applications.

Are you ready to embark on this thrilling Fullstack JS adventure? Let's dive in and unlock the endless possibilities of Fullstack JavaScript development!

In the next blog post, I will guide you through setting up your Fullstack JS development environment. Stay tuned!

Happy coding!

What are Multi-Stage Docker Images?

Yash Chavan — Tue, 20 Jun 2023 14:18:43 +0000

Introduction

Let's start from the basics

Docker! It's an awesome tool that lets you create, deploy, and run applications in these neat little containers. Think of them like tiny virtual machines, but with just enough resources to run your app. It's fantastic since it means you can run your application on any platform, from your laptop to the cloud!

The Power of Docker Images

Docker images are one of the key elements that make Docker so powerful. These are pre-built, pre-configured packages that include everything your app requires to execute - code, libraries, and dependencies. They're like the ultimate Lego set for developing and distributing applications!

But what if Docker images got better?

That's where multi-stage Docker images come in. They're like the superheroes of the Docker world - able to create smaller, faster, and more efficient images by separating the build and runtime environment. With multi-stage Docker images, you can save disk space, reduce build times, and even improve security!

The Magic of Multi-Stage Docker Images

What are Multi-Stage Docker Images?

Are you tired of creating bloated Docker images that take forever to build and deploy? Multi-stage Docker images to the rescue! These superheroes of the Docker world allow you to create smaller, faster, and more secure images by separating the build and runtime environment.

Let's say you're building a TypeScript app with Node.js as the runtime environment. With a traditional Docker image, you'd have to include everything in the same image, leading to a larger image size. But with a multi-stage Docker image, you can create a lean and mean image that only includes what's necessary.

# First stage: build environment
FROM node:14-alpine as build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Second stage: runtime environment
FROM node:14-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY package*.json ./
RUN npm install --only=production
CMD ["npm", "start"]

Traditional vs. Multi-Stage Docker Images

Traditional Docker images use a single stage to build and package an application, which means that the image includes both the build and runtime environment. This can make the image larger and less efficient.

On the other hand, multi-stage Docker images allow you to create smaller, more efficient images by separating the build and runtime environment. Each stage in a multi-stage Docker image can have its own base image, dependencies, and build instructions. You can use the COPY command to copy files between stages, and the final stage is used to create the final image that will be deployed.

Let's consider the above example of a Typescript app that you want to deploy to a serverless platform like AWS Lambda. With traditional Docker images, you would include both the build and runtime environment in a single image, which would result in a larger image size. This can slow down deployment times and make your app less responsive. Here's an example Dockerfile for a TypeScript app with traditional images:

# Tradional Docker image
FROM node:14-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install 
COPY . .
RUN npm run build
CMD ["npm", "start"]

As you can see, we not only install all dependencies, regardless of whether they are required in the production environment, but we also have the TypeScript code and the transpiled JavaScript, thus producing two copies of the same code.

Whereas with multi-stage Docker images, you can keep the size of your Docker image small by separating the build and runtime environment into separate stages. Here's an example Dockerfile for a TypeScript app that uses multi-stage Docker images:

# Build stage
FROM node:14 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Runtime stage
FROM node:14-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY package*.json ./
RUN npm install --only=production
CMD [ "npm", "run", "start" ]

Demystifying Multi-Stage Docker Images

Multi-stage Docker images work like a well-coordinated team, with each stage performing a specific task. In the first stage, you can use a TypeScript base image and include your source code and build tools. This stage compiles your TypeScript code and creates a build artifact.

FROM node:14 AS build
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

In the next stage, you can use a Node.js base image and copy only the runtime dependencies needed to run your app from the previous stage. By keeping the runtime environment separate, you can create a smaller, more efficient Docker image.

FROM node:14-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY package*.json ./
RUN npm install --only=production
CMD [ "npm", "run", "start" ]

The final stage can then create the final image that's ready for deployment. And the best part? With this approach, you can significantly reduce the size of your Docker image, making it faster and easier to deploy your TypeScript app.

Conclusion

Benefits of Multi-Stage Docker Images

They offer numerous benefits, including smaller image sizes, faster builds, reduced attack surface, and improved maintainability. By separating the build and runtime environments, you can create leaner, more efficient Docker images that are perfect for containerizing your applications.

Final Thoughts

Multi-stage Docker images are particularly useful for applications with complex build processes or large dependencies, such as TypeScript applications. They also shine when deploying to serverless platforms like AWS Lambda or Kubernetes Clusters for easy and fast management.

Using TypeScript with Docker: A Guide to Containerize Your Applications

Yash Chavan — Tue, 20 Jun 2023 14:16:40 +0000

Introduction

Prerequisites

Before we get into using Typescript and Docker together, it is important to understand what these technologies are on their own

Typescript is a programming language that extends JavaScript by adding new features such as type annotations, class and interface definitions, modules, decorators, and more. It's particularly useful for large-scale projects and for developing robust and maintainable code.
Docker is a platform that allows developers to create, deploy, and run applications in containers. Containers are lightweight, portable, and self-sufficient environments that can run on any machine that supports Docker, regardless of the underlying infrastructure, it provides several benefits, including portability, isolation, scalability, automation, and standardization

Understanding these two technologies makes it clear why knowing how to combine the two to build and deploy your applications can be beneficial

Benefits of using TypeScript and Docker

Using Typescript and Docker together gives the clear benefit of having robust and reliable apps but there are several more benefits when building and deploying applications:

Type safety: TypeScript's type annotations can help catch errors early during development, making the code more predictable and easier to understand. This can reduce the number of bugs in the application.
Improved development experience: TypeScript's advanced type system also comes with powerful autocomplete capabilities, providing developers with suggestions for properties, methods, and parameters, making coding faster and more efficient.
Better maintainability: TypeScript's class and interface definitions, modules, and decorators can make the code more organized and reusable, making it easier to maintain and update the application over time.
Consistency and reliability in deployment: Docker allows you to package your application and its dependencies into a single container, which can be easily deployed to any environment. This makes deployment more consistent and reliable and can help to reduce the number of environment-specific bugs.
Scalability: Docker allows for easy scaling of applications by running multiple containers, which can handle increased traffic and workloads.
Portability: Docker containers can be easily moved between different environments, such as development, staging, and production. This ensures consistency and reduces complexity.
Isolation: Docker allows multiple applications or services to run on the same machine without interfering with each other, improving the security and stability of the application.
Improved collaboration: Docker provides a consistent set of tools and technologies that can be used across different environments (So no more, "but it worked on my machine" from your peers), making it easier for developers to collaborate and share their work.

Setting up a TypeScript and Docker project

Let's take an example of a simple Nodejs application to get/create todos in typescript. (make sure you have Node, npm and Docker installed to follow along)

Step 1 - Setting up

To get started open your directory and setup your node app as usual with express.js, or follow the code given below

npm init -y
npm install express body-parser

Step 2- Adding TypeScript

To add Typescript run the following command

npm install --save-dev typescript @types/express nodemon ts-node

This will install typescript as a dev dependency along with types for express, and nodemon which we will use for testing the app locally along with ts-node

TypeScript uses a file called tsconfig.json to configure the compiler options for a project. Create a tsconfig.json file in the root of the project directory and paste the following JSON

{
  "compilerOptions": {
    "module": "commonjs",
    "esModuleInterop": true,
    "target": "es6",
    "moduleResolution": "node",
    "sourceMap": true,
    "outDir": "build"
  },
  "lib": ["es2015"]
}

At this point, your directory should look like this

--node_modules/ 
--package.json 
--tsconfig.json

Step 3 - Creating the App

Then create App.ts file ( you can name it anything you like I prefer App.ts) and paste the code below

import express, { Request, Response } from 'express';
import bodyParser from 'body-parser';

interface Todo {
    id: number;
    task: string;
    completed: boolean;
}

const app = express();
app.use(bodyParser.json());
let todos: Todo[] = [
    {id: 1, task: "Take out trash", completed: false},
    {id: 2, task: "Do laundry", completed: true}
];

app.get("/", (req: Request, res: Response) => {
    res.send("Hello World");
});


app.get('/todos', (req: Request, res: Response) => {
    res.send(todos);
});

app.post('/todos', (req: Request, res: Response) => {
    const newTodo: Todo = req.body;
    todos.push(newTodo);
    res.send(newTodo);
});

app.listen(3000, () => {
    console.log('Server is running on port 3000');
});

At this point, your directory should be looking like this

--node_modules/
--package.json
--tsconfig.json
--App.js

Step 4 -Time to test the app

To check if the app runs, we already have installed the tools need nodemon which uses ts-node to auto compile and autorun our app with changes, BUT we need to make some changes in our package.json

{
...,
"main": "App.ts",
...,
"scripts":{  
    "dev": "nodemon",
    "start": "node build/App.js",
    "build": "tsc --project ./"
  },
...
}

dev is used for testing, while the build is used to compile our typescript code and start to run the compiled javascript app.

To start the test server run the following command

npm run dev

Once nodemon finishes you should see the following

$ nodemon
[nodemon] 2.0.20
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: ts,json
[nodemon] starting `ts-node App.ts`
Server is running on port 3000

Step 5 - Setting up Docker

The next step is to set up Docker, we do that by creating a Dockerfile and paste the following:

FROM node:14-alpine
WORKDIR /app
COPY . .
RUN npm install
RUN npm run build
EXPOSE 3000
CMD ["npm","run", "start"]

This is the Dockerfile which is the schema to create your docker image,

the COPY command copies everything in the root directory to the app directory inside the docker image, to avoid us also copying the node modules we need to create a .dockerIgnore file and add the following inside it,

/node_modules

/build

Now to create the docker image run this command in your terminal:

docker build . -t tsdocker

This will create the docker image

docker run -p 3000:3000 tsdocker

You can open HTTP://Localhost:3000 and get the message Hello World on your screen and there you have it. You have set up your typescript app with docker. We will further how to deploy with a platform like render, in some future blog

Conclusion

Using TypeScript and Docker together can bring many benefits to a Node.js application. TypeScript provides a way to catch bugs early on by providing type checking and interfaces, while Docker allows for easy deployment and scaling of the application by packaging it in a lightweight container. Additionally, Docker provides a consistent environment regardless of the underlying infrastructure, which can prevent issues caused by differences between development and production environments. Furthermore, TypeScript and Docker make it simple to test the application in various environments as well as manage infrastructure and scaling. Finally, they can help to improve the overall development and deployment process by automating the building, testing, and deployment of code changes.

However, we haven't covered all the things, some advanced things you can cover on your own or through my future blogs are using multi-stage build in Dockerfile or using docker compose to run multiple containers.

Getting started with Web-dev

Yash Chavan — Tue, 20 Jun 2023 14:14:54 +0000

Introduction

Starting to get into web development is often taken in this step learn HTML jump on CSS and a framework like bootstrap and then JavaScript finally landing on the framework and boom you are done. This is somewhat wrong as we are not only skipping over the foundation but also just oversimplifying web development

Understanding the Foundation

Understanding the foundation of web development is simple as it is covered in the name of the web. However, there is a common misunderstanding regarding the distinction between the web and the internet.

What is the difference between the Web and the Internet

The Internet is a global network of networks while the Web, also referred to formally as World Wide Web (www) is a collection of information that is accessed via the Internet. Another way to look at this difference is; the Internet is infrastructure while the Web is served on top of that infrastructure. Alternatively, the Internet can be viewed as a big book store while the Web can be viewed as a collection of books on that store. At a high level, we can even think of the Internet as hardware and the Web as software!

once the difference is clear next is how this software communicates over this massive network it is built on, more technically known as Protocols, to be specific, and the important one for now HTTP.

So what is HTTP?

The Hypertext Transfer Protocol (HTTP) is the foundation of the World Wide Web and is used to load web pages using hypertext links. HTTP is an application layer protocol designed to transfer information between networked devices and runs on top of other layers of the network protocol stack. A typical flow over HTTP involves a client machine making a request to a server, which then sends a response message.

another important step into web dev is to understand what side of the development you want to be or to make it sound not only technical but also erotic (weirdly) which end you like (namely Frontend, Backend)

What's your Poison?

Front-end web developers focus on a website's client-side functions, while back-end web developers focus on a website's server-side development. Full-stack developers work with just that - the "full stack" of development technologies - and have mastery of both front and back-end technologies.

Front end developers

They create the content you see when interacting with a website. This includes visual elements such as menus, buttons, and animations that can execute on a client's machine. Front-end developers use three primary languages: HTML to create a website's structure, CSS to change how a website looks, and JavaScript to create interactive elements.

Back end developers

They work with the server side of a website. This involves managing web servers, interacting with databases, and using data analysis - all of which are functions the user doesn't see when interacting with the site.

Full Stack developers

They do both, take care of frontend and backend both

And this where learning to code can come in you now know not only how the web works but also what you wanna do on it and can respectively plan your road, though, in my opinion, it is important to learn at least basic frontend development even if you prefer backend

DEV Community: Yash Chavan

Git is Not Magic- Part 2: Where Are You in the Timeline?

The Pointer Called HEAD

Branches: Multiple Timelines

Merging: Bringing Timelines Together

Rebasing: Rewriting History

You've Got the Power Now

Git Is Not Magic: Part 1: The Polaroid Analogy

What is Git?

Taking Polaroids

Committing History

You're Not Scared Anymore, Are You?

The Great OOP Illusion in JS

The Example Problem

Creating a Human

Factory Pattern

The Secret Sauce Revealed

Walks in the new Approach

The Final Facade - Classes

Why this Matters

Demystifying Next.js: A Fresh Perspective on the Meta-Framework Enhancing React.js

It's not a Replacement

Next.js: The Meta-Framework

What is a Meta-Framework?

It's not a Frontend Framework

Understanding Next.js

Clarity Emerges

Conclusion

Introduction to Fullstack JS

What is Fullstack JavaScript?

Why Choose Fullstack JavaScript?

Essential Tools and Technologies

The Learning Path Ahead

What are Multi-Stage Docker Images?

Introduction

Let's start from the basics

The Power of Docker Images

But what if Docker images got better?

The Magic of Multi-Stage Docker Images

What are Multi-Stage Docker Images?

Traditional vs. Multi-Stage Docker Images

Demystifying Multi-Stage Docker Images

Conclusion

Benefits of Multi-Stage Docker Images

Final Thoughts

Further reading and learning

Using TypeScript with Docker: A Guide to Containerize Your Applications

Introduction

Prerequisites

Benefits of using TypeScript and Docker

Setting up a TypeScript and Docker project

Step 1 - Setting up

Step 2- Adding TypeScript

Step 3 - Creating the App

Step 4 -Time to test the app

Step 5 - Setting up Docker

Conclusion

Getting started with Web-dev

Introduction

Understanding the Foundation

What is the difference between the Web and the Internet

So what is HTTP?

What's your Poison?

Front end developers

Back end developers

Full Stack developers

Walks in the `new` Approach