Forem

Multithreading

QuecPython — Fri, 17 Apr 2026 09:02:57 +0000

Overview

Multithreading is a technique that allows multiple threads to execute concurrently in software or hardware. In a program, multiple threads can execute simultaneously, each performing independent tasks. This allows the program to continue executing other tasks while one thread is blocked (e.g., I/O operations), improving the efficiency of the program.

The QuecPython thread module provides functions for creating and deleting threads, as well as interfaces for mutexes, semaphores, and other related operations. QuecPython also provides component modules such as queue, sysbus, and EventMesh to facilitate multithreaded business processing.

Implementation of Multithreading

QuecPython does not create thread resources itself. In QuecPython, one thread corresponds to one thread in the underlying RTOS system and relies on the underlying thread scheduling. So how does the underlying system schedule and execute multiple tasks?

Thread Creation

Python provides a convenient way to create threads, which ignores the configuration of underlying parameters such as stack size and priority, simplifying usage as much as possible. When creating a thread in Python, a task control block (TCB) is generated in the underlying RTOS system for task scheduling and thread resource control.

The default stack size for the protocol stack is 8k. QuecPython also provides the ability to configure the stack size, which can be queried and configured using the thread.stacksize() interface.

Thread States

A thread has its own lifecycle, from creation to termination, and is always in one of the following five states: creation, runnable, running, blocked, and dead.

Creation: The thread is created and initialized to the runnable state.

• Runnable: The thread is in the runnable pool, waiting for CPU usage.

• Running: The thread is running when it obtains CPU execution resources from the runnable state.

• Blocked: The running thread gives up CPU usage for some reason and enters the blocked state. The thread is suspended and does not execute until it enters the runnable state again. This blocking state can be caused by various reasons, such as sleep, semaphore, lock, etc.

• Dead: The thread enters the dead state when it completes execution or terminates abnormally.

Thread Scheduling Mechanism

The simultaneous execution of multiple threads is a false proposition. In reality, not all threads can run continuously and exclusively occupy the CPU, no matter how powerful the hardware resources are. For thousands of threads, a certain scheduling algorithm is needed to implement multithreading. So how is the scheduling mechanism of multithreading implemented?

In an RTOS system, common scheduling mechanisms include time-slice round-robin scheduling, priority-based cooperative scheduling, and preemptive scheduling. Generally, multiple scheduling algorithms are used in an RTOS system.

Time-Slice Round-Robin Scheduling

The round-robin scheduling strategy in RTOS allows multiple tasks to be assigned the same priority. The scheduler monitors task time based on the CPU clock. Tasks with the same priority are executed in the order they are assigned. When the time is up, even if the current task is not completed, the CPU time is passed to the next task. In the next allocated time slot, the task continues to execute from where it stopped.

As shown in the following figure, time is divided into time slices based on the CPU tick. After each time slice, the scheduler switches to the next task in the runnable state, and then executes tasks A, B, and C in order.

Priority-Based Cooperative Scheduling

Priority-based cooperative scheduling in RTOS is a non-preemptive scheduling method based on priorities. Tasks are sorted by priority and are event-driven. Once a running task completes or voluntarily gives up CPU usage, the highest priority task in the runnable state can obtain CPU usage.

As shown in the following figure, according to the priority task scheduling method, when executing task A, an interrupt event task occurs and the high-priority interrupt event task is executed immediately. After the high-priority interrupt completes or gives up the CPU, the scheduler switches to the higher priority task A. After the task A completes or gives up the CPU, the scheduler switches to the task B.

Preemptive Scheduling

RTOS ensures real-time performance through preemptive scheduling. In order to ensure task responsiveness, in preemptive scheduling, as long as a higher priority task becomes runnable, the currently running lower priority task will be switched out. Through preemption, the currently running task is forced to give up the CPU, even if the task is not completed.

As shown in the following figure, according to the preemptive scheduling method, when executing task A, a higher priority task C appears and immediately switches to task C. After the higher priority task C completes or gives up the CPU, the scheduler switches to the higher priority task B based on the current runnable state. After task B completes or gives up the CPU, task A is executed again.

Thread Context Switching

In actual multithreaded execution, multiple threads are kept running by constantly switching between them. So how does the thread scheduling and switching process work? How is the execution state restored after switching?

When the operating system needs to run other tasks, it first saves the contents of the registers related to the current task to the stack of the current task. Then, it retrieves the previously saved contents of all registers from the stack of the task to be loaded and loads them into the corresponding registers, so that the execution of the loaded task can continue. This process is called thread context switching.

Thread context switching incurs additional overhead, including the overhead of saving and restoring thread context information, the CPU time overhead for thread scheduling, and the CPU cache invalidation overhead.

Thread Cleanup

A thread is the smallest scheduling unit of the system, and the creation and release of system threads require corresponding resource creation and cleanup.

To simplify the usage for customers, QuecPython automatically releases thread resources after the thread finishes running, so customers do not need to worry about thread resource cleanup. If you need to control the closure of a thread by another thread, you can use the thread.stopthread(thread_id) interface to control the specified thread based on the thread ID.

By using thread.stopthread(thread_id) to forcefully close a thread and release thread resources, you need to pay attention to whether the corresponding thread has locks, memory allocations, and other related operations that need to be released by the user to prevent deadlocks or memory leaks.

QuecPython Multithreading

QuecPython multithreading relies on the underlying system’s scheduling method and adds GIL lock to implement multithreading.

Python is an interpreted language, and for multithreading processing, it needs to be executed in order to ensure that only one thread is executing at the same time in the process. Therefore, the concept of GIL global lock is introduced to prevent shared resource exceptions caused by multithreading conditions.

QuecPython threads define the main thread, Python sub-threads, and interrupt/callback threads on the basis of the system and fix their priorities. The priority of the main thread (repl interactive thread) is lower than that of Python sub-threads, and the priority of Python sub-threads is lower than that of interrupt/callback threads.

The QuecPython multithreading switching process is shown in the figure below, when executing task A, after releasing the GIL lock of task A, switch to the higher priority interrupt task C. After the high-priority task C releases the GIL lock, execute the higher-priority task B and acquire the GIL lock. After the task B releases the GIL lock, continue to execute task A. QuecPython avoids the GIL lock causing high-priority tasks to be unable to execute and has flexibility in multithreading scheduling. It will automatically release the GIL lock after a certain number of executions and be scheduled by the system.

Inter-thread Communication amp; Resource Sharing

Inter-thread communication refers to the techniques or methods used to transmit data or signals between at least two processes or threads. In multithreading, inter-thread communication is essential for controlling thread execution, resource sharing control, message passing, etc., to achieve program diversification.

Common Issues

1. Thread Creation Failure

In most cases, thread creation fails due to insufficient memory. You can use thread.getheap_size() to check the current memory size and adjust the thread stack space to minimize memory consumption. However, the stack space should still meet the usage requirements to avoid crashes.

2. How to Release Thread Resources to Prevent Memory Leaks

Threads can be terminated in two ways. You can use the thread.threadstop(thread_id) interface to interrupt the program externally. Alternatively, threads can automatically exit when they finish running, and the system will reclaim the thread resources.

3. Thread Deadlock Issues

Deadlock occurs when multiple threads are waiting for each other to release system resources, resulting in a deadlock when neither side exits first.

To prevent deadlocks, make sure that thread locks are used in pairs and avoid situations where locks are nested. Use thread.threadstop(thread_id) with caution to prevent deadlocks caused by program termination during the locking process.

4. How to Wake Up Blocked Threads

For threads that need to be blocked, you can use inter-thread communication to wake them up. Avoid using sleep or other methods that cannot be interrupted.

5. Thread Priority

QuecPython has fixed priorities: the main thread (REPL interactive thread) has the lowest priority, followed by Python sub-threads, and then interrupts/callback threads. User-created Python sub-threads have the same priority.

6. How to Keep Threads Alive

QuecPython currently does not provide daemon threads or thread status query interfaces. If you need to keep a thread alive, you can implement a custom mechanism. For example, you can count the usage of the thread that needs to be kept alive and ensure that the thread performs a certain action within a certain period of time. If the action is not completed, the thread is cleared and recreated.

7. Thread Infinite Loop

QuecPython is compatible with multiple platforms, and an infinite loop in a thread may prevent the program from running or cause a system watchdog timeout and crash.

8. Thread Stack Exhaustion

QuecPython has different default thread stack sizes on different platforms, typically 2KB or 8KB. When the thread workload is large, stack overflow may occur, leading to unpredictable crashes. Therefore, consider whether the default stack size meets the requirements and use the thread.threadsize() interface to check and set the stack size.

9. Thread Safety

Thread safety is a concept in computer program code for multithreading. In a program with multiple threads that share data, thread-safe code ensures that each thread can execute correctly and accurately through synchronization mechanisms, without data corruption or other unexpected issues. We support mutex locks, semaphores, and other methods for data protection. When sharing data in multiple threads, users can use these methods as needed.

10. Comparison of Interrupts, Callbacks, Python Sub-threads, and the Main Thread (REPL Interactive Thread) Priority

Interrupts/callbacks depend on their triggering threads, and different interrupts/callbacks have different trigger objects, so their priorities cannot be determined.

Main thread (REPL interactive thread) priority < Python sub-thread priority < Interrupt/callback thread priority.

11. Whether The Time Slice Round-Robin Scheduling is Supported for Threads with the Same Priority.

Time slice round-robin scheduling is supported, but it is limited. Due to the Python Global Interpreter Lock (GIL) mechanism, after a thread is scheduled, it acquires the GIL lock. Only when the GIL lock is available can the thread execute successfully. Other threads can only be executed when the Python thread finishes or releases the GIL lock.

12. Whether The Thread Priority Configuration is Support.

Thread priority configuration is not supported.

Claude Opus 4.7: The Good, The Weird, and The Why Your Prompts Just Broke

Vishnu Damwala — Fri, 17 Apr 2026 09:01:16 +0000

Claude Opus 4.7: What Actually Matters for Developers

Anthropic dropped Claude Opus 4.7 and—plot twist—they admitted it's not their best work. The real beast, Claude Mythos, is locked behind a waitlist because it's "too capable at cybersecurity." Everyone else gets the "safe" version.

Here's what actually matters for developers.

SWE-bench Pro: 64.3% — Up from 53.4%. The gap between 4.6 and 4.7 is bigger than the gap between 4.6 and GPT-5.4 combined.
Vision: 2,576px — Triple the resolution. Your blurry 2 AM screenshots finally make sense.
Prompts are dead — "Make it better" does nothing. 4.7 needs a spec, not vibes.
Same price, more tokens — Tokenizer uses 0-35% more tokens. Your bill will go up.
Cyber capabilities locked — Pentesters need to apply for access. The model refuses security exploits by default.

The Only Benchmark That Matters

Model	SWE-bench Pro	SWE-bench Verified
Claude Opus 4.7	64.3%	87.6%
GPT-5.4	57.7%	—
Gemini 3.1 Pro	54.2%	80.6%
Claude Opus 4.6	53.4%	80.8%

SWE-bench isn't abstract—it's real GitHub issues from Django, scikit-learn, and matplotlib. The model has to understand a codebase, find bugs, write fixes, and verify they work. This is the "can this actually help me ship code" benchmark.

The 10.9 point jump from 4.6 to 4.7 means fewer "please try again" moments at 2 AM.

Can It Actually Code For Hours Without You Watching?

This is the main event. 4.7 claims 14% improvement in multi-step agentic tasks with one-third the tool errors. It coordinates multiple workstreams in parallel and passes "implicit-need tests" where it figures out what tools it needs without you explicitly telling it.

The scenario: It's 11 PM. You've been avoiding refactoring your auth system for three months because it's 200+ files of spaghetti. You fire up Claude Code with Opus 4.7, describe what you want, and go to bed.

With 4.6, you'd wake up to a half-finished disaster or subtle bugs that'd hit production at the worst moment. With 4.7, it sustains focus across the entire codebase, coordinates changes across multiple files, catches its own mistakes, and keeps going through tool failures that would have stopped 4.6 dead.

I tested a 4-hour session. It held coherent context the entire time. The degradation that used to happen? Gone.

Vision That Actually Works

Previous Claude models capped at 1,568 pixels (~1.15MP). Opus 4.7 handles 2,576 pixels / 3.75 megapixels. That's dense enough to read fine print in diagrams and extract data from complex charts.

The scenario: It's 2 AM. Production is on fire. Your error logs are a wall of red text across three monitors. You screenshot the chaos, paste it to Claude, and pray.

At 4.6's resolution, it might miss the critical line buried in the noise—the database timeout causing the cascade, not the prominent auth errors. At 4.7's resolution, it reads dense screenshots properly, identifies the actual root cause, and tells you exactly which config to change.

Bonus: coordinate mapping is now 1:1 with actual pixels. No more scale-factor math for UI automation.

Your Prompts Are Broken

4.7 is substantially more literal. Prompts that relied on "filling in the blanks" will produce unexpected or minimal results.

Before (4.6):

"Make this function better"

After (4.7):

"Refactor this function to handle null inputs, add error logging, 
and ensure it returns a consistent type. The function currently 
crashes on line 47 when user.email is undefined."

Budget time to re-tune your prompt library before migrating production systems.

Breaking Changes

Extended Thinking Budgets Are Gone — The thinking: {"type": "enabled", "budget_tokens": N} pattern returns a 400 error. Use thinking: {"type": "adaptive"} with output_config: {"effort": "high"} instead.
Sampling Parameters Are Gone — Setting temperature, top_p, or top_k to non-default values returns a 400 error. Remove them and use prompting to guide behavior.
Thinking Content Is Hidden By Default — The model still thinks, but you won't see the reasoning stream unless you opt in with thinking: {"type": "adaptive", "display": "summarized"}.

Should You Upgrade?

Yes if: You do long-running coding tasks, vision-heavy work, or complex agentic workflows. The SWE-bench jump translates to shipping code instead of debugging why the model hallucinated an API.

No if: You're happy with 4.6 for simple chat—you won't notice much difference.

Pricing: Same per-token price ($5/$25 per million), but the new tokenizer means 0-35% more tokens. Monitor usage after migration.

→ Read the full deep-dive with code examples, AWS Bedrock setup, and detailed FAQ

Originally published on MeshWorld India.

The NDC Revolution and What It Means for Data Engineers in Travel Tech

Martin Tuncaydin — Fri, 17 Apr 2026 09:01:02 +0000

The NDC Revolution and What It Means for Data Engineers

The airline industry is in the midst of its most significant distribution transformation in decades, and most data engineers working in travel tech are only beginning to grasp the magnitude of the shift. IATA's New Distribution Capability (NDC) standard isn't just another API specification—it's a fundamental reimagining of how airline products move from inventory systems to customer screens and it's creating challenges and opportunities that will reshape our discipline for years to come.

I've spent the better part of the last five years watching this transformation unfold, and I can tell you that the technical debt accumulated from decades of GDS-centric distribution is now coming due. The question isn't whether your data infrastructure can handle NDC; it's whether you're ready to rebuild large portions of it from the ground up.

From PNR to Offer: A Paradigm Shift in Data Modelling

The traditional airline distribution model centred on the Passenger Name Record—a flat, text-based format that evolved from the teletype era. Every data engineer who's parsed EDIFACT messages or wrangled Amadeus cryptic entries knows the pain of extracting structured information from what is essentially a formatted string with decades of accumulated quirks.

NDC replaces this with an offer and order model built on modern XML schemas. An offer represents a specific combination of flights, ancillaries, and pricing valid for a limited time. An order represents a confirmed purchase with all its associated services and fulfilment obligations. This sounds straightforward until you realise that a single shopping request might generate hundreds of dynamic offers, each with its own validity window, and that these offers don't correspond to traditional fare classes or booking codes.

I've had to completely rethink how we model availability in data warehouses. The old approach of storing fare classes, booking codes, and inventory counts doesn't map cleanly to a world where pricing is algorithmically generated in response to specific shopping requests. You're no longer dealing with relatively static fare tables that change a few times per day; you're dealing with ephemeral offers that exist only in the context of a specific shopping session.

The schema complexity alone is substantial. An NDC OrderViewRS response can contain nested structures for travellers, service associations, payment information, and fulfilment statuses that require careful normalisation. I've found that graph database patterns often make more sense than traditional relational schemas for representing the relationships between offers, orders, service definitions, and traveller profiles.

The API-First Reality and Its Infrastructure Demands

NDC is fundamentally an API-first standard, which means the asynchronous, message-based patterns that dominated GDS integration are giving way to synchronous REST and SOAP interactions. This shift has profound implications for how we architect data pipelines.

Traditional airline distribution relied heavily on queue processing—reservations were created, modified, and cancelled through queue messages that could be processed in batch. NDC shopping and ordering happen in real-time API calls with strict response time requirements. If your infrastructure can't return a shopping response in under two seconds, you've lost the customer.

I've learned that the data engineering challenges here extend far beyond simply calling APIs. You need sophisticated caching layers to avoid redundant shopping requests, circuit breakers to handle airline API failures gracefully, and rate limiting to manage quota consumption across multiple airline partners. The observability requirements are also completely different—you can't wait for batch job logs to investigate issues when every millisecond of API latency affects conversion.

The volume characteristics change dramatically as well. A single customer shopping session might generate dozens of API calls as they refine search parameters, compare options, and explore ancillary services. Each call produces detailed offer data that needs to be captured for analytics, even though most offers will never be purchased. I've seen shopping-to-booking ratios of 100:1 or higher, which means your data infrastructure needs to handle two orders of magnitude more traffic than your actual transaction volume would suggest.

Ancillary Services and the Unbundling Problem

One of NDC's core promises is rich merchandising of ancillary services—seats, bags, meals, lounge access, and increasingly creative product bundles. For data engineers, this unbundling creates a many-to-many relationship problem that legacy systems were never designed to handle.

In the GDS world, ancillaries were often bolted on as special service requests or stored as cryptic codes in free-text fields. NDC makes ancillaries first-class entities with their own pricing, availability, and fulfilment rules. A single order might contain base fares for three passengers, each with different cabin selections, baggage allowances, meal preferences, and entertainment packages.

I've found that modelling this effectively requires treating services as independent entities that can be associated with specific travellers and flight segments through a flexible association layer. And the challenge is that these associations have their own business rules—certain ancillaries are only valid in combination with specific fare families, some have dependencies on traveller status or frequent flyer tier, and others have complex rebooking or refund policies that differ from the base fare.

The analytics implications are equally complex. Traditional metrics like average fare or load factor become less meaningful when significant revenue comes from unbundled services. I've had to develop new frameworks for measuring ancillary attachment rates, bundle take-up, and service-level profitability that account for the dynamic nature of NDC offers.

The Schema Versioning Nightmare

IATA releases new versions of the NDC schema regularly, and individual airlines often implement airline-specific extensions or interpretations. This creates a versioning problem that makes traditional API versioning strategies look simple by comparison.

I've encountered situations where we needed to support three different NDC schema versions simultaneously because different airline partners were at different stages of their implementation journey. The data models need to accommodate this heterogeneity without creating separate pipelines for each version, which means building abstraction layers that can map different schema versions to a canonical internal representation.

The testing burden is substantial. You can't simply mock API responses because the schema variations between airlines mean that a response structure that works perfectly for one carrier might be invalid for another. I've invested heavily in contract testing and schema validation frameworks that can catch incompatibilities before they reach production.

Real-Time Analytics and the Death of Batch Processing

The shift to API-first distribution means that many analytics use cases that were previously satisfied by overnight batch processes now require near-real-time data streams. Revenue management needs current shopping data to adjust pricing algorithms. Customer service needs immediate access to order status across multiple airline systems. Marketing needs to track offer presentation and conversion in real-time to optimise merchandising strategies.

I've found that traditional data warehouse architectures struggle with this requirement. Loading NDC transaction data through nightly ETL jobs means your analytics are always at least 24 hours stale, which is unacceptable when pricing decisions need to respond to demand signals within hours or even minutes.

This has pushed me toward streaming architectures using tools like Apache Kafka and real-time processing frameworks. The challenge is that airline APIs don't emit events—you have to poll for updates or implement webhook listeners, then transform those API responses into event streams that can feed real-time analytics pipelines. Worth remembering.

Why does this matter? Because the alternative is worse. The state management becomes particularly complex. An order might be modified multiple times—seats changed, ancillaries added, traveller details updated—and you need to maintain both the current state and the full history of changes for compliance and analytics purposes. I've experimented with event sourcing patterns where each API interaction is captured as an immutable event, allowing you to reconstruct state at any point in time.

My View on Where This Is Heading

Looking ahead, I believe we're still in the early stages of understanding what NDC means for data infrastructure. The standard itself will continue to evolve, but the more fundamental shift is in how airlines think about distribution as a data-driven, algorithmically optimised process rather than a static inventory management problem.

The data engineering skills required for travel technology are converging with those needed in e-commerce and digital platforms more broadly. We need to think like product engineers building real-time systems, not just data engineers building analytical pipelines. The distinction between transactional and analytical systems is blurring as the feedback loops between pricing, merchandising, and customer behaviour tighten to near-instantaneous timescales.

I'm particularly excited about the potential for machine learning in this new paradigm. When offers are dynamically generated and every shopping interaction is captured in detail, you have the raw material for sophisticated personalisation and optimisation that was impossible with legacy distribution. The challenge is building data platforms that can support both the operational demands of NDC distribution and the experimental needs of ML model development.

The NDC revolution is fundamentally about moving airline distribution from a batch-oriented, message-based architecture to a real-time, API-first platform. For those of us building the data infrastructure that powers this transformation, it's an opportunity to apply modern engineering practices to an industry that desperately needs them—and to prove that travel technology can be every bit as sophisticated as what we see in other digital-native sectors.

About Martin Tuncaydin

Martin Tuncaydin is an AI and Data executive in the travel industry, with deep expertise spanning machine learning, data engineering, and the application of emerging AI technologies across travel platforms. Follow Martin Tuncaydin for more insights on ndc, data engineering.

Nginx Reverse Proxy: Complete Configuration Guide

Big Mazzy — Fri, 17 Apr 2026 09:00:40 +0000

Nginx Reverse Proxy: Your Gateway to Scalable and Secure Applications

Ever wondered how popular websites handle massive traffic or serve multiple applications from a single server? This guide will walk you through setting up an Nginx reverse proxy, a powerful tool that acts as an intermediary for your web applications. You’ll learn how to configure Nginx to direct incoming traffic to the correct backend service, enhance security, and improve performance.

What is a Reverse Proxy, Anyway?

Imagine you have a popular restaurant with several chefs, each specializing in a different cuisine. A host at the front door takes all customer orders and directs them to the appropriate chef. That host is like a reverse proxy. Instead of customers directly interacting with each chef (your backend applications), they interact with the proxy, which then forwards their request to the correct service.

A reverse proxy is a server that sits in front of one or more web servers, intercepting requests from clients. It forwards those requests to the appropriate backend server and then returns the server's response to the client, making it appear as if the proxy itself is the origin of the response. This offers several benefits, including load balancing, improved security, and SSL termination.

Why Use Nginx as Your Reverse Proxy?

Nginx (pronounced "engine-x") is a high-performance web server and reverse proxy known for its stability, rich feature set, and low resource consumption. Its event-driven architecture makes it exceptionally good at handling a large number of concurrent connections, making it an ideal choice for a reverse proxy. Many developers choose Nginx for its flexibility and the extensive community support available.

Getting Started: Installation

Before we configure Nginx, you need to have it installed on your server. The installation process varies slightly depending on your operating system.

For Debian/Ubuntu:

sudo apt update
sudo apt install nginx

For CentOS/RHEL:

sudo yum update
sudo yum install nginx

Once installed, you can start and enable the Nginx service:

sudo systemctl start nginx
sudo systemctl enable nginx

You can verify the installation by visiting your server's IP address in a web browser. You should see the default Nginx welcome page.

Basic Reverse Proxy Configuration

The core of Nginx configuration lies in its configuration files, typically found in /etc/nginx/. The main configuration file is nginx.conf, but it's best practice to create separate configuration files for each site or proxy configuration in the sites-available directory and then create symbolic links to them in the sites-enabled directory.

Let's create a configuration file for our first reverse proxy. We'll name it my_app.conf.

sudo nano /etc/nginx/sites-available/my_app.conf

Now, let's add a basic configuration to proxy requests to a hypothetical application running on localhost:3000.

server {
    listen 80;
    server_name your_domain.com www.your_domain.com; # Replace with your actual domain

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Let's break this down:

listen 80;: This tells Nginx to listen for incoming HTTP traffic on port 80.
server_name your_domain.com www.your_domain.com;: This directive specifies the domain names for which this server block should respond.
location / { ... }: This block defines how Nginx should handle requests for the root path (/) of your domain.
proxy_pass http://localhost:3000;: This is the key directive. It tells Nginx to forward all requests matching this location to the backend application running at http://localhost:3000.
proxy_set_header ...: These directives pass important information from the original client request to the backend server.
- Host $host: Passes the original Host header.
- X-Real-IP $remote_addr: Passes the real IP address of the client.
- X-Forwarded-For $proxy_add_x_forwarded_for: Appends the client's IP address to the X-Forwarded-For header, which is useful if you have multiple proxies.
- X-Forwarded-Proto $scheme: Indicates whether the original request was HTTP or HTTPS.

To enable this configuration, create a symbolic link:

sudo ln -s /etc/nginx/sites-available/my_app.conf /etc/nginx/sites-enabled/

Test your Nginx configuration for syntax errors:

sudo nginx -t

If the test is successful, reload Nginx to apply the changes:

sudo systemctl reload nginx

Now, when you visit your_domain.com in your browser, Nginx will forward the request to your application running on localhost:3000.

Serving Multiple Applications from One Server

One of the most common use cases for a reverse proxy is to host multiple applications on a single server. This is particularly useful when you don't want to manage separate IP addresses or ports for each application. Let's say you have a Node.js app on localhost:3000 and a Python app on localhost:5000.

You can configure Nginx to route traffic based on the domain name.

First, create a configuration file for your Python app:

sudo nano /etc/nginx/sites-available/python_app.conf

Add the following content:

server {
    listen 80;
    server_name python_app.your_domain.com; # Replace with your subdomain

    location / {
        proxy_pass http://localhost:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Now, ensure your my_app.conf is set up for your Node.js app:

server {
    listen 80;
    server_name node_app.your_domain.com; # Replace with your subdomain

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Remember to enable these configurations and reload Nginx as shown previously.

This setup allows you to manage multiple applications efficiently. For hosting your applications, consider providers like PowerVPS or Immers Cloud, which offer robust infrastructure suitable for running these services.

Enhancing Security with SSL/TLS

Serving your applications over HTTPS is crucial for security and user trust. Nginx makes it straightforward to implement SSL/TLS termination. This means Nginx handles the encryption and decryption of traffic, and then forwards unencrypted traffic to your backend applications.

The easiest way to obtain and manage SSL certificates is by using Let's Encrypt, a free, automated, and open certificate authority. You can use the Certbot tool to automate this process.

First, install Certbot and its Nginx plugin:

For Debian/Ubuntu:

sudo apt install certbot python3-certbot-nginx

For CentOS/RHEL:

sudo yum install epel-release
sudo yum install certbot python3-certbot-nginx

Once installed, run Certbot to obtain and install certificates for your domain. Make sure your domain's DNS records point to your server's IP address.

sudo certbot --nginx -d your_domain.com -d www.your_domain.com

Certbot will automatically modify your Nginx configuration to enable HTTPS and set up automatic certificate renewals. It will also prompt you to redirect HTTP traffic to HTTPS.

Your Nginx configuration file (my_app.conf in our example) will be updated to look something like this:

server {
    listen 80;
    server_name your_domain.com www.your_domain.com;

    # Redirect HTTP to HTTPS
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name your_domain.com www.your_domain.com;

    ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

This configuration directs all traffic to port 443 (HTTPS), handles SSL termination, and then proxies the requests to your backend application.

Load Balancing with Nginx

As your application grows, you might need to run multiple instances of your backend service to handle increased traffic. Nginx can act as a load balancer, distributing incoming requests across these multiple backend servers.

First, define your backend servers in an upstream block:

upstream my_backend_servers {
    server backend1.your_domain.com:3000;
    server backend2.your_domain.com:3000;
    server backend3.your_domain.com:3000;
}

server {
    listen 80;
    server_name your_domain.com;

    location / {
        proxy_pass http://my_backend_servers; # Use the upstream name here
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

In this example:

upstream my_backend_servers { ... }: This block defines a group of servers named my_backend_servers. Nginx will distribute traffic among these servers using a round-robin algorithm by default.
proxy_pass http://my_backend_servers;: The proxy_pass directive now points to the name of the upstream group.

Nginx also supports other load balancing methods like least-connected and IP hash. You can also add health checks to your upstream servers to automatically remove unhealthy servers from the pool.

For managing your server infrastructure, a resource like the Server Rental Guide can be an invaluable reference.

Advanced Configurations and Tips

1. Caching: Nginx can cache responses from your backend servers, reducing the load on your applications and speeding up delivery to clients.

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    # ... other configurations ...

    location / {
        proxy_pass http://localhost:3000;
        proxy_cache my_cache; # Enable caching
        proxy_cache_valid 200 302 10m; # Cache successful responses for 10 minutes
        proxy_cache_valid 404 1m;      # Cache 404s for 1 minute
        proxy_cache_key "$scheme$request_method$host$request_uri";
        add_header X-Cache-Status $upstream_cache_status; # Helpful for debugging
        # ... other proxy_set_header directives ...
    }
}

2. Rate Limiting: Protect your applications from abuse by limiting the number of requests a client can make within a certain time frame.


nginx
http {
    # ... other http configurations ...

    limit_req_zone $binary_remote_addr zone=mylimit:

How to Build an AI Sales Assistant Using n8n and GPT (Step-by-Step Guide)

Ciphernutz — Fri, 17 Apr 2026 09:00:31 +0000

Most “AI sales assistants” don’t actually sell.

They respond.
They chat.
They look impressive in demos.

But when it comes to real sales?

Leads still go cold
Follow-ups still get missed
Conversions don’t improve

That’s because most setups are just chatbots, not systems.

In this guide, you’ll learn how to build a real AI sales assistant using n8n and OpenAI GPT that:

Qualifies leads automatically
Responds instantly (24/7)
Follows up without manual effort
Pushes data into your CRM
Actually improves conversion rates

No fluff. Just a system that works.

What You’re Actually Building

Before jumping into tools, let’s clarify the outcome.

You’re not building a chatbot
You’re building a sales workflow system powered by AI

The system will:

Capture leads (form, WhatsApp, website, etc.)
Send data to GPT for qualification
Generate contextual responses
Trigger follow-ups automatically
Store everything in CRM
Notify your sales team when needed

Why Use n8n + GPT?

Because together, they solve the biggest sales bottleneck:

Manual coordination between tools

Why n8n?

Open-source & flexible
Visual workflow builder
Connects APIs easily
Perfect for automation pipelines

Why OpenAI GPT?

Understands natural language
Can qualify leads intelligently
Generates human-like responses
Adapts to context

Architecture Overview
Here’s the simple flow:

Lead Source → n8n Webhook → GPT Processing → Decision Logic → CRM + Response + Follow-up

Step 1: Capture Leads (Webhook Setup)

Start by creating a Webhook node in n8n.

Input sources:
Website forms
Landing pages
WhatsApp API
Facebook Ads leads

Example payload:

{
  "name": "John Doe",
  "email": "john@example.com",
  "message": "Looking for AI automation for my clinic"
}

Step 2: Send Data to GPT for Qualification

Now connect an HTTP Request node (or OpenAI node) to call GPT.

Prompt Example:

Classify this lead based on intent:
- High Intent
- Medium Intent
- Low Intent

Also extract:
- Industry
- Use case
- Urgency

Lead data: {{ $json["message"] }}

Output Example:

{
  "intent": "High",
  "industry": "Healthcare",
  "use_case": "Automation",
  "urgency": "Immediate"
}

Step 3: Add Decision Logic in n8n

Use an IF node to route leads:

High Intent → Immediate response + notify sales
Medium Intent → Nurture sequence
Low Intent → Add to long-term follow-up

This is where your system becomes intelligent, not reactive.

Step 4: Generate AI Response

Use GPT again to create a response.

Write a short, friendly reply to this lead:
{{lead_message}}

Context:
- Industry: {{industry}}
- Intent: {{intent}}

Goal: Book a call

Output:

“Hey John, thanks for reaching out! We’ve helped clinics automate workflows like yours…”

Step 5: Send Response Automatically

You can send replies via:

Email (SMTP node)
WhatsApp API
Slack/internal tools

Now your assistant responds instantly, even at 2 AM.

Step 6: Push Data to CRM

Store everything:

Lead details
Intent level
Conversation

Popular integrations:

HubSpot
Salesforce
Notion

Step 7: Automate Follow-Ups (This Is Where Money Is Made)

Most deals are lost here.

Set up follow-up workflows:

Day 1: Reminder message
Day 3: Case study
Day 7: Final nudge

All automated via n8n.

Advanced Improvements

Once your system works, you can level up:

1. Lead Scoring System
Assign scores based on:

Budget
Urgency
Industry

2. Multi-Channel Automation
Connect:

3. AI Memory Layer
Store past interactions to personalize responses.

4. Voice AI Integration
Turn this into a calling assistant.

ROI: What You Can Expect
With a proper setup:

3-5x faster response time
30-50% reduction in manual work
Higher lead-to-call conversion

Final Thought

Most businesses don’t lose leads because of bad products.

They lose them because:

No one replies on time
Follow-ups don’t happen
Systems don’t exist

Building an AI sales assistant using n8n + OpenAI GPT solves exactly that.

gRPC in Go: real-time streaming for microservices

Odilon HUGONNOT — Fri, 17 Apr 2026 09:00:03 +0000

Three internal Go services need real-time crypto prices. The first implementation: REST polling against a homemade aggregator, every second. Result: 3 services × 60 req/min = 180 requests per minute for data that changes every 200 ms. Latency anywhere from 500 ms to 1 s depending on where you land in the polling cycle. And that's before counting JSON serialization overhead on every round-trip.

SSE would have worked — I have a dedicated article on it. But SSE is designed to push events to a browser. Service-to-service, the unidirectional HTTP/1.1 protocol brings more constraints than benefits. WebSockets are bidirectional, but stateful, complex to manage at scale, and there's no data contract — anyone sends anything.

gRPC server streaming solves exactly this. One persistent HTTP/2 connection. The server pushes updates as they arrive. The contract is defined in a .proto file — versioned, typed, with generated code on both sides. That's the right tool.

REST vs gRPC: the real comparison

Before diving into code, an honest comparison. Not the marketing bullet points, but the real questions you'll ask yourself when choosing between the two.

REST / JSON

gRPC / Protobuf

Format

JSON (text)

Protobuf (binary)

Contract

OpenAPI (optional)

.proto (mandatory)

Streaming

Not native (SSE / WS as add-on)

Native (4 modes)

Payload size

~1x (baseline)

~3–10x smaller

Browser

✅ native

⚠️ gRPC-web only

Code generation

Optional

Mandatory

Debugging

curl, Postman

grpcurl, Evans

Honest take: REST is the obvious answer for public APIs and browser clients. gRPC becomes the right choice when both ends are internal Go services, you need streaming, and you want strict contracts between teams without maintaining an OpenAPI spec by hand.

Defining the contract in Protobuf

Everything starts with the .proto file. It's the shared source of truth between the server and its clients. You define the messages first — the typed equivalent of JSON bodies — then the service and its methods.

syntax = "proto3";
package pricefeed;
option go_package = "./pb";

message PriceUpdate {
    string pair      = 1;  // "BTC/USDT"
    string exchange  = 2;  // "binance"
    double bid       = 3;
    double ask       = 4;
    int64  timestamp = 5;  // unix millis
}

message SubscribeRequest {
    repeated string pairs = 1;  // ["BTC/USDT", "ETH/USDT"]
}

service PriceFeed {
    // Server streaming: client subscribes, server pushes updates
    rpc Subscribe(SubscribeRequest) returns (stream PriceUpdate);

    // Unary: get last known price for a pair
    rpc GetLatest(SubscribeRequest) returns (PriceUpdate);
}

The stream keyword before the return type signals a server streaming RPC. The client sends a single request (SubscribeRequest) and receives an indefinite stream of PriceUpdate messages until the connection is closed — by the server, by the client, or by a context timeout.

Once the file is written, protoc generates the corresponding Go code:

protoc --go_out=. --go_opt=paths=source_relative \
       --go-grpc_out=. --go-grpc_opt=paths=source_relative \
       pricefeed.proto

Result: two Go files in ./pb/ — message structs and server/client interfaces. Never edit these files by hand: they'll be overwritten on the next generation.

Implementing the Go server

The server implements the interface generated by protoc. Embedding pb.UnimplementedPriceFeedServer ensures forward compatibility: if new methods are added to the service without being implemented, calls return Unimplemented instead of failing at compile time.

type PriceFeedServer struct {
    pb.UnimplementedPriceFeedServer
    updates chan *pb.PriceUpdate
}

func (s *PriceFeedServer) Subscribe(req *pb.SubscribeRequest, stream pb.PriceFeed_SubscribeServer) error {
    pairs := make(map[string]bool)
    for _, p := range req.Pairs {
        pairs[p] = true
    }

    for {
        select {
        case update := <-s.updates:
            if !pairs[update.Pair] {
                continue
            }
            if err := stream.Send(update); err != nil {
                // Client disconnected — not a server error
                return nil
            }
        case <-stream.Context().Done():
            return nil  // Client cancelled the subscription
        }
    }
}

A few important points in this implementation:

The updates channel is fed by the goroutine collecting prices from exchanges (Binance, Kraken, etc.). The gRPC server only distributes.
stream.Send() returns an error if the client has disconnected. Returning nil here is intentional: it's not a server error, it's a normal disconnection.
stream.Context().Done() catches explicit client cancellations and context timeouts. Without this, the goroutine would keep running after the client disconnects.

To start the server:

func main() {
    updates := make(chan *pb.PriceUpdate, 100)

    srv := grpc.NewServer()
    pb.RegisterPriceFeedServer(srv, &PriceFeedServer{updates: updates})

    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        slog.Error("failed to listen", "error", err)
        os.Exit(1)
    }

    slog.Info("gRPC server listening", "addr", ":50051")
    if err := srv.Serve(lis); err != nil {
        slog.Error("serve error", "error", err)
        os.Exit(1)
    }
}

The Go client

The client is equally straightforward. The gRPC connection is reusable — create it once and inject it into the services that need it.

func connectPriceFeed(ctx context.Context, addr string) error {
    conn, err := grpc.NewClient(addr, grpc.WithTransportCredentials(insecure.NewCredentials()))
    if err != nil {
        return fmt.Errorf("dial: %w", err)
    }
    defer conn.Close()

    client := pb.NewPriceFeedClient(conn)
    stream, err := client.Subscribe(ctx, &pb.SubscribeRequest{
        Pairs: []string{"BTC/USDT", "ETH/USDT"},
    })
    if err != nil {
        return fmt.Errorf("subscribe: %w", err)
    }

    for {
        update, err := stream.Recv()
        if err == io.EOF {
            return nil  // Server closed the stream cleanly
        }
        if err != nil {
            return fmt.Errorf("recv: %w", err)
        }
        slog.Info("price update",
            "pair", update.Pair,
            "bid", update.Bid,
            "ask", update.Ask,
            "exchange", update.Exchange,
        )
    }
}

Note on insecure.NewCredentials(): this is for local development and intra-cluster communication (mTLS managed at the network level by the service mesh). In production over a public network, use credentials.NewClientTLSFromFile() or credentials.NewTLS().

The stream.Recv() loop is blocking. If the server isn't pushing updates, the client waits — without burning CPU. HTTP/2 handles that, no active polling. When the context is cancelled (client service shutdown, timeout, etc.), Recv() returns an error and the loop stops cleanly.

The 4 gRPC streaming modes

gRPC supports four communication patterns. We used server streaming above, but it's worth knowing the other three to pick the right tool for each case.

Unary — request / response

Classic REST behaviour. One call, one response. Ideal for point-in-time reads (GetLatest in our service).

rpc GetLatest(SubscribeRequest) returns (PriceUpdate);

Server streaming — subscribing to a feed

What we just implemented. The client sends one request, the server pushes as many responses as it wants. Perfect for feeds: prices, metrics, logs.

rpc Subscribe(SubscribeRequest) returns (stream PriceUpdate);

Client streaming — batch data upload

The client sends a stream of requests, the server replies once at the end. Use cases: bulk data ingestion, segmented file upload, order flow to aggregate before processing.

rpc BatchOrders(stream Order) returns (BatchResult);

Bidirectional streaming — streams in both directions

Client and server exchange streams simultaneously. Legitimate use cases: chat, collaborative editing, negotiation protocols. But be warned — this is the most complex mode to implement and debug. For most microservice needs, server streaming or unary is enough. Bidirectional is often over-engineered.

rpc MarketDataFeed(stream MarketQuery) returns (stream MarketEvent);

Conclusion

gRPC isn't here to replace REST. They're two tools with different use cases, and conflating them leads either to unnecessary complexity (gRPC-ifying a public API) or to broken polling (REST-ifying a real-time feed).

The right tool here is gRPC, when three conditions are met: internal Go services, need for data streaming, strict contracts between teams. On this concrete case, switching from REST polling to gRPC server streaming cut latency from ~800 ms to <50 ms, eliminated 180 req/min of useless network overhead, and delivered a versioned contract between the aggregator service and its consumers.

For APIs exposed to browsers or third-party clients: REST is still the answer. For service-to-service with real-time constraints: that's gRPC.

Building a Privacy-First URL Shortener on Blockchain

Wes Parsons — Fri, 17 Apr 2026 09:00:02 +0000

Why Traditional URL Shorteners Are a Privacy Nightmare

When you click a bit.ly link, here's what happens:

Bit.ly logs your IP, timestamp, user agent
They see the destination URL
They track your browsing patterns
They sell this data to advertisers

Even if you trust the shortener, their database can be hacked.

Introducing Cryptly

I built cryptly to solve this problem using blockchain and encryption.

How It Works

Encryption (Client-Side)

   const encrypted = await crypto.subtle.encrypt(
     { name: "AES-GCM", iv: iv },
     key,
     urlBuffer
   );

Blockchain Storage
- Encrypted URL stored on Cronos blockchain
- Immutable, decentralized
- No centralized database to hack
Decryption (Browser)
- Browser fetches from blockchain
- Decrypts locally using Web Crypto API
- Server never sees destination

Architecture

Tech Stack:

Cloudflare Workers (serverless, edge deployment)
Web Crypto API (native browser encryption)
Cronos blockchain (decentralized storage)

Privacy Benefits:

✅ Server never sees destination URLs
✅ No tracking, no analytics
✅ No database to leak
✅ Censorship-resistant (blockchain)

Try It

Live demo: cryptly.workers.dev
GitHub: github.com/your-username/cryptly

Still in early stages but feedback welcome!

privacy #blockchain #webdev #opensource

3 Ways to Configure Resources in Terraform

Ijay — Fri, 17 Apr 2026 09:00:00 +0000

Infrastructure as Code has changed how engineers manage cloud infrastructure. Instead of manually creating resources in the cloud console, we can define everything in code and let tools handle the provisioning.

Terraform is one of the most popular tools for this purpose.

When working with Terraform, you often need to define values for your resources. For example, you may want to specify the following:

The instance type of a server
The region where resources will be deployed
The name of a resource
Tags used for identification

Terraform allows you to configure these values in different ways. Choosing the right approach helps make your infrastructure easier to manage, reuse, and maintain.

In this article, you will learn three common ways to configure resource values in Terraform:

Using variables
Using locals
Using auto.tfvars files

By the end of this guide, you will understand when to use each method and how they help improve your Terraform configuration.

Prerequisites

Before reading along, make sure you have the following:

Basic understanding of any cloud provider infrastructure.
Terraform is installed on your machine.

You can verify that Terraform is installed by running the following command in your terminal:

terraform version

If Terraform is installed correctly, you should see the version number above displayed.

Understanding Resource Configuration in Terraform

In Terraform, infrastructure is defined using resources.

A resource represents a cloud component such as a virtual machine, storage bucket, database, or load balancer.

Here is a simple example of a Terraform resource that creates an AWS EC2 instance:

resource "aws_instance" "example" {
  ami           = "ami-0xxxxxxxxxxxxxxx0"
  instance_type = "t2.micro"
}

In this configuration, the values for ami and instance_type are written directly inside the resource block.

This works for simple cases, but it can become difficult to manage when your infrastructure grows. Hardcoding values makes configurations less flexible and harder to reuse.

Terraform provides several ways to make these values more dynamic and easier to manage.

How Do We Add Dynamic Values in Terraform?

When writing Terraform configurations, you may sometimes need values that can change. For example, the instance type of a server may be different in development and production environments.

If you write these values directly inside your resource blocks, your configuration becomes harder to reuse and maintain. Instead, Terraform allows you to define values outside the resource and reference them when needed.

Method 1: Using Variables

Variables allow you to define values outside of your resource blocks. This makes your Terraform configuration more flexible and easier to reuse.

Instead of hardcoding values inside a resource, you define the value once and reference it wherever it is needed.

Step 1: Define the variable.

First, define a variable. This is usually done in a file called variables.tf

variable "instance_type" {
  description = "The EC2 instance type"
  type        = string
  default     = "t2.micro"
}

Above, we created a variable called instance_type.

This variable stores the value Terraform uses when creating the EC2 instance.

The default value is set to t2.micro, but this value can be changed later if needed.

Step 2: Next is to use the variable to create a resource.

After defining the variable, you can reference it inside your resource configuration.

resource "aws_instance" "example" {
  ami           = "ami-0xxxxxxxxxxxxxxx0"
  instance_type = var.instance_type
}

So with this declaration Terraform does not use a hardcoded value for the instance type. Instead, it reads the value from the variable we defined earlier.

The prefix var. tells Terraform that the value is coming from a variable.

When Terraform runs, it will use the value stored in instance_type to configure the resource.

Why do you think variables are useful?

As mentioned earlier, hardcoding values can make your infrastructure difficult to manage, especially as your system grows or needs to scale.

Terraform variables help solve this problem by separating configuration values from the resource definitions.

Variables are useful in several situations.

When you want to reuse the same configuration in different environments

For example, you might use a small instance type in a development environment and a larger one in production. With variables, you can keep the same configuration and only change the value.

When you want to change values without modifying the resource block

Instead of editing the resource every time a value changes, you simply update the variable. This keeps your configuration cleaner and easier to maintain.

When you want to make your Terraform configuration easier for other engineers to use

Variables make it clear which values can be adjusted. This allows other engineers to work with the configuration without needing to modify the core infrastructure code.

Method 2: Using Locals

Terraform locals allow you to store values or expressions that are used multiple times in your configuration.

Locals are helpful when you want to simplify repeated values or calculations.

How do I use Local?

Step 1: Define the Local Values

Create a locals block in your Terraform configuration.

locals {
  instance_name = "example-server"
  instance_type = "t2.micro"
}

The code block defines local values called instance_name and instance_type of the configuration.

Next, you define the local values inside the resource configuration

Step 2: Using Locals in a Resource

resource "aws_instance" "example" {
  ami           = "ami-0abcdef1234567890"
  instance_type = local.instance_type

  tags = {
    Name = local.instance_name
  }
}

The resource configuration uses the value stored in instance_name and in instance_type above to create a resource

Why are Locals Useful in Terraform Declarations?

Locals are useful when you want to avoid repeating the same values in multiple places.
Locals can be used to simplify complex expressions.
The keyword "local" can be used to organize your configuration more clearly.

Method 3: Using auto.tfvars Files

A tfvars file is used to store values for Terraform variables. Instead of typing values in the command line or writing them directly in your configuration, you can place them inside a separate file.

Terraform has a special type of file called ".auto.tfvars."

When Terraform sees a file with this name, it automatically loads the values inside it. This means you do not need to manually pass the file when running Terraform commands.

How is it declared?

Step 1: Define the variable

First, define the variable in your Terraform configuration.

For example, in variable. tffile:

variable "instance_ec2" {
  description = "EC2 instance type"
  type        = string

 tags = {
    Create_By = var.created_by
  }
}

Here, we created a variable called instance_ec2

Step 2: Create the auto.tfvars File

Next, create another file called, let's say, ec2.auto.tfvars

Inside this file, assign a value to the variable.

instance_type = "t3.micro"
created_by    = "dev"

Why Should You Create a auto.tfvars File?

The file helps keep your Terraform configuration clean by separating variable values from the main infrastructure code.

Instead of placing all values directly inside your Terraform files, you can store them in an auto.tfvars file and let Terraform load them automatically.

auto.tfvars Files are useful when:

To keep configuration values separate from your Terraform code
i.e., your resource definitions stay focused on infrastructure, while the variable values are stored in a separate file.
To manage different environment settings
For example, a development environment might use smaller resources, while production may require larger ones.
To allow Terraform to automatically load variable values
Terraform reads .auto.tfvars files automatically when you run commands like terraform plan or terraform apply, so you do not need to pass the file manually.

Because of the benefit of an auto.tfvars file, many teams use tfvars files to manage values for different environments, such as

development
staging
production

When Should You Use Each Method in Resource Configuration?

Variables are best when you want flexibility and reusable configurations.
Locals are useful for simplifying repeated values inside your Terraform code.
auto.tfvars files help supply variable values automatically without modifying the configuration.

In practice, most Terraform projects use a combination of these approaches.

Conclusion

Terraform provides several ways to configure values for your resources. Choosing the right approach can make your infrastructure easier to manage and maintain.

Other Helpful Resources

Stay updated with my projects by following me on Twitter, LinkedIn, and GitHub.

Thank you for reading

I'm a Final-Year CS Student — And I'm Done Letting AI Tools Own My Data

Nirbhay Gautam — Fri, 17 Apr 2026 08:57:32 +0000

There's a particular kind of restlessness that comes from being a CS student in 2026.
It's not the assignments, or the deadlines, or even the exams. It's the feeling that by the time you've shipped something, the landscape has already shifted. Every week there's a new model, a new tool, a new framework that everyone on the internet insists will change everything. I've genuinely lost count of how many times I've read the words "the future is here" in the last six months alone.
So when OpenClaw started showing up everywhere — 20,000 GitHub stars in a day, people on every forum talking about their "personal AI agent" like it was a houseplant they were proud of — my first instinct was to actually look into it. I'd learned to tell the difference between hype and something worth digging into. This felt like the latter.
I was right.

Why I Actually Tried It

It wasn't the star count that got me. It was one specific thing I kept reading about: you run it yourself. On your own machine. Your data doesn't disappear into some company's server farm. Your conversations, your memory, your context — it all lives in plain text files that you can open, read, and edit like any other document.

That mattered to me more than I expected it to.

As someone who's spent four years studying how these systems work under the hood, I've grown increasingly uncomfortable with how much of my digital life runs inside black boxes I'm not allowed to inspect. Most AI tools are designed to keep you dependent and ignorant — not out of malice, but because that's the model. OpenClaw felt like a deliberate rejection of that. Not a subscription. Not a walled garden. A tool that actually respects the intelligence of the person using it.

The second pull was automation. I have a full plate — final year coursework, projects, part-time commitments, and a group chat that never sleeps. The idea that something could handle the repetitive edges of that without me having to babysit it wasn't a luxury. It was just practical.
So I set it up. It took an afternoon, a couple of wrong turns, and one moment where I was fairly sure I'd misconfigured something permanently. But I got there.

The First Week: Honest Notes from the Trenches

The first thing OpenClaw did that genuinely impressed me was remember something I told it on day one and surface it — unprompted — three days later in a completely different context. I already understood the mechanism: daily logs for short-term context, a long-term MEMORY.md file for the important stuff, all plain markdown. But seeing it work in practice still landed differently than reading about it. It felt less like a chatbot and more like a system that was actually tracking state in a meaningful way.

The automation side was where things got interesting from an engineering perspective. The first workflow I built was simple — summarising a long document and routing the output somewhere useful. The setup took longer than the time it saved, at first. But that's always how it goes when you're building infrastructure rather than just using it. Once the pattern clicks, everything after it gets faster.

What I didn't expect was how readable the internals would be. The memory files, the logs, the configuration — all of it is plain text you can inspect, version control, and reason about. For someone who's used to digging into source code to understand what a system is actually doing, that's not a small thing. It meant I could debug it like any other software rather than submitting a support ticket and hoping for the best.

What It Gets Right

Most AI tools are built on the assumption that you should trust them completely and ask no questions. You send input, you receive output, and the gap between the two is none of your business.

OpenClaw makes the opposite bet. The architecture is transparent by design. Your memory is in files you own. Your logs are yours to read. Your configuration is yours to modify. It's a system that treats you as someone capable of understanding what's happening — because you are.

That transparency has a compounding effect. Every time something didn't behave as expected and I had to dig into why, I came out with a clearer mental model of how AI agents actually work — the execution loops, the tool calls, the context management. That's knowledge that transfers. It doesn't matter what the next popular agent framework is; the underlying concepts are the same.

The other thing it gets right is low friction adoption. You don't need a new app or a new habit. You can interface with it through messaging platforms you already use. The best tools are the ones that fit into your life rather than demanding you reorganize around them. At its best, OpenClaw disappears into your existing workflow.

On the Pace of All This

I want to be honest about something: the pace of this space is genuinely wild — even when you're close to it. OpenClaw went from zero to the most-starred project in GitHub history in months. Its creator got hired by OpenAI mid-project. Serious security vulnerabilities, a thriving skill marketplace, a conference, major players building on top of it. All while I was finishing coursework.

Being a CS student doesn't make you immune to that pace — if anything, it makes you more aware of how much is happening simultaneously and how hard it is to separate signal from noise. The temptation is to try to follow everything. I've learned that's the wrong move. Better to go deep on something real than to skim the surface of everything.
OpenClaw has become that something for me — not because it's the most polished tool out there, but because it's open, it's honest about what it is, and working with it has been more educational than most things I've read about AI agents this year.

What Comes Next

I'm still early with it. There's a lot I haven't touched — deeper skill integrations, multi-agent setups, building on top of the API layer. But I'm not in a rush.

That might be the most useful reframe OpenClaw gave me: the goal isn't to keep up with everything. It's to actually build something, understand it properly, and carry that understanding forward regardless of what the landscape looks like next month.

If you're a developer who's been watching the AI agent space from a distance, waiting for something worth getting into — this is worth your time. Not because it'll automate your life overnight. But because understanding it changes how you think about everything else in this space.

And right now, that's the most useful thing a tool can do.

I added @ai-context blocks to 1000 files — here's what the AI agent said

Clément Tournier — Fri, 17 Apr 2026 08:50:59 +0000

I've been working on a large Next.js production project — around 1000 files,
a complex booking system, Firebase, Zod schemas, custom hooks, services.

Every time I asked an AI agent to help me modify something, it spent the
first part of the conversation just reading files to understand the
architecture. 30-50 lines per file, one by one.

So I built aidoc-kit — a CLI that enriches every file in your codebase
with structured @ai-* blocks, generated automatically by an LLM.

What it generates

/**
 * @ai-agent types-expert
 * @ai-context
 * Defines Zod schemas and TypeScript types for a universal 3-step booking
 * form (participants → formulas → options). Key complexity: dual age
 * categorization system — getAgeCategory() uses fixed global ranges,
 * getAgeCategoryFromRanges() uses per-stay configurable ranges with hardcoded
 * edge cases for 6-11 and 12-16 age ranges. Factory functions initialize
 * state consumed by payment, components, hooks, and services in @ai-cascade.
 * @ai-enriched 2026-04-16
 * @ai-when-modifying
 * 1. Check cascade files below before modifying
 * 2. After modifying, ask the developer to run @ai-validate
 *
 * @ai-cascade
 * - src/app/(public)/paiement/page.tsx
 * - src/components/sejours/universal/BookingPreviewModal.tsx
 * - src/hooks/sejours/useUniversalBooking.ts
 * - src/services/sejours/universalBookingService.ts
 * ... (11 files total)
 *
 * @ai-validate
 * npm run typecheck
 */

Four tags do the heavy lifting:

@ai-context — 2-3 sentence role description. The agent knows what the file does without reading it.
@ai-cascade — list of dependent files. No more grepping for imports.
@ai-when-modifying — checklist the agent must follow before touching the file.
@ai-validate — command to run after any change.

I tested it on a real production project

After enriching ~70 files in the bookings module, I asked an AI agent to
analyse the full system and give me an honest review of aidoc-kit itself.

Here's what it said verbatim:

"Without aidoc-kit, I would have had to read the first 30-50 lines of each
file to understand its role. With @ai-context, I scanned 15+ files in
seconds and focused deep reads only on the truly complex ones —
EditInscriptionModal and universalBookingService.

@ai-cascade turned out more useful than expected — not just for regression
prevention, but for architecture mapping. The list of 20+ dependents on
inscriptions.ts showed immediately why that type file is critical.

Honest gain: real time saving on a project this size."

That last line is the one that mattered to me.

What surprised me

@ai-cascade is an architecture map, not just a safety net.

I expected agents to use it to avoid breaking things. What actually happened:
the agent used it to understand the system topology — which files are leaves,
which are hubs, which are critical paths — without running a single grep.

Files with 20+ dependents are now automatically flagged in @ai-context:

FastAPI With LangChain and MongoDB

MongoDB Guests — Fri, 17 Apr 2026 08:48:54 +0000

This article was written by Carlos Barboza.

I'm happy to welcome you to this tutorial! This demonstration provides a fully functional example of integrating FastAPI, LangChain, and MongoDB, and I'm eager to share it with all technology enthusiasts.

The value of this guide is that it provides a working example—you can copy and paste the code, and it will run seamlessly without any further configuration. It will also give you a clear, practical overview of the kinds of applications you can build using these powerful tools.

I am developing a suggestion application designed to assist customers globally in generating new ideas. This involves providing personalized recommendations and checking for existing companies that offer comparable services.

Prerequisites

Python, virtualenv basics
Basic understanding of REST APIs
MongoDB basics (collections, documents)
Accounts/keys
- MongoDB Atlas or local MongoDB
- LLM provider API key

Project Architecture

FastAPI is a Python framework for building APIs quickly, efficiently, and with very little code.

It’s known for being fast (as the name implies), easy to use, and perfect for modern applications like AI, microservices, and backend APIs. In this example, it will handle the API queries for the backend.

MongoDB is a NoSQL, document-based database that stores data in flexible JSON-like documents instead of rigid tables like SQL. This makes it fast to develop, easy to scale, and great for evolving data structures. For our case, it will store all the information.

LangChain is a framework for building applications powered by LLMs (like GPT, LLaMA, Ollama, and Mistral) that lets you connect models with tools, memory, external data, and multi-step reasoning. It provides the necessary tools in Python for utilizing AI models.

Project Setup

MongoDB Atlas

The simplest way to obtain a MongoDB instance for this guide is to register on the official site. This will provide you with an M0 instance, which is entirely sufficient for executing this guide.

Docker

Should you not have Docker installed, the official link provides installation instructions based on your operating system.

The docker-compose file is configured to set up a MongoDB container. This container uses the official version 7.0, is named mongodb, and uses the credentials root as the username and example as the password. Furthermore, a volume is defined to ensure data persistence across container reloads.

version: "3.3"
services:
  mongo:
    image: mongo:7.0
    container_name: mongodb
    restart: unless-stopped
    ports:
      - "27017:27017"
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: example
    volumes:
      # Named volume for persistent data
      - mongo_data:/data/db

volumes:
  mongo_data:

Execute the following commands to execute the docker:

docker compose up -d

Finally, you can connect to the MongoDB instance using the connection string. In your case, it’s mongodb://root:example@localhost:27017.

LLMs

Large language models (LLMs) are AI models trained on massive amounts of text that can understand language, generate text, write code, answer questions, and hold conversations like a human.

They don’t think—they predict the next word intelligently based on patterns they've learned. For our case, we are going to use Ollama so you can execute the example on your local machine.
Alternatively, you may choose to use a different LLM, such as OpenAI, though this may incur additional costs.

Ollama installation

Depending on your operating system, you must follow the official instructions. At the end of the day, you should be able to execute Ollama commands in your terminal.

ollama list # Shows all the models available in your terminal
ollama pull llama3.2 # Download the llama3.2 model

Development

Requirements.txt

These are all the libraries needed for the project:

aiohappyeyeballs==2.6.1
aiohttp==3.13.2
aiosignal==1.4.0
annotated-doc==0.0.4
annotated-types==0.7.0
anyio==4.12.0
attrs==25.4.0
bcrypt==3.2.2
certifi==2025.11.12
cffi==2.0.0
charset-normalizer==3.4.4
click==8.3.1
colorama==0.4.6
cryptography==46.0.3
dataclasses-json==0.6.7
distro==1.9.0
dnspython==2.8.0
ecdsa==0.19.1
email-validator==2.3.0
fastapi==0.123.0
frozenlist==1.8.0
greenlet==3.2.4
h11==0.16.0
httpcore==1.0.9
httpx==0.28.1
httpx-sse==0.4.3
idna==3.11
jiter==0.12.0
jsonpatch==1.33
jsonpointer==3.0.0
langchain==1.1.0
langchain-classic==1.0.0
langchain-community==0.4.1
langchain-core==1.1.0
langchain-openai==1.1.0
langchain-text-splitters==1.0.0
langgraph==1.0.4
langgraph-checkpoint==3.0.1
langgraph-prebuilt==1.0.5
langgraph-sdk==0.2.10
langsmith==0.4.49
marshmallow==3.26.1
motor==3.7.1
multidict==6.7.0
mypy_extensions==1.1.0
numpy==2.3.5
openai==2.8.1
orjson==3.11.4
ormsgpack==1.12.0
packaging==25.0
passlib==1.7.4
propcache==0.4.1
pyasn1==0.6.1
pycparser==2.23
pydantic==2.12.5
pydantic-settings==2.12.0
pydantic_core==2.41.5
pymongo==4.15.4
python-dotenv==1.2.1
python-jose==3.5.0
python-multipart==0.0.20
PyYAML==6.0.3
regex==2025.11.3
requests==2.32.5
requests-toolbelt==1.0.0
rsa==4.9.1
six==1.17.0
sniffio==1.3.1
SQLAlchemy==2.0.44
starlette==0.50.0
tenacity==9.1.2
tiktoken==0.12.0
tqdm==4.67.1
typing-inspect==0.9.0
typing-inspection==0.4.2
typing_extensions==4.15.0
urllib3==2.5.0
uvicorn==0.38.0
xxhash==3.6.0
yarl==1.22.0
zstandard==0.25.0

Environment file

It’s recommended to have an .env file with sensitive information like the MongoDB URI, JWT Secret Key, and other settings. This file should be excluded from the git.ignore and must be configured on the main location.

MONGO_URI=mongodb+srv://admin:admin@atlascluster.f3spasq.mongodb.net/
MONGO_DB_NAME=fastapi_demo
JWT_SECRET_KEY=super-secret-key
JWT_ALGORITHM=HS256
ACCESS_TOKEN_EXPIRE_MINUTES=60
OLLAMA_HOST=http://host.docker.internal:11434 # Only if fastAPI is running with docker

.gitignore

# ---------------------
# Environment variables
# ---------------------
.env
.env.local
.env.*.local

# ---------------------
# Python
# ---------------------
__pycache__/
*.pyc
*.pyo
*.pyd
*.pdb
*.pkl
*.db

# Virtual environments
venv/
.venv/

# Byte-compiled
*.py[cod]
*$py.class

# ---------------------
# FastAPI / Uvicorn logs
# ---------------------
*.log

# ---------------------
# IDE & editor files
# ---------------------
.vscode/
.idea/
*.swp

# ---------------------
# OS files
# ---------------------
.DS_Store
Thumbs.db

# ---------------------
# Docker
# ---------------------
/data/
docker-data/
*.pid

# ---------------------
# Optional cache folders
# ---------------------
cache/
logs/

Schema folder

chat.py
from pydantic import BaseModel

class ChatRequest(BaseModel):
    question: str

class ChatResponse(BaseModel):
    answer: str
    used_context: bool

item.py
from pydantic import BaseModel

class Item(BaseModel):
    id: str
    name: str
    price: float

user.py
from pydantic import BaseModel, EmailStr

class UserCreate(BaseModel):
    email: EmailStr
    password: str

class UserPublic(BaseModel):
    id: str
    email: EmailStr

class Token(BaseModel):
    access_token: str
    token_type: str = "bearer"

class UserInDB(BaseModel):
    id: str
    email: EmailStr
    hashed_password: str

notes.py
from pydantic import BaseModel

class NotesCreate(BaseModel):
    text: str

class NotesInDB(BaseModel):
    id: str
    user_id: str
    text: str

Core folder

config.py
import os

MONGO_URI = os.getenv("MONGO_URI", "mongodb+srv://admin:admin@atlascluster.f3spasq.mongodb.net/")
MONGO_DB_NAME = os.getenv("MONGO_DB_NAME", "fastapi_demo")

JWT_SECRET_KEY = os.getenv("JWT_SECRET_KEY", "change-me")
JWT_ALGORITHM = os.getenv("JWT_ALGORITHM", "HS256")
ACCESS_TOKEN_EXPIRE_MINUTES = int(os.getenv("ACCESS_TOKEN_EXPIRE_MINUTES", "60"))

llm.py
import os
from langchain_community.chat_models import ChatOllama

OLLAMA_HOST = os.getenv("OLLAMA_HOST", "http://localhost:11434")

llm = ChatOllama(
    model="llama3.2"
    ,base_url=OLLAMA_HOST,
)

security.py
from datetime import datetime, timedelta, timezone
from typing import Optional

from fastapi.security import OAuth2PasswordBearer
from jose import jwt
from passlib.context import CryptContext

from app.core.config import JWT_SECRET_KEY, JWT_ALGORITHM, ACCESS_TOKEN_EXPIRE_MINUTES

pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="auth/login")

def hash_password(password: str) -> str:
    return pwd_context.hash(password)

def verify_password(plain_password: str, hashed_password: str) -> bool:
    return pwd_context.verify(plain_password, hashed_password)

def create_access_token(
    data: dict,
    expires_delta: Optional[timedelta] = None,
) -> str:
    to_encode = data.copy()
    expire = datetime.now(timezone.utc) + (
        expires_delta or timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
    )
    to_encode.update({"exp": expire})
    encoded_jwt = jwt.encode(to_encode, JWT_SECRET_KEY, algorithm=JWT_ALGORITHM)
    return encoded_jwt

db folder

from motor.motor_asyncio import AsyncIOMotorClient
from app.core import config as core_config

client = AsyncIOMotorClient(core_config.MONGO_URI)
db = client[core_config.MONGO_DB_NAME]

users_collection = db["users"]
notes_collection = db["notes"]
items_collection = db["items"]

depsFolder

auth.py
from typing import Optional, Annotated

from fastapi import Depends, HTTPException, status
from jose import JWTError, jwt

from app.core.config import JWT_SECRET_KEY, JWT_ALGORITHM
from app.core.security import oauth2_scheme, hash_password, verify_password
from app.db.mongo import users_collection
from app.schemas.user import UserInDB, UserCreate

async def get_user_by_email(email: str) -> Optional[UserInDB]:
    doc = await users_collection.find_one({"email": email})
    if not doc:
        return None
    return UserInDB(
        id=str(doc["_id"]),
        email=doc["email"],
        hashed_password=doc["hashed_password"],
    )

async def create_user(user: UserCreate) -> UserInDB:
    existing = await get_user_by_email(user.email)
    if existing:
        raise HTTPException(
            status_code=status.HTTP_400_BAD_REQUEST,
            detail="Email already registered",
        )
    hashed = hash_password(user.password)
    res = await users_collection.insert_one(
        {"email": user.email, "hashed_password": hashed}
    )
    return UserInDB(id=str(res.inserted_id), email=user.email, hashed_password=hashed)

async def get_current_user(
    token: Annotated[str, Depends(oauth2_scheme)]
) -> UserInDB:
    credentials_exception = HTTPException(
        status_code=status.HTTP_401_UNAUTHORIZED,
        detail="Could not validate credentials",
        headers={"WWW-Authenticate": "Bearer"},
    )
    try:
        payload = jwt.decode(token, JWT_SECRET_KEY, algorithms=[JWT_ALGORITHM])
        email: str = payload.get("sub")
        if email is None:
            raise credentials_exception
    except JWTError:
        raise credentials_exception

    user = await get_user_by_email(email)
    if user is None:
        raise credentials_exception
    return user

Routers folder

auth.py
from typing import Annotated

from fastapi import APIRouter, Depends, HTTPException, status
from fastapi.security import OAuth2PasswordRequestForm

from app.core.security import create_access_token, verify_password
from app.deps.auth import create_user, get_user_by_email, get_current_user
from app.schemas.user import UserCreate, UserPublic, Token, UserInDB

router = APIRouter(prefix="/auth", tags=["auth"])

@router.post("/register", response_model=UserPublic)
async def register(user: UserCreate):
    new_user = await create_user(user)
    return UserPublic(id=new_user.id, email=new_user.email)

@router.post("/login", response_model=Token)
async def login(form_data: Annotated[OAuth2PasswordRequestForm, Depends()]):
    # I am using email as the username field in the OAuth2 form.
    user = await get_user_by_email(form_data.username)
    if not user or not verify_password(form_data.password, user.hashed_password):
        raise HTTPException(
            status_code=status.HTTP_401_UNAUTHORIZED,
            detail="Incorrect email or password",
        )
    access_token = create_access_token(data={"sub": user.email})
    return Token(access_token=access_token)

@router.get("/me", response_model=UserPublic)
async def get_me(
    current_user: Annotated[UserInDB, Depends(get_current_user)]
):
    return UserPublic(id=current_user.id, email=current_user.email)

chat.py
from typing import Annotated

from fastapi import APIRouter, Depends
from langchain_core.messages import HumanMessage, SystemMessage

from app.core.llm import llm
from app.db.mongo import notes_collection
from app.deps.auth import get_current_user
from app.schemas.user import UserInDB
from app.schemas.chat import ChatRequest, ChatResponse

router = APIRouter(prefix="/chat", tags=["chat"])

@router.post("/", response_model=ChatResponse)
async def chat_with_ai(
    body: ChatRequest,
    current_user: Annotated[UserInDB, Depends(get_current_user)],
    # Uses LangChain + OpenAI + some context from MongoDB.
):
    print(current_user)

    notes_cursor = (
        notes_collection.find({"user_id": current_user.id})
        .sort("_id", -1)
        .limit(3)
    )
    notes = await notes_cursor.to_list(length=3)

    context_text = "\n".join(
        note.get("text", "") for note in notes if note.get("text")
    )
    used_context = bool(context_text)

    system_prompt = (
        "You are an assistant helping the user with their notes."
        " "
        "Use the following context if relevant; if not, just answer normally.\n\n"
        f"Context:\n{context_text or '(no context available)'}"
    )
    messages = [
        SystemMessage(content=system_prompt),
        HumanMessage(content=body.question),
    ]

    response = await llm.ainvoke(messages)

    return ChatResponse(answer=response.content, used_context=used_context)

items.py
from typing import List, Annotated

from fastapi import APIRouter, Depends

from app.db.mongo import items_collection
from app.schemas.item import Item
from app.schemas.user import UserInDB
from app.deps.auth import get_current_user

router = APIRouter(prefix="/items", tags=["items"])

@router.get("/", response_model=List[Item])
async def list_items(
    current_user: Annotated[UserInDB, Depends(get_current_user)]
):
    # Example async Mongo query using Motor.
    # Demo: seed items if collection is empty
    count = await items_collection.count_documents({})
    if count == 0:
        await items_collection.insert_many(
            [
                {"name": "Book", "price": 10.5},
                {"name": "Laptop", "price": 999.99},
            ]
        )

    docs = await items_collection.find().to_list(length=100)
    return [
        Item(id=str(doc["_id"]), name=doc["name"], price=float(doc["price"]))
        for doc in docs
    ]

notes.py
from typing import Annotated

from fastapi import APIRouter, Depends
from langchain_core.messages import HumanMessage, SystemMessage

from app.core.llm import llm
from app.db.mongo import notes_collection
from app.deps.auth import get_current_user
from app.schemas.user import UserInDB
from app.schemas.chat import ChatRequest, ChatResponse
from app.schemas.notes import NotesCreate, NotesInDB

router = APIRouter(prefix="/notes", tags=["notes"])

@router.post("/", response_model=NotesInDB)
async def create_note(body: NotesCreate,current_user: Annotated[UserInDB, Depends(get_current_user)]):
    print(current_user)

    note = await notes_collection.insert_one({"text": body.text, "user_id": current_user.id})
    return NotesInDB(id=str(note.inserted_id), text=body.text, user_id=current_user.id)

Main.py

from fastapi import FastAPI

from app.routers import auth, items, chat, notes

app = FastAPI(title="FastAPI + MongoDB + JWT + LangChain Example")

@app.get("/")
async def root():
    return {"message": "FastAPI + MongoDB + JWT + LangChain example"}

# Include routers
app.include_router(auth.router)
app.include_router(items.router)
app.include_router(chat.router)
app.include_router(notes.router)

Application execution

On the main folder, you can execute the following command:

uvicorn app.main:app --reload
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)

If you access the page http://127.0.0.1:8000/docs#, you can find the Swagger documentation created by default.

Users creation

You can execute the following command to create a new user:

curl -X 'POST' \
  'http://127.0.0.1:8000/auth/register' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "email": "user@example.com",
  "password": "string" 
}'

Or if you have vscode Rest Api Extension you can execute
POST http://127.0.0.1:8000/auth/register
Accept: application/json
Content-Type: application/json

{
  "email": "user@example.com",
  "password": "string"
}

The above command will create a new user with hashed password:

Users authentication

In order to authenticate the user and retrieve the bearer token, please execute the following command:

curl -X 'POST' \
  'http://127.0.0.1:8000/auth/login' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=password&username=user%40example.com&password=string&scope=&client_id=string&client_secret=string'
Rest API extension
POST http://127.0.0.1:8000/auth/login
Content-Type: application/x-www-form-urlencoded
accept: application/json

grant_type=password&username=test@example.com&password=123&scope=&client_id=string&client_secret=string

After a successful authentication, you will receive the following output. The token is important to authenticate on the remaining routes.

HTTP/1.1 200 OK
date: Tue, 02 Dec 2025 17:40:11 GMT
server: uvicorn
content-length: 180
content-type: application/json
Connection: close

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ0ZXN0QGV4YW1wbGUuY29tIiwiZXhwIjoxNzY0NzAwODExfQ.riXj1vvLZSyzyU4T7kG3ygYaUU8sgvgCjK_Os_uggvo",
  "token_type": "bearer"
}

Idea creation

The main purpose of the application is to make suggestions based on ideas that the end users have. The following request will create those notes.

POST http://127.0.0.1:8000/notes/
Content-Type: application/json
Authorization: Bearer {{token}}

{
  "text": "testing123"
}

Chat interaction

The application now offers advice based on the notes stored by users in the database. To enable interaction with the LLM, we define the chat's behavior in the chat.py file. This definition is an example of prompt engineering, and this is the section where you can modify the prompt's language and content, if needed.

system_prompt = (
        "You are an assistant helping the user with their notes."
        " "
        "Use the following context if relevant; if not, just answer normally.\n\n"
        f"Context:\n{context_text or '(no context available)'}"
    )

Execution example:

POST http://127.0.0.1:8000/chat/
Content-Type: application/json
Authorization: Bearer {{token}}

{
  "question": "What i need to do"
}

Execution output:

{
  "answer": "To help you achieve your goals of saving more money and finishing your project, here are some actionable steps:\n\n**Saving More Money:**\n\n1. **Track your expenses**: Write down every single transaction, no matter how small, for a week or two to understand where your money is going.\n2. **Create a budget**: Based on your income and expenses, allocate a specific amount for savings each month.\n3. **Automate your savings**: Set up an automatic transfer from your checking account to your savings account.\n4. **Cut back on unnecessary expenses**: Identify areas where you can cut back on unnecessary spending, such as dining out or subscription services.\n5. **Consider a savings challenge**: Try a savings challenge like the \"52-week savings challenge\" where you save an amount equal to the number of the week (e.g., Week 1: Save $1, Week 2: Save $2 etc.).\n\n**Finishing Your Project:**\n\n1. **Break down your project into smaller tasks**: Divide your project into manageable tasks to make it feel less overwhelming.\n2. **Create a schedule**: Set a specific deadline for each task and stick to it.\n3. **Prioritize your tasks**: Focus on the most critical tasks first, and then move on to less important ones.\n4. **Remove distractions**: Identify potential distractions (e.g., social media, email, phone notifications) and eliminate them while you work.\n5. **Take regular breaks**: Take short breaks to recharge and maintain productivity.\n\nWhich of these steps do you want to start with?",
"used_context": true
}

Docker (optional)

Our application is currently functional. However, to execute it in a different environment, we must install the necessary dependencies. Docker can facilitate and streamline this deployment process.

Create Dockerfile and paste the following code:

# Dockerfile
FROM python:3.11-slim

# Set work directory inside the container
WORKDIR /app

# Install system dependencies (optional but useful for many libs)
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

# Copy only requirements first (for better Docker cache)
COPY requirements.txt .

# Install Python dependencies
RUN pip install --no-cache-dir -r requirements.txt

# Copy the rest of your project
COPY . .

# Expose the FastAPI port
EXPOSE 8000

# Default command: run uvicorn
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Create the docker-compose.yml:

version: "3.8"
services:
  fastapi:
    build: .
    container_name: fastapi-langchain
    ports:
      - "8000:8000"
    env_file:
      - .env # optional: if you have one
    extra_hosts:
      - "host.docker.internal:host-gateway"
    restart: unless-stopped

Now, we can build and execute our docker:

docker-compose build
docker-compose up -d

Conclusion

This tutorial has provided a complete, practical demonstration of building a modern, data-driven application by seamlessly integrating FastAPI, LangChain, and MongoDB.

We have successfully covered:

FastAPI for creating a robust, fast, and documented REST API, including user registration and JWT-based authentication.
MongoDB (using Motor) for asynchronous and scalable document storage, handling user data and application-specific notes.
LangChain (with Ollama) for enabling powerful AI capabilities, using the stored user notes as dynamic context to generate personalized, helpful suggestions and answers.

The example application, an idea generation assistant, serves as a clear blueprint for how to leverage this stack for complex projects requiring data persistence, secure user access, and cutting-edge large language model integration. By using a local LLM via Ollama, we also ensured the entire stack is executable on a local machine, making it accessible for rapid prototyping and development.

This integration strategy—combining the speed of FastAPI, the flexibility of MongoDB, and the intelligence of LangChain—is a highly effective pattern for developing the next generation of intelligent web applications. We hope this guide serves as a solid foundation for your future AI-powered projects.

Day 5: I Almost Over-Engineered Everything

GraceSoft — Fri, 17 Apr 2026 08:47:41 +0000

At this point, GraceSoft Core was starting to take shape.

Architecture. Patterns. Principles.

Everything felt… solid.

And then I caught myself.

I was about to over-engineer the whole thing.

⚖️ The Tension

There’s always this trade-off:

Build it right vs
Build it fast

And I’ve been on both extremes before:

🚀 Too Fast

Hack things together
Ship quickly
Pay the price later

🧱 Too Perfect

Design everything upfront
Endless planning
Nothing actually ships

🤯 The Realisation

GraceSoft Core was at risk of becoming:

A system that’s beautifully designed… but never used.

💡 What Changed

I asked myself a different question:

“What’s the smallest version of this that actually works?”

Not:

Perfect architecture
Full feature set
Every edge case covered

Just:

Something real I can use in my current app.

🔑 New Principle

Build just enough core to remove friction — not all friction.

🚧 What I’m Focusing On Now

Instead of everything, I’m narrowing down to:

Auth (done properly once)
Basic integrations (Stripe, email)
Clean project structure
Reusable UI foundations

Everything else?

Can come later.

🧠 Honest Truth

I still feel the urge to overbuild.

To make it “complete”.

But I’m learning this:

A system becomes real when it’s used — not when it’s finished.