DEV Community: Guna SantoshDeep Srivastava

Service-to-Service Communication in Microservices: What Every Developer Should Know

Guna SantoshDeep Srivastava — Mon, 13 Jul 2026 09:02:51 +0000

I still remember the first time a junior dev I was mentoring asked me, "why did the order service just... hang for 30 seconds and then crash the whole checkout flow?" The answer had nothing to do with their code being wrong. It had everything to do with how their service was talking to another service — and nobody had ever actually taught them that part.

That's the gap this post is trying to close. Not "what is a microservice" — you already know that. This is about the part that trips up almost everyone the first time they split a monolith into services: how do these things actually talk to each other, and what breaks when they do?

We'll go through this using Spring Boot, since that's what most Java shops are running, but the concepts carry over regardless of stack.

The thing that changes the moment you split a monolith

In a monolith, calling another module is just a method call. It's fast, it's reliable, and if something goes wrong, you get a stack trace pointing at the exact line.

The moment that "module" becomes a separate service running somewhere else, that method call becomes a network call. And a network call can fail in ways a method call never does: the other service could be slow, temporarily down, overloaded, or reachable but taking 45 seconds to respond because its database is having a bad day. Your code needs to handle all of that, and most tutorials skip straight past it to show you the happy path.

So let's not skip it.

Synchronous communication: when you need the answer right now

This is the "call and wait" pattern — Service A calls Service B and blocks until it gets a response. Good for things like "check if this user is allowed to do this," where you genuinely can't proceed without the answer.

RestTemplate — you'll see this in a lot of existing codebases. It's not formally deprecated, but the class Javadoc itself says it's in maintenance mode and won't get new features. Worth knowing how to read, not worth starting a new project with.

RestTemplate restTemplate = new RestTemplate();
UserDto user = restTemplate.getForObject(
    "http://user-service/users/{id}", UserDto.class, userId);

If you specifically want a modern synchronous client without pulling in WebFlux, Spring Boot 3.2+ also ships RestClient — same fluent style as WebClient below, but blocking by default. Worth a look if WebClient feels like overkill for a non-reactive app.

WebClient — the modern reactive replacement, and it works fine even if you're not doing reactive programming elsewhere in your app. You can call .block() if you just want a plain synchronous result. Full options are in the Spring Framework WebClient reference, including the example code for things like timeouts and filters.

WebClient client = WebClient.create("http://user-service");

UserDto user = client.get()
    .uri("/users/{id}", userId)
    .retrieve()
    .bodyToMono(UserDto.class)
    .block();

OpenFeign — if you're in a Spring Cloud microservices setup, this is probably what you actually want. You declare an interface, Feign generates the HTTP client for you, and it reads like a normal method call again. Full setup and config options are in the Spring Cloud OpenFeign reference docs.

@FeignClient(name = "user-service")
public interface UserClient {
    @GetMapping("/users/{id}")
    UserDto getUser(@PathVariable("id") Long id);
}

Then you just inject UserClient and call userClient.getUser(id) like it's a local bean. This is usually the nicest developer experience of the three, which is part of why it's so widely used in Spring Cloud shops.

Worth knowing if you're starting something new: Spring Cloud OpenFeign itself now says it's feature-complete and points people toward Spring's own native declarative clients (@HttpExchange + @ImportHttpServices), introduced in Spring Framework 7. Same declarative-interface idea as Feign, just built into core Spring instead of a separate dependency. Spring's own writeup on it is here if you want the example code. Feign isn't going anywhere soon, but if you're picking a client for a brand-new project, it's worth a look before you default to Feign out of habit.

Asynchronous communication: when you don't need the answer right now

Not everything needs an immediate response. "Send a confirmation email after checkout" doesn't need to block the checkout request — it just needs to eventually happen. This is where message brokers come in: Service A publishes an event, Service B picks it up whenever it's ready, and the two services never have to be online at the same moment.

Kafka, with Spring Kafka (full reference and runnable examples here):

// Producer
@Autowired
private KafkaTemplate<String, OrderEvent> kafkaTemplate;

public void publishOrderCreated(OrderEvent event) {
    kafkaTemplate.send("order-events", event);
}

// Consumer, in a different service entirely
@KafkaListener(topics = "order-events", groupId = "email-service")
public void handleOrderCreated(OrderEvent event) {
    emailService.sendConfirmation(event.getOrderId());
}

RabbitMQ, with Spring AMQP (reference docs and more listener examples here), if you want more routing flexibility than Kafka's topic model gives you:

@RabbitListener(queues = "order.created.queue")
public void handleOrderCreated(OrderEvent event) {
    emailService.sendConfirmation(event.getOrderId());
}

The real decision isn't "Kafka vs RabbitMQ" — that's a second-order question. The first question is sync vs async, and that comes down to one thing: does the caller need the result before it can continue? If yes, sync. If no, you're just adding latency and coupling for no reason by making it synchronous.

The part beginners skip and seniors get burned by anyway

This is the section that actually matters more than picking a client library.

Timeouts. If you don't set one explicitly, you may be relying on a default that's way too generous — or in some client setups, no timeout at all. A slow downstream service without a timeout on the caller side doesn't just slow you down, it can exhaust your thread pool and take down services that have nothing to do with the original problem.

WebClient client = WebClient.builder()
    .baseUrl("http://user-service")
    .clientConnector(new ReactorClientHttpConnector(
        HttpClient.create().responseTimeout(Duration.ofSeconds(3))))
    .build();

Retries. Sounds simple until you ask: is this call safe to retry? A GET usually is. A POST that charges a credit card is not — unless you've made it idempotent (idempotency keys are the usual fix). Blindly wrapping every call in a retry loop is how you get duplicate charges, not resilience.

Circuit breakers. When a downstream service is genuinely down, retrying just piles more load onto something that's already struggling — and it makes the caller's own response times terrible while it keeps trying. Resilience4j (official docs and full config reference here) handles this cleanly in Spring Boot:

@CircuitBreaker(name = "userService", fallbackMethod = "fallbackUser")
public UserDto getUser(Long id) {
    return userClient.getUser(id);
}

public UserDto fallbackUser(Long id, Throwable t) {
    return UserDto.guest();
}

Once the failure rate crosses a threshold, the circuit "opens," calls fail fast without even hitting the network, and the fallback kicks in instead. That one annotation is doing a lot of work most teams don't add until after their first real outage.

Finding each other in the first place

One more piece worth knowing: in a real deployment, service instances scale up and down and their addresses change. Hardcoding http://user-service-host:8080 doesn't survive that. Spring Cloud's usual answer is a discovery service like Eureka, paired with Spring Cloud LoadBalancer — services register themselves on startup, and callers ask the registry "where's user-service right now?" instead of hardcoding an address. If you noticed http://user-service in the Feign and WebClient examples above with no port or IP — that's this in action, resolved by the load balancer at call time.

Quick decision guide

Situation	Reach for
You need the result before you can continue	Synchronous (WebClient or Feign)
The action can happen "eventually"	Asynchronous (Kafka or RabbitMQ)
Multiple services need to react to the same event	Asynchronous, pub/sub
Calling a flaky or slow external dependency	Synchronous + circuit breaker, always
Instance addresses change as you scale	Service discovery (Eureka), not hardcoded URLs

What I've actually seen go wrong in practice

The bug that gets people almost every time isn't a missing feature — it's a missing timeout. Someone calls a downstream service, doesn't set an explicit timeout, everything works fine in dev because the downstream service is fast and local, and then in production, under real load, one slow dependency quietly takes the whole request chain down with it. It's boring, it's not a "clever" bug, and it's also the single most common root cause I've run into in real incident reviews.

If you take away one thing from this post: don't add a client library and call it done. Set a timeout. Decide, explicitly, whether each call is safe to retry. Those two habits alone prevent most of the outages I've seen traced back to service-to-service calls.

What's the worst service-to-service incident you've personally debugged? I'm curious whether it was a timeout, a retry storm, or something weirder — genuinely feels like everyone in this field has one story.

AWS CodePipeline Tutorial: Deploy to EC2 with CodeCommit, CodeBuild & CodeDeploy

Guna SantoshDeep Srivastava — Mon, 13 Jul 2026 07:35:29 +0000

This is a step-by-step AWS CodePipeline tutorial for anyone who needs to deploy to EC2 using CodeCommit, CodeBuild, and CodeDeploy together. I set this exact pipeline up recently and kept notes as I went, so this is the walkthrough I wish I'd had — console clicks and all.

The pipeline covers the standard flow: pull source from CodeCommit, build it with CodeBuild, and deploy straight to an EC2 instance with CodeDeploy. No test stage, no load balancer — just the core CodePipeline setup most small-to-mid apps actually need to get from git push to a running EC2 instance.

If you want to cross-check any step against the source, AWS's own walkthrough for this exact flow is here: Tutorial: Create a simple pipeline (CodeCommit repository).

Before you start

Make sure you've got:

Console access with permissions for CodePipeline, CodeCommit, CodeBuild, and CodeDeploy
Your source code already pushed to a CodeCommit repo
Three IAM service roles created ahead of time: one for CodePipeline, one for CodeBuild, one for CodeDeploy (EC2)
A target EC2 instance with the CodeDeploy agent installed and an IAM instance profile attached
A buildspec.yml in the root of your repo

If any of those are missing, sort them out first — the pipeline wizard will let you create some things inline, but the IAM roles are much easier to set up beforehand.

Step 1: Confirm your CodeCommit repo exists

Nothing fancy here — just make sure the repository you want to build from is already in CodeCommit with your code pushed to the branch you plan to deploy from.

Step 2: Open CodePipeline and start a new pipeline

From the AWS Console, go to CodePipeline → Create pipeline.

Step 3: Choose "Build custom pipeline"

This gives you full control over each stage instead of using one of the templated flows.

Step 4: Configure the pipeline basics

Setting	Value
Pipeline name	whatever makes sense for your app/environment
Execution mode	Superseded
Service role	Existing service role
Role ARN	`arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<YourCodePipelineServiceRole>`
Advanced settings	Defaults are fine to start

Step 5: Add the source stage

Setting	Value
Source provider	AWS CodeCommit
Repository name	your repo
Branch name	whichever branch this pipeline should track (e.g. `main`, `qa`, `staging`)
Other settings	Defaults

Step 6: Setting up the CodeBuild stage

Set Build provider to AWS CodeBuild.

If you already have a CodeBuild project for this app, just search for it and select it. If not, here's what a fresh project looks like (full console walkthrough here):

Setting	Value
Project name	name it after your app
Environment – OS	Amazon Linux
Environment – Runtime	Standard
Environment – Image	`aws/codebuild/standard:6.0`
Service role	Existing service role
Role ARN	`arn:aws:iam::<YOUR_ACCOUNT_ID>:role/service-role/<YourCodeBuildServiceRole>`
Buildspec	Use a buildspec file
Batch configuration / Logs	Defaults

After creating it, go back and select it from the project list — the wizard doesn't always auto-select a project you just created.

Optional environment variables, if your build needs them:

Name	Example value
`PROFILE_NAME`	`qa`
`HOST_ENTRY`	`<your-ec2-hostname>:<your-ec2-private-ip>`

Leave build type as Single build unless you specifically need batch builds.

Step 7: Skip the test stage

Unless you're wiring up an automated test stage separately, you can skip this one entirely.

Step 8: Setting up the CodeDeploy stage for EC2 deployment

Setting	Value
Deploy provider	AWS CodeDeploy
Input artifacts	BuildArtifact
Application name	select existing, or create new

If you don't have a CodeDeploy application yet:

Go to CodeDeploy → Applications → Create application
Set Compute platform to EC2/On-Premises
Create a deployment group with:

Setting	Value
Service role ARN	`arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<YourEC2CodeDeployRole>`
Deployment type	Default (in-place, unless you need blue/green)
Environment configuration	Amazon EC2 instances
Instance name/tag	whatever tag identifies your target instance(s)
Load balancer	leave unchecked if you're not using one

Step 9: Review and create

Double check every stage, then hit Create pipeline. It'll kick off an initial run immediately.

A few things I'd flag for anyone doing this

Double-check your IAM trust relationships before you start. Half the "pipeline failed" errors I hit came down to a service role missing a trust policy, not the pipeline config itself.
Never commit real account IDs, role ARNs, or internal hostnames into a public repo or a public writeup. It's an easy habit to slip into when you're copying from your own working setup — always swap in placeholders before sharing.
Validate your buildspec.yml locally (or with aws codebuild start-build first) before wiring it into a full pipeline. Debugging a broken buildspec through the pipeline UI is slower than catching it upfront.
If you're running this across multiple environments (dev/QA/prod), keep the environment-specific values — account IDs, hostnames, role ARNs — in a separate config reference rather than hardcoding them per pipeline. Makes it much easier to replicate later.

That's the whole flow. Happy to answer questions if anyone's stuck on a specific stage.

Cursor Just Became Part of SpaceX — Here's What Developers Should Actually Watch For

Guna SantoshDeep Srivastava — Mon, 13 Jul 2026 07:08:24 +0000

I saw the headline last month and honestly scrolled past it — another AI company acquisition, who cares. But this one's actually worth a second look if you write code for a living.

Cursor's parent company, Anysphere, is getting absorbed into SpaceX. $60 billion, all stock, deal reported by CNBC here. Most of what's been written about it is finance-desk stuff — IPO timing, share structure, how fast the revenue curve went up and to the right. Nobody's really talked about what it means for the tool itself, which is the part I actually care about.

What happened, quickly

SpaceX had an option to buy Anysphere sitting around since April, and in June they used it. Once the deal closes (expected sometime this quarter, still pending regulatory approval), Cursor becomes part of the same company that owns xAI and Grok. So Elon's AI stack, which never really had a coding product of its own, suddenly has one — same category as Claude Code from Anthropic or Codex from OpenAI.

On its own that's just an acquisition. Companies buy companies. But there's a piece of this that actually changes the product, not just the org chart.

The part that actually matters

Cursor's whole thing, since it launched, was that it didn't care which model you used. Claude, GPT, Gemini, its own Composer model — you picked whatever worked for the task and Cursor got out of the way. That's a big reason a lot of teams picked it over something tied to a single vendor.

Once your editor's parent company also owns a frontier model, "we don't care which model you use" gets a lot harder to actually believe, even if nothing changes on day one. There's a quote from an analyst at Futurum Group that stuck with me — he said moving inside a model vendor turns a model-agnostic layer into a captive one. That's the whole risk in one sentence. Enterprise teams are already treating Cursor less like a neutral tool and more like a bet on one company.

I'm not saying Cursor gets worse next week. I'm saying if you picked it because it let you shop around, that reason just got shakier.

What I'd actually keep an eye on

Not going to pretend I have a crystal ball here, but if I were running Cursor day to day, this is what I'd watch instead of doom-scrolling about it:

Whether the model picker starts quietly defaulting to Grok/Composer instead of staying neutral. Whether the pricing gap between first-party and third-party models (which already showed up this month) gets wider once the deal actually closes. Whether the data/training policy changes once Cursor sits under new ownership — worth a second read once that happens instead of assuming it's the same as before. And if your company has an enterprise contract with Cursor, it's probably worth an email to whoever owns that relationship, just to ask what happens to it.

None of that is a reason to switch tools today. It's a reason to actually read the changelog for once instead of clicking past it.

Where I land on this

I don't think Cursor is doomed, and I'm not telling anyone to jump to Claude Code or Codex out of pure caution. Tools get bought all the time and plenty of them keep getting better afterward. But "who owns the company behind my editor" is now a real factor in choosing a coding tool, in a way it wasn't six months ago. That's new, and I don't think enough people are talking about it.

I mostly live in VS Code with Copilot day to day rather than Cursor, so I'm watching this one from the outside — but I'm curious how it looks from the inside.

If you're actually running Cursor right now: does any of this change what you're doing, or does it not matter at all to you? Curious if I'm overthinking a corporate acquisition that has nothing to do with the editor you open every morning.

angular

Guna SantoshDeep Srivastava — Tue, 24 Jun 2025 06:23:19 +0000

OpenJDK vs. Oracle JDK: Key Differences and When to Use Each

Guna SantoshDeep Srivastava — Tue, 24 Jun 2025 06:12:01 +0000

Introduction

When developing Java applications, choosing the right Java Development Kit (JDK) is crucial. Two prominent options are OpenJDK and Oracle JDK. Both serve the same core purpose—providing the essential tools and libraries for building and running Java applications—but they differ in licensing, development model, and support.

In this article, we’ll explore the key differences and similarities between OpenJDK and Oracle JDK to help you make an informed decision on which is the best fit for your project or organization.

Licensing: Open Source vs. Commercial

One of the primary differences between OpenJDK and Oracle JDK lies in their licensing models.

Oracle JDK: This is a closed-source, commercially licensed software developed by Oracle Corporation. If you use Oracle JDK in production environments, especially for commercial purposes, you’ll need to purchase a license. This commercial licensing ensures access to Oracle's premium support services and regular updates.
OpenJDK: On the other hand, OpenJDK is an open-source project licensed under the GNU General Public License (GPL) version 2, with the Classpath Exception. This means OpenJDK can be freely used, modified, and redistributed by anyone. It’s a great choice for individual developers, open-source projects, or organizations looking for a cost-effective solution.

Development Model: Proprietary vs. Community-Driven

The development models of Oracle JDK and OpenJDK also differ significantly:

Oracle JDK: Oracle JDK is entirely maintained and developed by Oracle Corporation. It is optimized for enterprises, with a strong focus on providing commercial support, advanced performance optimizations, and enterprise-grade features.
OpenJDK: OpenJDK, while overseen by Oracle, is an open-source, community-driven project. Major companies like Red Hat, as well as independent developers, contribute to its development. This collaborative approach ensures continuous improvements and broader community support, but without the dedicated commercial backing of Oracle JDK.

Functional Equivalence: Identical in Code Base

From Java 11 onwards, Oracle JDK and OpenJDK are virtually identical in terms of functionality. Both are built from the same code base, meaning they provide the same libraries, tools, and APIs for developing and running Java applications.

For example, features like Flight Recorder and Mission Control—originally exclusive to Oracle JDK—are now included in both versions. Whether you choose OpenJDK or Oracle JDK, the functionality remains the same.

Key Differences: Support and Cost

While OpenJDK and Oracle JDK are functionally equivalent, they differ in support and cost:

Support:
- Oracle JDK: Enterprises using Oracle JDK benefit from professional support services, including regular updates, security patches, and performance tuning from Oracle.
- OpenJDK: OpenJDK relies on community support. While companies like Red Hat also provide support for their OpenJDK distributions, the overall support model is community-based, with updates and issue resolution handled by contributors.
Cost:
- Oracle JDK: Requires a paid commercial license for production environments. This cost ensures access to Oracle’s premium support and features.
- OpenJDK: Completely free and open-source, with no licensing fees required for any usage.

When to Choose OpenJDK?

OpenJDK is the right choice if:

You’re an individual developer or working on a small project where budget constraints are a priority.
Your organization prefers open-source software for flexibility, transparency, and cost-effectiveness.
You don’t need enterprise-level support and can rely on community-driven support and updates.
Compliance with open-source licensing is important to you or your organization.

When to Choose Oracle JDK?

Oracle JDK is better suited for:

Enterprises that require commercial support, regular updates, and advanced features tailored for large-scale production environments.
Organizations that rely on service-level agreements (SLAs) for support and require faster issue resolution.
Projects with specific performance needs, where access to Oracle’s enterprise-grade performance enhancements is critical.
Companies that require legal assurances and compliance guarantees in the form of a paid license.

Conclusion

In summary, OpenJDK and Oracle JDK are functionally equivalent, as they both stem from the same code base. However, the decision to choose between them boils down to your specific needs:

OpenJDK offers a free, open-source solution, ideal for individual developers and small projects.
Oracle JDK is geared towards enterprises that need commercial support, robust performance tuning, and advanced features—though it comes at a cost.

Ultimately, both JDKs are powerful tools that enable Java developers to build world-class applications. The choice depends on your project’s scale, budget, and support needs.

Stay Connected

Have any questions or need further insights into Java development? Feel free to reach out to me!

How to Install and Use NVM to Manage Multiple Node.js Versions

Guna SantoshDeep Srivastava — Sat, 12 Oct 2024 09:44:51 +0000

Introduction

Hi Tech Enthusiasts, Greetings!

Welcome to this step-by-step guide on using Node Version Manager (NVM) for Windows! If you’ve ever faced the challenge of managing multiple versions of Node.js across different projects, NVM is the tool you need. It simplifies the process, letting you easily switch between Node.js versions and keeping your development environment organized.

By the end of this article, you’ll be able to install NVM on Windows, use it to manage Node.js versions, and make your Node.js workflow much smoother.

Goal of the Article

In this article, we will cover:

What NVM is and why it’s important for Node.js development.
How to install NVM on Windows.
Essential NVM commands for managing Node.js versions.
Common use cases and tips for using NVM effectively.

Let’s dive in!

What is NVM and Why Use It?

Node Version Manager (NVM) is a tool that helps you manage multiple versions of Node.js on your system. As a developer, you may be working on projects that require different Node.js versions. Switching manually between these versions can be time-consuming and error-prone.

With NVM, you can:

Install and use multiple Node.js versions easily.
Switch between versions in seconds with a single command.
Set project-specific versions of Node.js using an .nvmrc file.

NVM eliminates the need for uninstalling and reinstalling Node.js each time a project requires a different version.

How to Install NVM on Windows

Installing NVM on Windows is straightforward, but it’s a bit different from the process on macOS or Linux. Here’s a step-by-step guide:

Download NVM for Windows
- Visit the official NVM for Windows GitHub releases page.
- Download the latest NVM-Setup.zip file.
- Extract the ZIP and run the nvm-setup.exe file to start the installation.
Complete the Installation
- Follow the prompts in the installer. It’s recommended to use the default install location (e.g., C:\Program Files\nodejs) unless you have a specific reason to change it.
Configure Your Environment
- After installation, open Command Prompt or PowerShell to verify that NVM is working by running:
```
 nvm version
```

If you see the NVM version printed, the installation was successful.

Basic NVM Commands for Windows

Now that NVM is installed, let’s look at the most useful commands you’ll need to manage Node.js versions on your machine.

Install a Specific Node.js Version

   nvm install 14.17.0

This command downloads and installs Node.js version 14.17.0 on your system. You can replace 14.17.0 with any version number you need.

Switch to a Different Node.js Version

   nvm use 14.17.0

This tells NVM to switch your active Node.js version to 14.17.0.

Set a Default Node.js Version If you want a specific version to always be used by default, run:

   nvm alias default 14.17.0

List Installed Node.js Versions

   nvm list

This command lists all the Node.js versions you’ve installed using NVM.

List All Available Node.js Versions To see all the versions of Node.js that you can install, use:

   nvm list available

Uninstall a Node.js Version If you no longer need a specific version of Node.js, remove it with:

   nvm uninstall 14.17.0

Managing Node.js Versions in Projects

One of the key benefits of NVM is that it allows you to specify Node.js versions for individual projects.

Using `.nvmrc` to Specify Node.js Version

To make sure a project always uses a specific Node.js version, create an .nvmrc file in the root directory of the project.

For example, if your project requires Node.js version 14.17.0, create an .nvmrc file with the following content:

14.17.0

Then, when you’re inside that project directory, simply run:

nvm use

NVM will automatically switch to the version specified in the .nvmrc file.

Common Use Cases

Switching Node.js Versions for Different Projects
If you’re working on multiple projects, each requiring a different Node.js version, use nvm use to switch between them seamlessly.
Testing Your Application Across Different Node.js Versions
NVM makes it easy to test your application’s compatibility with various Node.js versions. Simply switch versions using nvm use and run your tests.
Isolating Global Packages
Global npm packages are installed separately for each Node.js version. This means you can have different global packages for each version without worrying about conflicts.

Pro Tips for Using NVM on Windows

Speed Up Switching Between Versions You can use the nvm alias command to create shortcuts for switching to commonly used versions. For example:

  nvm alias lts 14.17.0

Now, you can switch to Node.js version 14.17.0 by simply running nvm use lts.

Install Node.js LTS Versions You can install the latest long-term support (LTS) version of Node.js by running:

  nvm install --lts

Handling Global npm Packages Keep in mind that global npm packages are installed per Node.js version. If you switch versions and notice a global package missing, you’ll need to reinstall it for that specific version.

Conclusion

Node Version Manager (NVM) is an essential tool for any Node.js developer, especially if you’re working with multiple projects or need to test code across different Node.js versions. With NVM, you can install, switch, and manage Node.js versions effortlessly, making your development process much smoother.

Now that you have NVM set up and running on Windows, you’re ready to manage Node.js versions like a pro. Start switching versions with ease, and ensure each of your projects is running in the right environment.

Stay Connected

If you have any questions or need further assistance with NVM, feel free to reach out! I’d love to hear your feedback or help you on your development journey.

Email : [gunasantosh4@gmail.com]
LinkedIn : Guna-Santosh
GitHub : Guna-Santosh

Thank you for reading, and happy coding with NVM!

DEV Community: Guna SantoshDeep Srivastava

Service-to-Service Communication in Microservices: What Every Developer Should Know

The thing that changes the moment you split a monolith

Synchronous communication: when you need the answer right now

Asynchronous communication: when you don't need the answer right now

The part beginners skip and seniors get burned by anyway

Finding each other in the first place

Quick decision guide

What I've actually seen go wrong in practice

AWS CodePipeline Tutorial: Deploy to EC2 with CodeCommit, CodeBuild & CodeDeploy

Before you start

Step 1: Confirm your CodeCommit repo exists

Step 2: Open CodePipeline and start a new pipeline

Step 3: Choose "Build custom pipeline"

Step 4: Configure the pipeline basics

Step 5: Add the source stage

Step 6: Setting up the CodeBuild stage

Step 7: Skip the test stage

Step 8: Setting up the CodeDeploy stage for EC2 deployment

Step 9: Review and create

A few things I'd flag for anyone doing this

Cursor Just Became Part of SpaceX — Here's What Developers Should Actually Watch For

What happened, quickly

The part that actually matters

What I'd actually keep an eye on

Where I land on this

angular

OpenJDK vs. Oracle JDK: Key Differences and When to Use Each

Introduction

Licensing: Open Source vs. Commercial

Development Model: Proprietary vs. Community-Driven

Functional Equivalence: Identical in Code Base

Key Differences: Support and Cost

When to Choose OpenJDK?

When to Choose Oracle JDK?

Conclusion

Stay Connected

How to Install and Use NVM to Manage Multiple Node.js Versions

Introduction

Goal of the Article

What is NVM and Why Use It?

How to Install NVM on Windows

Basic NVM Commands for Windows

Managing Node.js Versions in Projects

Using .nvmrc to Specify Node.js Version

Common Use Cases

Pro Tips for Using NVM on Windows

Conclusion

Stay Connected

Using `.nvmrc` to Specify Node.js Version