DEV Community: shravan jain

what's all this hype about "loop engineering"

shravan jain — Sun, 05 Jul 2026 09:20:33 +0000

Honestly it's not a new concept. this feature already existed in models before. problem was the models were just weak.

Looping only works if each attempt gets the agent closer to the correct solution. Earlier models weren't consistent enough for that. They often misunderstood feedback, repeated the same mistakes, or got stuck in an infinite loop. Instead of improving with each iteration, they frequently failed to make meaningful progress, eventually consuming large numbers of tokens without solving the problem.

The Context Window Limitation

Earlier language models had much smaller context windows. As the agent went through more iterations, the conversation history and reasoning gradually filled the available context. Once the context window was exceeded, older messages had to be dropped or compressed into summaries. As a result, the agent could forget previous failed attempts, lose important clues or reasoning, and sometimes repeat the same mistakes it had already made.

So what did modern models actually fix?

Bigger context windows Models can now hold way more of the conversation/history without forgetting, so the agent doesn't need to spin up a fresh session every few iterations. it can just keep looping with the full history of what failed and why.

modern models also got way more consistent earlier if you asked a model to fix the same bug 5 times you'd get 5 different half-baked answers, now it actually converges toward the real fix. and tool use got better too . Old models could write code but couldn't run it and read the actual error, now they call a test runner, see the real failure, and fix that exact thing which is literally what makes the "verify" step possible.

And then there's inference it is simply the process of a model generating an answer. like when you type "write a java binary search," the model reads your prompt, thinks, and generates code that whole process is inference. every time the model generates text, that's one inference. now here's the thing inference has gotten way faster and cheaper. running a loop means multiple inferences back to back (generate, verify, retry, repeat), and earlier that would've been slow and expensive enough that nobody did it casually. now it's cheap and fast enough to just run 10 iterations without thinking twice.

I tested this myself

instead of just reading, I tried the smallest version of this loop on a palindrome checker. first attempt used basic s == s[::-1] it worked on simple cases but failed on anything with spaces, punctuation, or mixed case, stuff like "A man a plan a canal Panama." fed that exact failure back in, nothing extra. second attempt cleaned the string first, then compared it passed.

two iterations, one test suite as the verify step. that's the entire loop generate → verify → retry → stop.

try it yourself with literally any model . Ask it to write something small, run it, let it fail on some edge case, copy that exact error and paste it back asking it to fix that specific thing, run it again. watch it fix itself.

that's the whole "loop" everyone's hyping except you're the one doing the looping manually. tools like claude code, openClaw etc just automate this exact cycle so nobody has to copy-paste errors back and forth themselves.

So, going back to my original doubt

why couldn't we just loop an agent till it solves the problem, back in 2022-23? turns out we could, technically. the loop itself was never the hard part it's a while loop.

what was actually hard, and what's finally solved now, is knowing when to stop. bigger context so it doesn't forget, consistency so each attempt gets closer instead of randomly different, real tool use so it can verify instead of guess.

so when people say "loop engineering," they're not describing some new AI capability. they're describing the fact that the boring infrastructure problems finally got solved, so a decade-old idea finally works.

WebSocket in Spring Boot, Explained Simply

shravan jain — Fri, 03 Jul 2026 14:00:09 +0000

What Problem Does WebSocket Solve?

My always go-to learning technique is asking "what problem does this solve?"

I think this is the best method to learn any new topic when we learn this way, we eventually get the curiosity to dig deeper into that topic and explore more.

So, what problem does WebSocket solve?

In a traditional website, if a client wants to get information from the server, the client sends an HTTP request asking for that specific thing. Upon receiving the request, the server processes it (this may include querying the database, performing business logic, etc.) and sends back an HTTP response containing the requested data along with an appropriate status code.

Here's the catch HTTP is stateless, meaning the server doesn't remember the previous request. So every single request must carry all the information the server needs to process it.

The Chat App Example

Imagine there are two users chatting with each other. Client 1 sends a message, and the server stores it. But the problem here is Client 2 currently cannot see the message. Instead, Client 2 has to keep sending requests at fixed intervals, asking "Do I have any new messages?" This technique of repeatedly sending requests to check for new data is called Polling.

Now imagine there are thousands of users online, all continuously sending requests just to check if there's a new message even when there isn't one. This puts unnecessary load on the server.

This is where WebSockets provide a much better solution.

What Is a WebSocket?

WebSockets are a different protocol that starts with an HTTP request. Once the connection is established, it remains open until either the client or the server closes it. Since the connection stays open, there's no need to create a new connection for every request.

Think of it like having a door between two houses. Once the door is unlocked and opened, both people can walk through it whenever they want, without having to knock every single time.

I won't go too deep into WebSockets because that's not the goal of this article we're here to build one with Spring Boot. If you're curious how WebSockets work behind the scenes, I'd recommend giving the WebSocket Handbook by Ably a read:

https://pages.ably.com/hubfs/the-websocket-handbook.pdf

With that out of the way, let's jump into the implementation.

Setting Up WebSocket in Spring Boot

Add the Dependency

Tbh, this is one of the best parts about using Spring Boot it handles most of the heavy lifting for us, so we don't have to implement the core WebSocket functionality from scratch.

<dependency>  
    <groupId>org.springframework.boot</groupId>  
    <artifactId>spring-boot-starter-websocket</artifactId>  
</dependency>

If you created your project using Spring Initializr, you can simply select the WebSocket dependency while creating the project. If you already have an existing project, just add this to your pom.xml and run mvn clean install (or let your IDE reload the Maven project).

What We're Building

For this tutorial, let's build a simple dashboard where multiple users can post something. The goal: once User 1 posts something, it should automatically reflect in User 2's browser without refreshing the page.

To make this work, we obviously need to set up WebSocket communication in our Spring Boot app. And that starts with configuration.

Why We Need a WebSocketConfig Class

By default, Spring Boot automatically configures REST APIs. That's why we can simply declare REST endpoints using annotations like @RequestMapping() or @GetMapping() without any additional setup when the application starts, Spring Boot starts the embedded Tomcat server and configures HTTP request handling automatically.

However, Spring does not know how we want to configure WebSockets. We need to specify things like the WebSocket endpoint, the message broker, and the destination prefixes ourselves. That's why we create a separate WebSocketConfig class. When the application starts, Spring scans this configuration class, recognizes that the application uses WebSockets, and sets up the WebSocket infrastructure based on the settings we provide.

Here's what that class looks like:


@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws")
                .setAllowedOriginPatterns("http://localhost:5173")
                .withSockJS(); 
            // .withSockJS() is for compatibility , if the browser doesn't support web socket,
               // then roll back to default polling or streaming method .
    }

    @Override
    public void configureMessageBroker(MessageBrokerRegistry registry) {
        registry.enableSimpleBroker("/topic");
        registry.setApplicationDestinationPrefixes("/app");
    }
}

What is registerStompEndpoints()?

This method is used to define the endpoint for WebSocket communication. But you might wonder "why do we need a separate endpoint for WebSockets?", Why can't we just use @RequestMapping like we do for REST APIs?

The reason is simple. @RequestMapping is designed only for HTTP which is a request-response protocol. The client asks, the server answers, and the connection closes. That's it. It's one-directional per request.

WebSockets are different. Once the connection is established, both the client and the server can send messages to each other at any time without waiting for a request. That's bi-directional communication and HTTP simply wasn't designed for that. So we need a separate endpoint that upgrades the HTTP connection into a WebSocket connection.

You might also wonder about the registry argument this method receives — it's of type StompEndpointRegistry. Here's what's happening behind the scenes: when Spring starts up, it sees the @EnableWebSocketMessageBroker annotation, builds the entire WebSocket infrastructure internally, and then passes that registry object into your method. Think of it like Spring handing you a blank blueprint and saying "here, fill in the details." You then use methods like addEndpoint() to define where clients can connect — building the configuration piece by piece. That's exactly what registerStompEndpoints() does it tells Spring "this is the URL where clients can connect to open a WebSocket connection."

What is `configureMessageBroker()`?

Now that we've defined where clients connect, we need to tell Spring how to route messages once they're inside. That's exactly what configureMessageBroker() does.

Think of it like a post office. When a message arrives, the post office needs rules which messages go where, and how to deliver them. configureMessageBroker() defines those rules.

Similar to registerStompEndpoints(), Spring builds the MessageBrokerRegistry internally and hands it to you same idea, you just fill in the details.

Now let's look at the two lines inside:

registry.enableSimpleBroker("/topic");

This enables Spring's built-in message broker and tells it to handle any destination that starts with /topic. Think of /topic/activities like a YouTube channel any client can subscribe to it, and whenever a message is sent to that channel, all subscribers receive it instantly.

registry.setApplicationDestinationPrefixes("/app");

This defines the prefix for messages that are sent FROM the client TO the server. So if a client sends a message to /app/activity, Spring knows to route it to a controller method annotated with @MessageMapping("/activity"). Without this prefix, Spring wouldn't know whether an incoming message is meant for the broker or for your controller.

In short /topic is for server-to-client delivery, /app is for client-to-server routing.

What is STOMP?

We already know what WebSockets do they maintain a persistent connection between the client and the server, allowing both sides to send data to each other at any time.

But raw WebSockets are just an open pipe. You can put anything in that pipe there's no structure, no rules, no way to say "this message goes to this person" or "this is a chat message vs a notification." It's just raw data flying back and forth.

That's where STOMP (Simple Text Oriented Messaging Protocol) comes in. STOMP works on top of WebSockets and adds structure to the flow of data. It introduces three simple concepts:

Destinations — like addresses, e.g. /topic/activities
Subscribe — a client says "I want messages sent to this destination"
Send — the server or client pushes a message to a destination

Think of it like this WebSocket is the road, STOMP is the traffic rules. Without traffic rules, cars go everywhere and crash into each other. With rules, everyone knows where to go.

In Spring Boot, when you use @EnableWebSocketMessageBroker, you're enabling STOMP support on top of WebSockets. That's why your endpoints and broker configuration use STOMP concepts like destinations and prefixes.

Broadcasting from the Server `SimpMessagingTemplate`

Okay so we've set up WebSockets, configured STOMP, defined our endpoints and broker. But here's the question how does our Spring controller actually push a message to all the connected clients? Like who does the actual sending?

That's where SimpMessagingTemplate comes in.

Spring gives you this object out of the box you don't need to create it, you don't need to configure it. Just autowire it like any other bean and it's ready to use.

@Autowired
private SimpMessagingTemplate smt;

Now whenever you want to push something to all subscribers, you just call one method:

smt.convertAndSend("/topic/activities", savedActivity);

That's it. One line. Here's what it does under the hood:

Takes your Java object (savedActivity)
Converts it to JSON automatically
Pushes it to everyone currently subscribed to /topic/activities

Now let's see it in context. Here's what the full controller method looks like:

@PostMapping
public Activity insertActivity(@RequestBody Activity activity) {
    Activity savedActivity = activityRepository.save(activity);
    smt.convertAndSend("/topic/activities", savedActivity);
    return savedActivity;
}

Two things are happening here. First, the activity gets saved to the database. Second, that same activity gets broadcast to all connected clients instantly over WebSocket. The person who made the POST request gets a normal HTTP response back. Everyone else watching the dashboard gets it pushed to them in real time.

Testing It The HTML Client

So after configuring everything, let's look at how we can test it. Just a heads up I'm not really focused on JS or frontend right now, so I won't go deep into how this code works internally. I know it at a high level, and that's good enough for this test.

<!DOCTYPE html>
<html>
<head>
<title>WebSocket Test</title>
<script src="https://cdn.jsdelivr.net/npm/sockjs-client@1/dist/sockjs.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/stompjs@2.3.3/lib/stomp.min.js"></script>
</head>
<body>
<h2>WebSocket Test</h2>
<div id="messages"></div>
<script>
var socket = new SockJS('http://localhost:8080/ws');
var stompClient = Stomp.over(socket);
stompClient.connect({}, function(frame) {
    console.log('Connected: ' + frame);
    stompClient.subscribe('/topic/activities', function(message) {
        document.getElementById('messages').innerHTML += '<p>' + message.body + '</p>';
    });
});
</script>
</body>
</html>

This is just a small HTML page that connects to our /ws endpoint, subscribes to /topic/activities, and displays whatever comes through. That's it nothing fancy, just enough to prove the WebSocket connection actually works end to end.

The test:

Open this HTML file in the browser.
Hit the POST /activity endpoint with some activity data.
Watch the page the new activity shows up instantly, no refresh needed.

That confirms the full flow save to DB, broadcast over WebSocket, client receives it live.

Conclusion

And that's it that's a full WebSocket setup with Spring Boot, from the problem it solves all the way to seeing it work live in the browser.

To recap what we built: we configured a WebSocket endpoint, set up STOMP for structured messaging, used SimpMessagingTemplate to broadcast from the server, and tested it with a simple HTML client all to get one thing working: when User 1 posts something, User 2 sees it instantly, without refreshing.

This is the exact same foundation used for things like chat apps, live notifications, live dashboards, and real-time tracking apps so once you're comfortable with this, you can build a lot on top of it.

Monitoring a Server with Prometheus and Grafana: A Beginner’s Guide

shravan jain — Fri, 23 May 2025 08:52:46 +0000

Monitoring a website is super important for developers. It helps you figure out what’s causing issues like why your website is down, why requests are taking too long, or what might be slowing things down in general.

That’s where Prometheus and Grafana come in.

Prometheus is used to collect metrics from endpoints that you define (like your server or apps).
Grafana takes those metrics from Prometheus and turns them into easy-to-understand graphs and dashboards, so you can actually see what’s going on behind the scenes.

What This Guide Covers and Prerequisites

This guide is intended for beginners who want to learn the basics of setting up Prometheus and Grafana for monitoring their website.
I'll cover how to write a YAML configuration file for the Prometheus server, how to containerize it using Docker, and how to pull the Grafana image and use its dashboard.
Prerequisites

Basic knowledge of Linux/command line

Docker (for containerization)

Basic understanding of YAML

Familiarity with any backend language (I'm using Flask in this guide)

Setting Up Prometheus

Creating an flask server

from flask import Flask
from prometheus_flask_exporter import PrometheusMetrics

app = Flask(__name__)
metrics=PrometheusMetrics(app)
@app.route('/')
def test():
    return "hello world"

if __name__ == '__main__':
    app.run(host='0.0.0.0',debug=True)

In the above program, I have created a PrometheusMetrics instance and passed the app object as an argument.
This automatically sets up an endpoint (/metrics) that exposes application metrics, which Prometheus can scrape.

Now, if you open the website and go to endpoint /metrics you would now see this.

if you find any problem or get error 404 turn off the debug mode or run export DEBUG_METRICS=1 then run the application.

prometheus server
- Create a prometheus-config.yml to put the prometheus configuration.

 global:
  scrape_interval: 4s # it'll scrape the metrics from the end point every 4s

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["<you-target-address>"] # put you private address here to make that as your end-point

creating a docker container for prometheus server

version: "3"

services:
  prom-server:
    image: prom/prometheus
    ports:
      - 9090:9090
    volumes:
      - ./prometheus-config.yml:/etc/prometheus/prometheus.yml

This container pulls the prom/prometheus image and listens on port 9090 on my machine (host), forwarding it to port 9090 inside the container. It uses Docker volumes to bind ./prometheus-config.yml (on the host) to /etc/prometheus/prometheus.yml (inside the container), so any changes made to the config file on the host will be reflected in the container at runtime.

Summary of Prometheus Setup

I created a Flask app and used PrometheusMetrics to integrate Prometheus with it by passing the Flask app instance. This setup automatically exposed a /metrics endpoint, where all the raw data is available. Then, I used a Prometheus Docker container and specified a prometheus.yml file inside it to define which address to scrape the metrics from. Now, Prometheus collects the metrics from my Flask app and stores the data so it can be used for monitoring and visualization.

Setting Up Grafana

Setting up Grafana is simple — just run it in a Docker container:
docker run -d -p 3000:3000 --name=grafana grafana/grafana-oss
There are two versions of Grafana:

Grafana OSS (Open Source Software) — free and open to use (this is the one we’re using)

Grafana Enterprise — has extra features for businesses

After running the container, open your browser and go to:
http://localhost:3000
You’ll see the Grafana login page. Use the default credentials:

Username: admin

Password: admin

Grafana will ask you to set a new password — choose anything you like.
Connect Grafana to Prometheus

Once you’re logged in:

Click on “Add your first data source”

Choose Prometheus

In the URL box, enter the address of your Prometheus server, for example:

For example, if your Prometheus server is running at 172.20.54.207 on port 5000, enter:
http://172.20.54.207:5000

Scroll down and click “Save & Test”
You should see a green success message that says Grafana is connected to Prometheus.

That’s it — you're all set!

Here's what the raw metrics look like in Prometheus. Grafana takes this data and turns it into easy-to-understand visual dashboards.

Write Less, Reuse More: Template Inheritance in Flask Explained

shravan jain — Sat, 17 May 2025 07:57:15 +0000

This turned out to be a pretty cool concept. While working on my site monitoring app, I had around three or four services like uptime checks, DNS lookups, pinging, and a few others. Since I’m not much of a UI designer, I ended up creating separate files for each service, even though they all shared the same layout.

That’s when I discovered Flask’s template inheritance. Instead of repeating the same code over and over, you can create a base layout and reuse it wherever you want. It really helped clean things up and made everything way easier to manage. Here’s how you can set it up.

Inheriting from base to child:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>template-inheritance</title>
</head>
<body>
    <header>
        <nav>
            <ul>
                <a href="home">home</a>
                <a href="about">about</a>
                <a href="contact">contact</a>
            </ul>
        </nav>
    </header>
    <main>
        {% block content %}{% endblock %}
    </main>
    <footer>
        &copy; 2025 My Site
    </footer>
</body>
</html>

Simply put, if you want to use the same template like reusing the same navigation bar across multiple pages, you can just extend the base file. The whole layout gets reused automatically.

And if you want to change something specific on a page, you define blocks in the base file that let you override those sections whenever you need to. For example, if you want to override content inside the tag, you would define a block like this in the base:

 <main>
      {% block content %}{% endblock %}
 </main>

Then, in your child template, you extend the base and override that block:

{% extends "base.html" %}

{% block content %}
<div class="content">
    hello world!!
</div>
{% endblock %}

That way, you get the shared layout and can customize parts of the page without repeating your code.

Mastering Flask Blueprints: The First Step to Scalable Web Apps

shravan jain — Thu, 15 May 2025 16:08:37 +0000

As I started learning Flask, I was building simple apps just to understand the basics and get comfortable with it. Once I felt a bit more confident, I decided to start a project, a site monitoring tool. Since I knew the project would grow and include more functionality, I realized that things should be organized better. That’s when I came across Flask Blueprints. A Blueprint is a modular way to organize code and routes into separate components. Today, I set up my first Blueprint in Flask and here’s how it went.

Project structure

blueprint-example/
├── run.py
└── app/
    └── routes.py
    └── __init__.py
    └── templates/
        └── index.html

Step 1: Creating a simple Blueprint

from flask import Blueprint,render_template
#creating a flask blueprint called 'main_route'
main_route=Blueprint('main_route',__name__)
#define a route on this blueprint
@main_route.route('/')
def blue_example():
    return render_template('index.html')

Step 2: Register the blueprint

from flask import Flask

app=Flask(__name__)

def blue_example():
    from .routes import main_route
    app.register_blueprint(main_route)#registering my blueprint to my flask app instance
    return app

Step 3: Run the app

from app import blue_example

app=blue_example()#Calling a function to get flask app instance

if __name__ == '__main__':
    app.run(debug=True) #run the app in debug mode

What i found use full?

I basically had an idea of how this works because I had learned about MVC (Model, View, and Controller) in Java. The working process of both is quite similar, so I was able to grasp it a bit quicker.

Here are a few things I found helpful about using Blueprints:

It's a clean way to split the code logically. For example, separating routes and the dashboard into components makes the structure much easier to work with.
It's much easier to manage as the app grows and more features are added.
It makes the project more organized and scalable, which is especially useful when working in teams or revisiting the project later.

My Journey into Python and DevOps Begins

shravan jain — Wed, 14 May 2025 14:46:38 +0000

Hey everyone! 👋

I'm Shravan Jain, a student who recently found a niche in coding.

I’ve always been fascinated by the terminal. That childhood excitement of using a black screen with white text never really left me. Over time, I started exploring fun and nerdy things—like configuring servers in Cisco Packet Tracer and tweaking Firefox CSS just to see what I could do.

For a while, I was doing these small, non-productive (but oddly satisfying) things that sparked my curiosity. But now, I’ve decided to channel that curiosity into something more focused and practical.

I’ve started learning Python scripting to automate tasks and understand how things work behind the scenes. I'm drawn to Python because of how versatile it is—it's like a multitool for developers. Whether it's scripting, automation, DevOps, or backend systems, Python is everywhere.

This is my first step into something more structured and skill-driven, and I'm excited to share what I learn along the way!

Thanks for reading, and feel free to connect if you're also on a similar journey. 🙌

Python #DevOps #StudentDev #LearningJourney #Automation