DEV Community: Guna SantoshDeep Srivastava

HTTP Got a New Method After 16 Years — Meet QUERY (RFC 10008)

Guna SantoshDeep Srivastava — Thu, 16 Jul 2026 06:49:39 +0000

Quick trivia: before this year, the last time HTTP got a brand-new method was PATCH, back in 2010. That's a 16-year gap. In June 2026, that gap finally closed — the IETF published RFC 10008, officially adding a new method to HTTP: QUERY.

If you've ever needed to send a complex search or filter to an API and had to awkwardly choose between a messy GET URL or a POST that doesn't quite feel right, this method exists because of exactly that problem.

The problem QUERY is solving

For as long as HTTP has existed, reading data with parameters has meant picking between two imperfect options:

GET is safe, repeatable, and cacheable — but everything has to go in the URL. There's no guaranteed size limit (the spec only recommends a floor of 8000 characters), and complex data like nested filters or JSON just doesn't fit cleanly into a URL string. URLs also get logged far more often than request bodies, which is a real problem if your "search" contains anything sensitive.
POST can carry a full body, so complex data is easy to send — but nothing about POST tells a cache, proxy, or browser "this is just a read, nothing is changing." POST is treated as unsafe and non-repeatable by default, even when all you're doing is running a search.

QUERY is built to close that exact gap.

What QUERY actually is

Per the RFC itself, QUERY behaves like POST in form — it carries a full request body — but comes with the same reliability guarantees as GET:

Method	Has a body	Safe	Idempotent	Cacheable
GET	No	Yes	Yes	Yes
POST	Yes	No	No	Only in specific cases
QUERY	Yes	Yes	Yes	Yes

Safe means the client isn't asking to change anything on the server.
Idempotent means sending the same request twice has the same effect as sending it once — safe to retry.
Cacheable means a response can be reused for an identical request instead of hitting the server again.

Here's why those three properties aren't just theory — a concrete example of what actually breaks without them:

Say your app's network drops mid-request, and your HTTP client automatically retries. If that request was a POST, the client genuinely doesn't know whether the first attempt actually reached the server before the connection dropped. Retry, and you might run the same search twice — harmless for a search, but the exact same mechanism is why "retry on POST" is dangerous for something like a payment. The protocol gives the client no safe way to know it's okay to just try again.

If that same request had been a QUERY, the retry is a non-issue by definition — QUERY is idempotent, so running it twice has to produce the same result as running it once. Your HTTP client, your load balancer, and any proxy in between can all retry it automatically without asking anyone.

The caching angle plays out the same way: a CDN sitting in front of your API can cache a QUERY response and serve it instantly to the next identical request, the same way it already does for GET. It can never safely do that for a POST, because nothing in POST's contract says the response represents a stable, reusable answer.

On the wire, a QUERY request looks like this:

QUERY /products HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "category": "shoes",
  "price": { "lt": 100 },
  "sort": "newest"
}

Same shape as a POST, but the server (and any cache or proxy in between) knows this is a read-only request, not a write.

Where this actually helps

Complex search and filter endpoints — anything where the query itself is too big or too structured to fit nicely in a URL.
GraphQL queries — GraphQL reads are already safe and idempotent by design, but sending them as GET often blows past URL length limits. QUERY is a natural fit.
Anything currently using POST just to work around GET's limits — a pattern that's extremely common, and one that always meant giving up caching and the "safe" guarantee just to send a bigger request.

What's not ready yet

This is a brand-new standard, and it's important to be honest about where adoption actually stands as of mid-2026:

Browser support is still being evaluated — don't build a public-facing web app around it just yet.
QUERY is not a CORS-safelisted method, so browser JavaScript calling it across origins needs a preflight request, same as PUT or DELETE.
Popular frameworks are still catching up — Node.js has supported parsing QUERY since early 2024 (ahead of the RFC itself), and OpenAPI 3.2 already documents it, but Spring hasn't shipped built-in support as of this writing.
Existing infrastructure is a real concern: WAFs, API gateways, CDNs, and CSRF middleware are often configured around a fixed list of methods — GET, POST, PUT, DELETE, PATCH. Rule sets written before June 2026 may not know QUERY exists, and might reject it, or worse, handle it inconsistently.
Caching QUERY correctly means the cache key has to include the request body, not just the URL. A cache that gets this wrong opens the door to serving the wrong response to the wrong request.

How a client actually discovers QUERY is supported

You can't just assume every endpoint accepts QUERY — the server has to say so first. It does this with a response header called Accept-Query, usually seen after an OPTIONS request:

OPTIONS /products HTTP/1.1
Host: example.com

HTTP/1.1 204 No Content
Allow: GET, POST, QUERY
Accept-Query: application/json

That Accept-Query: application/json line is the server telling any client: "yes, you can QUERY this endpoint, and send the body as JSON." Without it, a client has no reliable way to know whether QUERY will even be understood here — which is exactly why the gradual rollout (advertise it, then let clients adopt it) depends on this header existing in the first place.

How to actually roll this out

The sane path, based on what the RFC's authors themselves suggest, is gradual:

Keep your existing POST-based search endpoint working exactly as it is.
Add QUERY as a second way to reach the same endpoint.
Advertise support using the Accept-Query header, so clients can detect it.
Let clients migrate over to QUERY on their own timeline, instead of forcing a switch.

Nobody needs to rip out a working POST search endpoint tomorrow. This is a "start advertising it, let adoption happen naturally" kind of rollout, not a "migrate everything this sprint" one.

The one-line version

HTTP just got its first new method in 16 years. QUERY gives you a way to send a complex, structured request body — like POST — while keeping the safe, repeatable, cacheable guarantees of GET. It's real, it's an official standard, and it's genuinely useful — but browsers, frameworks, and infrastructure are all still catching up, so treat it as something to watch and start testing with, not something to depend on in production just yet.

Have you run into the "GET can't hold this much data, but POST doesn't feel safe to cache" problem yourself? That's exactly the itch QUERY is trying to scratch.

How AWS CodePipeline Works: A Real CI/CD Flow (Source, Build, Deploy)

Guna SantoshDeep Srivastava — Tue, 14 Jul 2026 13:59:23 +0000

I used CodePipeline for months without really understanding it: push code, stages turn green, app updates. That was fine until something broke and the console didn't explain why, and I got tired of just guessing. So I opened a terminal and traced my own pipeline step by step, using the AWS CLI — every file, every stage, every "why does this even exist." It turned out to be a lot more interesting than the console picture makes it look.

Here's what I found, with the real commands and the real output (with private details removed). If you've ever wondered what actually happens between "code pushed" and "app updated," this is it.

How the pipeline actually wakes up

First question: does CodePipeline keep checking CodeCommit for changes, or does something tell it the moment a change happens? I checked the pipeline settings to find out:

aws codepipeline get-pipeline --name my-app --profile my-profile --region us-west-2

"triggerType": "CloudWatchEvent",
"PollForSourceChanges": "false"

That answers it:

PollForSourceChanges: false means it's not checking on a timer.
A separate CloudWatch Events rule sits in the background, watching for pushes to that branch.
The moment a push happens, that rule starts the pipeline right away — not "sometime in the next minute or two."

What "Source" actually produces

Here's something I hadn't thought about before: the Source stage doesn't give Build a live link to your repo. It packs up a snapshot instead.

"configuration": {
    "BranchName": "qa",
    "OutputArtifactFormat": "CODE_ZIP",
    "RepositoryName": "my-app"
}

CODE_ZIP means CodePipeline takes the whole repo at that commit and turns it into one plain zip file.
No .git folder, no history — just the files as they were at that exact moment.
There's another option, CODEBUILD_CLONE_REF, that does a real git clone instead, in case your build ever needs actual git history.

Where that zip actually goes

Source, Build, and Deploy each run in their own separate, temporary space — they don't share files directly. So the zip needs one shared place to sit, and that's an S3 bucket that CodePipeline manages for the whole pipeline:

"artifactStore": {
    "type": "S3",
    "location": "codepipeline-us-west-2-<ACCOUNT_ID>"
}

This one bucket holds files for every stage of the pipeline — it's not tied to one specific file. The exact file name (the "key") is different every time the pipeline runs.

Proving the zip is real

I didn't want to just take this on faith, so I looked at the real file:

aws s3api head-object --bucket codepipeline-us-west-2-<ACCOUNT_ID> --key "my-app/SourceArti/<key>" --profile my-profile --region us-west-2

{
    "ContentLength": 98230361,
    "ContentType": "application/zip",
    "ServerSideEncryption": "aws:kms"
}

What this confirms:

A real zip file, about 98 MB — the whole repo, nothing left out.
Locked with KMS encryption while it sits in storage.
These files delete themselves after a set amount of time — they're not meant to stay forever, just handed off between stages and cleaned up afterward.

Finding the right artifact, not an old one

S3 doesn't know which file is "the latest one in this folder" — only CodePipeline actually keeps track of that. So if something's broken, don't just guess by browsing S3 folders. Ask the pipeline first:

aws codepipeline get-pipeline-state --name my-app --profile my-profile --region us-west-2

"currentRevision": { "revisionId": "<commit-hash>" },
"latestExecution": { "status": "Succeeded" },
"pipelineExecutionId": "<execution-id>"

currentRevision.revisionId is the real commit hash that was pulled. Copy that value, then use list-action-executions with the matching pipelineExecutionId to find the exact S3 file for that specific run.

Build: how it knows what to work on

Now, the Build stage. It doesn't just magically know where the code is — the pipeline settings tell it directly:

"configuration": {
    "ProjectName": "my-app"
},
"inputArtifacts": [{ "name": "SourceArtifact" }]

SourceArtifact is just a name tag. CodePipeline connects that name to the real bucket and file it just created in the Source stage — Build never has to know the real path itself.

What it actually runs on

"environment": {
    "type": "LINUX_CONTAINER",
    "image": "aws/codebuild/amazonlinux-x86_64-standard:6.0",
    "computeType": "BUILD_GENERAL1_MEDIUM"
},
"environmentVariables": [
    { "name": "PROFILE_NAME", "value": "qa" },
    { "name": "HOST_ENTRY",   "value": "<internal-host>:<internal-ip>" },
    { "name": "TAG_VERSION",  "value": "latest_qa" }
]

What happens every single build:

A brand-new Amazon Linux container is created — no leftover cache, nothing saved from the last run.
These environment variables (PROFILE_NAME, HOST_ENTRY, TAG_VERSION) are already set inside it for buildspec.yml to use.
Before any of your commands even run, CodeBuild automatically downloads and unzips SourceArtifact into the container's working folder.

That last point is why your pom.xml, source files, Dockerfile, and everything else are just "there" the moment the build starts — nobody has to unzip anything by hand.

Walking through the buildspec, step by step

install phase — sets up the runtime:

runtime-versions:
  java: corretto17

pre_build phase — logging in, before anything gets built:

- aws ecr get-login-password | docker login --username AWS --password-stdin <account-id>.dkr.ecr.us-west-2.amazonaws.com
- export CODEARTIFACT_AUTH_TOKEN=$(aws codeartifact get-authorization-token --domain my-codeartifact-domain ...)

Line 1 logs Docker into ECR using a password that only works for a short time. This is what makes the later docker push command actually work.
Line 2 gets a token so Maven can download private dependencies later, using settings.xml.
One tip: don't print env in a real pipeline. It's handy for debugging on your own computer, but it prints every environment variable — including ones you didn't mean to share — straight into build logs your whole team can read.

build phase — the actual compile:

- mvn -s settings.xml package -DskipTests=true

Compiles the Spring Boot project and packs it into a .jar file.

post_build phase — this is where it gets interesting:

- docker build -t my-app:${TAG_VERSION} .
- docker tag my-app:${TAG_VERSION} <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}
- docker push <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}

Line 1 builds the image inside the CodeBuild container.
Line 2 gives it a second label pointing at the ECR address.
Line 3 uploads it — this is the exact moment the image stops being "a temporary file that's about to disappear" and becomes a real, permanent file that sticks around.

Proof it landed:

aws ecr describe-images --repository-name my-app --profile my-profile --region us-west-2

{
    "imageDigest": "sha256:<digest>",
    "imagePushedAt": "2026-07-13T18:24:55+05:30"
}

The part that actually surprised me

Here's the one thing that made this whole exercise worth doing: Build creates two completely separate outputs, and they don't go to the same place.

The Docker image — the actual application, ~290 MB in my case — goes to ECR.
A tiny zip — just deploy scripts and a small deployment-env-vars file, about 2.35 KB total — goes to S3, in a folder CodePipeline labels BuildArtifact.

Laid out side by side, the size gap is what makes it click:

What	Goes where	Size
Docker image	Container registry (ECR)	~290 MB
Deploy scripts + tag reference	S3 (`BuildArtifact`)	~2-3 KB

These aren't two copies of the same thing — they're not even close in size. The small S3 zip only exists so CodePipeline can hand Deploy one simple instruction: "here's the image tag to go get from ECR." That's because CodePipeline can only pass files forward through S3, never directly through ECR. Your actual application never touches that small handoff file at all.

If you want to see this yourself: open S3, find your pipeline's artifact bucket, look inside the BuildArtifact folder, download the (tiny) zip, and unzip it locally. You'll find things like appspec.yml, a couple of shell scripts, and an imagedefinitions.json — nothing that looks like your actual application code, because it was never meant to be in there.

Stage 3 — Deploy

This is the part that made the whole "small zip vs. big image" split actually make sense to me. Deploy is different from Source and Build in one big way: it doesn't create a temporary container somewhere in AWS. It runs directly on your actual EC2 server, using the CodeDeploy agent that's already installed and running there.

The first thing the agent does is read appspec.yml — the file that was inside that tiny zip the whole time — to find out which script to run, and when:

version: 0.0
os: linux
hooks:
  ApplicationStop:
    - location: stop_container.sh
      timeout: 300
  AfterInstall:
    - location: start_container.sh
      timeout: 300

CodeDeploy always follows the same set order of steps on the server, and appspec.yml just connects your scripts to the steps you care about:

ApplicationStop → stop_container.sh — runs before anything new gets installed. Its job is simple: stop and remove whatever container is already running under this app's name, so the port is free and there's no clash when the new one starts.
AfterInstall → start_container.sh — this is where most of the real work happens. It's also where that deployment-env-vars file — the one that's been sitting quietly in the small zip since the Build stage — finally gets used.

Roughly, here's what start_container.sh does:

# read the image tag that Build decided on
source deployment-env-vars

# pull that exact image from ECR
docker pull <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}

# start it with the right port mapping, env vars, and volumes
docker run -d \
  --name my-app \
  -p 8080:8080 \
  --env-file app.env \
  -v /opt/my-app/logs:/app/logs \
  <account-id>.dkr.ecr.us-west-2.amazonaws.com/my-app:${TAG_VERSION}

And that's the moment everything comes together. Remember that "just instructions" file from the Build stage — the one that seemed too small to matter next to a 290 MB image? This is what it was for, the whole time:

It never carried any real weight itself.
It just told this script which tag to go get.
The image had already been sitting in ECR since the Build stage finished.
Deploy's only job is to tell the server to go grab it and run it.

It's a small thing, but it changed how I think about the whole pipeline: Source and Build are about creating files and putting them in the right place. Deploy isn't really "installing" anything in the usual sense — it's just giving the server one clear instruction and stepping out of the way.

The short version, if you just want the summary

Source starts the moment you push (no waiting, no timer), packs the exact commit into a zip with no git history, and drops it into a shared S3 bucket under a brand-new name every time.
Build picks that zip up on its own, compiles the code, and builds a Docker image.
Build's output splits in two: the real app goes to ECR, and a tiny instruction file goes to S3 just to tell Deploy which image tag to grab.
Deploy runs right on the EC2 server itself, reads that small file to find the right tag, stops whatever's currently running, pulls the new image from ECR, and starts it back up.

Have you ever traced your own pipeline's files like this, or do you just trust the console screen for it? I expected this to be boring, and instead I came out understanding what I'm actually running, much better than before.

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

HTTP Got a New Method After 16 Years — Meet QUERY (RFC 10008)

The problem QUERY is solving

What QUERY actually is

Where this actually helps

What's not ready yet

How a client actually discovers QUERY is supported

How to actually roll this out

The one-line version

How AWS CodePipeline Works: A Real CI/CD Flow (Source, Build, Deploy)

How the pipeline actually wakes up

What "Source" actually produces

Where that zip actually goes

Proving the zip is real

Finding the right artifact, not an old one

Build: how it knows what to work on

What it actually runs on

Walking through the buildspec, step by step

The part that actually surprised me

Stage 3 — Deploy

The short version, if you just want the summary

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