Forem

Beyond the Cloud: Mastering On-Device GenAI with MediaPipe and Gemini Nano on Android

Programming Central — Sat, 25 Apr 2026 10:00:00 +0000

The era of "Cloud-First" AI is facing a silent revolution. While GPT-4 and Claude 3 dominate the headlines, a significant shift is happening right in your pocket. Developers are moving away from the latency, cost, and privacy concerns of cloud-based LLMs toward a more sustainable, immediate, and private alternative: On-Device Generative AI.

With the release of the MediaPipe LLM Inference API and the integration of AICore in Android, Google has fundamentally changed how we build intelligent applications. We are moving from a world where every AI query required a round-trip to a data center to a world where your phone's silicon handles the heavy lifting.

In this guide, we will dive deep into the architecture, the science of model quantization, and the practical implementation of production-ready LLMs on Android using Kotlin 2.x.

The Architecture of On-Device Intelligence

To understand the MediaPipe LLM Inference API, we must first recognize the shift in Android’s architectural philosophy. Historically, deploying a machine learning model on Android was a manual, often painful process. You would bundle a .tflite file in your assets folder, ship it, and hope the user’s device had enough RAM to handle it.

This approach suffered from "binary bloat"—increasing APK sizes by hundreds of megabytes—and forced developers to manually manage hardware acceleration across a fragmented landscape of GPUs, NPUs, and DSPs.

The System-Level AI Provider Model

Google’s transition to AICore and Gemini Nano represents a move toward a System-Level AI Provider model.

Think of this like CameraX. Before CameraX, developers had to write custom code for thousands of different camera hardwares. CameraX provided a consistent API to abstract that complexity. AICore does the same for AI hardware (NPUs, GPUs, and TPUs). Instead of the application "owning" the model, the Android OS owns it. Your app simply requests the capability to perform inference.

Why the AICore Ecosystem Matters

AICore is a system service that manages the lifecycle, updates, and execution of Gemini Nano. This design choice is driven by three critical constraints:

Memory Footprint (VRAM/RAM): LLMs are notorious memory hogs. If five different apps each bundled their own 2GB LLM, the device would run out of memory instantly. By centralizing the model in AICore, the system shares a single instance across processes, managing loading and unloading with surgical precision.
Model Evolution: AI moves fast. By decoupling the model from the APK, Google can update Gemini Nano via Google Play System Updates. Your app gets smarter without you ever having to push a new version to the Play Store.
Hardware Optimization: Different chips (Google Tensor G3, Snapdragon 8 Gen 3) have different acceleration paths. AICore acts as the translation layer, ensuring the model runs on the most efficient silicon available on that specific device.

The "Room Database" Analogy

Think of initializing the LLM Inference API as being similar to a Room database migration. A migration is a heavy, one-time operation that ensures the schema is correct before the app can function. Similarly, loading an LLM into the NPU is a high-latency event. If you handle this on the Main Thread, you will trigger an Application Not Responding (ANR) error. This is why the modern AI stack on Android is designed to be asynchronous and lifecycle-aware from the ground up.

Gemini Nano and the Science of Quantization

How do you fit a model with billions of parameters onto a device that fits in your hand? The answer lies in Quantization.

Gemini Nano is a "distilled" version of the larger Gemini models. To make it mobile-friendly, Google employs quantization, specifically moving from FP32 (32-bit floating point) to INT4 (4-bit integer) weights.

Under the Hood: Why 4-bit?

In a standard LLM, every parameter is a weight. In FP32, each weight takes 4 bytes. A 3-billion parameter model would require roughly 12GB of RAM just to load the weights. That is more RAM than most flagship phones possess, leaving zero room for the OS or other apps.

By quantizing to 4-bit, we reduce the memory requirement to approximately 0.5 bytes per parameter. This shrinks the model size to between 1.5GB and 2GB. This is the "sweet spot" that allows the model to reside in RAM while leaving enough breathing room for the rest of the system.

The Trade-off: We lose some "nuance" or precision, but we gain the ability to run inference locally with millisecond latency. For tasks like summarization, smart reply, and proofreading, the trade-off is almost always worth it.

Mapping AI Concepts to Modern Kotlin 2.x

The MediaPipe LLM Inference API isn't just a C++ wrapper; it’s built for the reactive nature of modern Android development. To build a production-ready feature, we need to map AI behaviors to Kotlin's concurrency primitives.

1. Asynchronous Inference with Coroutines

LLM inference is a "blocking" operation in the sense that the GPU/NPU is working intensely. We must ensure this happens off the Main dispatcher. Using Dispatchers.Default is the correct choice here, as it signals to the system that we are performing heavy computational work rather than simple I/O.

2. Streaming Responses with `Flow`

Users hate waiting. If a user has to wait 5 seconds for a full paragraph to appear, the app feels broken. LLMs generate tokens one by one. By using Kotlin Flow<String>, we can stream these tokens to the UI in real-time, creating that "typing" effect that users have come to expect from AI interfaces.

3. State Management with Context Receivers

In Kotlin 2.x, we can use Context Receivers to ensure that prompt-building logic only executes within the context of an initialized LlmInference engine. This provides a compile-time safety net, preventing the dreaded "Model Not Loaded" errors at runtime.

Building the Production-Ready Implementation

Let’s look at how these concepts converge into a clean, Hilt-managed architecture. We will build a repository that handles the model lifecycle and a ViewModel that manages the UI state.

Step 1: Dependencies

Add the following to your build.gradle.kts. Note that the GenAI tasks are distinct from standard MediaPipe tasks.

dependencies {
    // MediaPipe LLM Inference
    implementation("com.google.mediapipe:tasks-genai:0.10.14")
    // Jetpack Compose & Lifecycle
    implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.7.0")
    implementation("androidx.lifecycle:lifecycle-runtime-compose:2.7.0")
    // Hilt for Dependency Injection
    implementation("com.google.dagger:hilt-android:2.50")
    kapt("com.google.dagger:hilt-android-compiler:2.50")
    // Kotlin Serialization
    implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.6.3")
}

Step 2: The LLM Repository (Hardware Orchestration)

The repository is a Singleton. Loading a model is expensive; we only want to do it once.

@Singleton
class LlmRepository @Inject constructor(
    @ApplicationContext private val context: Context
) {
    private var llmInference: LlmInference? = null

    // Initialize the engine. Think of this as your DB initialization.
    suspend fun initializeModel(modelPath: String) = withContext(Dispatchers.Default) {
        if (llmInference == null) {
            val options = LlmInference.LlmInferenceOptions.builder()
                .setModelPath(modelPath)
                .setMaxTokens(1024)
                .setTemperature(0.7f) // Randomness vs Determinism
                .setTopK(40)
                .build()

            llmInference = LlmInference.createFromOptions(context, options)
        }
    }

    /**
     * Generates a response using a Flow to stream tokens.
     */
    fun generateResponse(prompt: String): Flow<String> = flow {
        val engine = llmInference ?: throw IllegalStateException("Model not initialized")

        // Bridging MediaPipe's callback-based API to Kotlin Flow
        engine.generateResponse(prompt).let { result ->
            emit(result)
        }
    }.flowOn(Dispatchers.Default)

    fun close() {
        llmInference?.close()
        llmInference = null
    }
}

Step 3: The ViewModel (State Management)

The ViewModel uses the MVI (Model-View-Intent) pattern to handle the UI states: Idle, Loading, and Success.

@HiltViewModel
class LlmViewModel @Inject constructor(
    private val repository: LlmRepository
) : ViewModel() {

    private val _uiState = MutableStateFlow(LlmUiState())
    val uiState: StateFlow<LlmUiState> = _uiState.asStateFlow()

    fun onPromptSubmitted(prompt: String) {
        viewModelScope.launch {
            _uiState.value = _uiState.value.copy(isLoading = true, response = "")

            try {
                // Ensure model is loaded (usually done at app startup)
                repository.initializeModel("/data/local/tmp/gemini_nano.bin")

                repository.generateResponse(prompt).collect { partialResult ->
                    _uiState.value = _uiState.value.copy(
                        isLoading = false,
                        response = _uiState.value.response + partialResult
                    )
                }
            } catch (e: Exception) {
                _uiState.value = _uiState.value.copy(isLoading = false, error = e.message)
            }
        }
    }

    override fun onCleared() {
        super.onCleared()
        repository.close() // Crucial for preventing native memory leaks
    }
}

data class LlmUiState(
    val response: String = "",
    val isLoading: Boolean = false,
    val error: String? = null
)

Detailed Execution Flow: What Happens When You Click "Generate"?

Initialization: The LlmRepository is injected. When initializeModel is called, MediaPipe maps the model's weights into the GPU/NPU memory space. This is a native operation via JNI.
UI Trigger: The user clicks "Generate". The ViewModel launches a coroutine.
Context Switching: We switch to Dispatchers.Default. This is vital. LLM inference is a CPU/GPU-bound task. If you run this on the Main thread, your UI will freeze, and Android will kill your app.
The Forward Pass: The LlmInference engine takes the raw string, tokenizes it into integers, passes them through the neural network layers (the "forward pass"), and decodes the resulting tokens back into text.
State Propagation: As tokens are generated, the Flow emits them. The ViewModel updates the StateFlow, and Compose re-renders the text on the screen instantly.
Cleanup: When the user leaves the screen, onCleared() ensures the native memory handles are released.

Common Pitfalls and How to Avoid Them

Even with a great API, on-device AI is tricky. Here are the most common mistakes developers make:

1. Main Thread Blocking

This is the #1 cause of crashes. MediaPipe’s generateResponse is a synchronous, blocking call. You must wrap it in withContext(Dispatchers.Default).

2. Memory Overload (OOM)

LLMs are massive. If you try to load a 3B parameter model on a budget device with 4GB of total RAM, the OS will terminate your app to save itself. Always check device capabilities before attempting to load the model.

3. Incorrect Model Path

MediaPipe requires an absolute path. If you bundle your model in the assets folder, you must copy it to context.filesDir first. MediaPipe cannot read directly from the compressed APK asset stream.

4. Ignoring the Native Lifecycle

Since this API uses JNI, the Garbage Collector doesn't know about the 2GB of weights sitting in native memory. If you don't call .close(), you will leak memory until the OS restarts.

The Future: Local AI Summarizers

One of the most powerful use cases for this technology is the Local AI Summarizer. By providing a "System Prompt" (e.g., "Summarize the following text in 3 bullet points"), you can create highly specialized tools that work without an internet connection.

In a production environment, you would use Structured Prompting. Instead of passing raw user input, you wrap it in a template:

fun buildSummarizationPrompt(userInput: String): String {
    return """
        <|system|>
        You are a helpful assistant that summarizes text concisely.
        <|user|>
        Summarize this: $userInput
        <|assistant|>
    """.trimIndent()
}

This ensures the model remains consistent and doesn't "hallucinate" outside of its intended purpose.

Conclusion

On-device Generative AI is no longer a futuristic concept—it is a production-ready tool available today via MediaPipe and Gemini Nano. By understanding the architectural shift toward system-level providers and mastering the nuances of quantization and asynchronous Kotlin code, you can build apps that are faster, more private, and cheaper to operate than their cloud-dependent counterparts.

The transition from "AI in the Cloud" to "AI in your Pocket" is the next great frontier of mobile development. It’s time to start building.

Let's Discuss

Given the trade-off between model precision (FP32) and performance (INT4), what types of mobile applications do you think are least suited for on-device LLMs?
As AICore becomes a standard part of the Android OS, do you think developers will eventually stop using cloud AI APIs for basic text tasks entirely? Why or why not?

The concepts and code demonstrated here are drawn directly from the comprehensive roadmap laid out in the ebook
On-Device GenAI with Android Kotlin: Mastering Gemini Nano, AICore, and local LLM deployment using MediaPipe and Custom TFLite models. You can find it here: Leanpub.com or Amazon.
Check also all the other programming & AI ebooks with python, typescript, c#, swift, kotlin: Leanpub.com or Amazon.

How I Set Up Ollama With n8n and Brought My AI API Costs to Zero

Mahdi BEN RHOUMA — Sat, 25 Apr 2026 09:57:34 +0000

Home
Automation
How I Set Up Ollama With n8n and Brought My AI Costs to Zero

How I Set Up Ollama With n8n and Brought My AI API Costs to Zero

In December I opened my OpenAI billing dashboard and saw $54. Not because I'd built something impressive — because my n8n automations had been quietly calling the API thousands of times across several workflows, and the costs had crept up while I wasn't paying attention.

The automations were worth it. But $54/month purely for API calls to classify emails and summarize text felt wrong when I knew local models existed that could do the same thing.

I spent a weekend switching to Ollama. My January OpenAI bill was $0.

This post is the honest version of how that went — what worked immediately, what tripped me up, what I had to compromise on, and whether the quality difference is actually noticeable.

What I Was Using AI For in My Workflows

Before explaining the switch, it helps to know what I was actually using OpenAI for. My n8n workflows were calling GPT-3.5-turbo for:

Email classification: Is this email urgent, routine, or can I ignore it? (200-300 tokens per email, runs 30-40 times daily)
Document type detection: Is this a contract, invoice, receipt, or proposal? (runs on every PDF I receive)
Lead scoring summaries: Given this form submission, write a 2-sentence summary and suggest a follow-up priority
Weekly report drafting: Turn a list of completed tasks into natural language paragraphs

None of these required GPT-4. I was using GPT-3.5-turbo for everything, which is cheap — but cheap multiplied by hundreds of daily calls adds up.

The math: roughly 800 API calls per day × 500 average tokens × $0.002 per 1K tokens = ~$0.80/day = ~$24/month. Add some larger calls and occasional GPT-4 tests and you land at $50-60/month.

Installing Ollama

I have two machines I work from: a MacBook Pro M2 (32GB RAM) and a Windows desktop with an RTX 3080. I installed Ollama on both.

MacBook (Apple Silicon):

# Download from ollama.com or via Homebrew
brew install ollama

# Pull models
ollama pull llama3.1
ollama pull phi3

# Start the service
ollama serve

Ollama automatically uses the Apple Neural Engine and GPU on M-series chips. Performance is excellent — Llama 3.1 8B generates around 30-40 tokens per second on M2. Fast enough to feel instantaneous in a workflow.

Windows with NVIDIA GPU:
Download the installer from ollama.com. It detects your GPU automatically and uses CUDA. Same experience, similar performance.

After installation, test it:

# Chat directly
ollama run llama3.1

# Test the API
curl http://localhost:11434/api/generate \
  -d '{"model": "llama3.1", "prompt": "Classify this email as urgent or routine: Meeting at 3pm tomorrow?", "stream": false}'

If you see a response, you're ready.

The Docker Networking Problem

My n8n instance runs in Docker. When I set up the Ollama credential in n8n with http://localhost:11434, every AI node failed with a connection error.

The issue is obvious once you know it, but it cost me an hour: inside a Docker container, localhost refers to the container's own loopback address, not the host machine. The Ollama server running on my Mac was invisible to the n8n container.

Fix on Mac/Windows:

Docker Desktop automatically creates a special hostname host.docker.internal that resolves to the host machine's IP. Change your Ollama credential in n8n from:

http://localhost:11434

to:

http://host.docker.internal:11434

That's it. Saved and tested — the connection worked immediately.

Fix on Linux (where host.docker.internal isn't automatic):

Add this to your docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n
    extra_hosts:
      - "host.docker.internal:host-gateway"
    # ... rest of config

Or find your host's Docker bridge IP (172.17.0.1 on most systems) and use that directly.

Setting Up the n8n Credential

In n8n, go to Settings → Credentials → New. Search for "Ollama".

Fields:

Base URL: http://host.docker.internal:11434
Name it: "Local Ollama"

Save. Then in any AI node, select "Ollama" as the provider and "Local Ollama" as the credential.

Replacing Each Workflow — What Happened

Email Classification

Before (OpenAI):

Model: gpt-3.5-turbo
Prompt: "Classify this email as urgent/routine/ignore. Return JSON: {category, reason}"
Average response time: 800ms
Cost: ~0.001 per call

After (Ollama / Llama 3.1 8B):

Model: llama3.1
Same prompt
Average response time: 1.2 seconds (local, M2 Mac)
Cost: $0

Quality difference: Essentially none for this task. Llama 3.1 8B classifies emails correctly about 94-96% of the time in my testing, compared to GPT-3.5-turbo at around 96-97%. The 2% difference means maybe one misclassified email per week. Completely acceptable.

Document Type Detection

After switch quality: Very good. The model correctly identifies invoice/contract/receipt/proposal 97%+ of the time when I give it the first page of text. Better than I expected, honestly.

One thing I had to change: my prompt for OpenAI could be relatively loose. Local models respond better to more explicit, structured prompts.

OpenAI prompt (loose):

What type of document is this? Invoice, contract, receipt, or proposal?
[document text]

Ollama prompt (structured):

You are a document classification assistant. Analyze the document text below and 
identify its type.

IMPORTANT: Respond with ONLY a valid JSON object. No explanation. No markdown.

Format: {"type": "invoice|contract|receipt|proposal|other", "confidence": "high|medium|low"}

Document text:
[document text]

The more explicit instruction to return valid JSON was necessary. GPT-3.5 would usually return JSON without being told. Llama 3.1 8B needed the instruction reinforced. Once I updated my prompts, the outputs were reliable.

Lead Scoring Summaries

This one was trickier. The task involves some nuanced judgment — reading a form submission and writing a professional 2-sentence summary that captures the key details and suggests a follow-up priority.

My honest assessment: GPT-3.5 wrote better summaries. The language was more natural, the summaries were more insightful, and it made better judgment calls about priority.

Llama 3.1 8B was fine — the summaries were accurate and useful — but they had a slightly more mechanical feel. For internal workflow use where I'm the only one reading them, it's completely adequate. If these summaries were going to clients, I'd use GPT-4.

I kept this workflow on Ollama but added a "review" flag for any lead scored above a certain threshold, where I personally review the AI summary before using it.

Weekly Report Drafting

This was the biggest quality gap. Report writing requires fluent prose and the ability to weave a coherent narrative from a list of completed tasks. Llama 3.1 8B produced grammatically correct text that covered all the facts, but it lacked the natural flow that GPT-4 could produce.

For this specific workflow, I switched from Ollama to a compromise: I use Ollama for the data aggregation and structuring step (which is mechanical), and GPT-4 for the final prose generation step (which benefits from the quality difference). This reduced my OpenAI costs by about 80% for this workflow while keeping the output quality high.

My Current Model Setup

After a month of testing, here's what I actually use:

Task	Model	Reason
Email classification	Phi-3 Mini	Fast, accurate enough, very low resource
Document detection	Llama 3.1 8B	Good accuracy, handles longer text
Data extraction from docs	Llama 3.1 8B	Good JSON output with proper prompts
Lead summaries	Llama 3.1 8B	Adequate quality for internal use
Report prose writing	GPT-4 (via API)	Quality matters, small volume
Research summaries	Llama 3.1 70B (server)	Better reasoning, justify the resource use

The 70B model runs on a rented GPU server (Lambda Labs, used only for batch jobs), not my laptop. For occasional heavy tasks it's cost-effective — a few dollars for an hour of GPU time is far less than equivalent GPT-4 API calls.

What My Costs Look Like Now

Before switch:

OpenAI API: ~$54/month
n8n VPS: €3.79/month
Total: ~$59/month

After switch:

OpenAI API: ~$4/month (only report prose writing, low volume)
n8n VPS: €3.79/month
Lambda Labs (occasional): ~$2/month average
Total: ~$10/month

Monthly savings: ~$49

Annual savings: ~$588.

Would I Recommend This?

Yes, with these caveats:

Do it if:

Your AI workflows run high volumes (100+ calls per day)
You're processing sensitive data that shouldn't leave your network
Your tasks are classification, extraction, or structured output generation
You have decent hardware (16GB RAM minimum, GPU helps a lot)

Think carefully if:

You need GPT-4-level prose quality in client-facing outputs
Your hardware is old or underpowered (CPU-only inference is slow)
You're doing tasks that require broad world knowledge or nuanced reasoning

The middle path (what I do): Use Ollama for the bulk of high-volume, mechanical tasks. Keep a minimal OpenAI subscription for the small percentage of tasks where quality genuinely matters. You get most of the cost savings with minimal quality compromise.

Frequently Asked Questions

Does Ollama work as well as OpenAI GPT-4 for n8n automations?

For most automation tasks — classification, summarization, data extraction — Llama 3.1 8B performs at roughly GPT-3.5 quality, sufficient for the vast majority of workflow automation. For complex reasoning or nuanced writing, GPT-4 still has an edge. Many users run Ollama for 90% of tasks and keep OpenAI as a fallback for the other 10%.

Can I run Ollama on a VPS server without a GPU?

Yes. On a Hetzner CX31 (4 vCPU, 8GB RAM, €8/month), Llama 3.1 8B runs at about 3-5 tokens per second — slow but functional for background automations. CPU-only is fine for overnight batch jobs. For real-time workflows, GPU or Apple M-series is much better.

How do I connect n8n in Docker to Ollama on the host machine?

Use host.docker.internal instead of localhost. In your n8n Ollama credential, set Base URL to http://host.docker.internal:11434. On Linux, add --add-host=host.docker.internal:host-gateway to your Docker run command.

Which Ollama model should I start with for n8n automation?

Start with Llama 3.1 8B (ollama pull llama3.1). It handles the majority of automation tasks well. If too slow, try Phi-3 Mini. If quality is insufficient for specific tasks, try Mistral 7B or Llama 3.1 70B if your hardware supports it.

Originally published at https://iloveblogs.blog

How to Get Historical Stock Data for Free with Python (and Actually Use It)

Kevin Meneses González — Sat, 25 Apr 2026 09:51:28 +0000

Most people searching for free stock data end up in the same loop.

They find Yahoo Finance. The yfinance library seems perfect — until it breaks in production, returns inconsistent data, or silently changes its response format because it's scraping an unofficial endpoint.

Then they try pandas-datareader. Then Alpha Vantage with a key that throttles after 5 requests per minute. Then a random GitHub repo with 200 stars and no commits since 2022.

If you're:

building a backtesting engine,
training a financial ML model,
or just trying to get clean OHLCV data without paying enterprise prices,

this matters.

The real problem isn't that free historical stock data doesn't exist. It's that most free options are brittle — they work in a Jupyter notebook and fail the moment you put them in a real project.

Why Unofficial APIs Break (and What to Use Instead)

yfinance is the most-used Python library for historical stock data. It's also reverse-engineered from Yahoo Finance's internal API — which means Yahoo can break it without notice, and they do.

Here's what developers typically run into:

Responses return None on tickers that worked yesterday
Rate limits hit without clear error messages
Adjusted close calculations differ from official sources
No support, no SLA, no guarantee of tomorrow

It's fine for quick experiments. It's not fine for anything you're shipping.

The alternative is using an API designed for developers — with documented endpoints, stable JSON responses, and a free tier that's actually functional.

That's exactly what EODHD gives you.

What Is EODHD and What's Free

EODHD (End of Day Historical Data) is a financial data API covering 150,000+ tickers across 60+ global exchanges, including US stocks, ETFs, crypto, forex, and indices. It's been running for over 7 years with 24/7 live support.

The free plan gives you:

20 API calls per day — no credit card required
End-of-day OHLCV data for any ticker in the past year
Access to the full ticker universe (not just a handful of symbols)
A demo key that works immediately for AAPL.US, TSLA.US, AMZN.US, BTC-USD, and EUR-USD — useful for testing your code before registering

For developers building and testing locally, 20 calls/day is enough to pull a year of daily data for multiple tickers and validate your entire pipeline before upgrading.

👉 Get your free EODHD API key here — no credit card, instant access.

Getting Historical Stock Data in Python: Step by Step

All examples below use only requests and pandas — no custom library needed. Just your API key and standard Python.

1. The base request

import requests
import pandas as pd

API_KEY = "YOUR_API_KEY"  # get yours free at eodhd.com/register

def get_eod(ticker, start, end):
    url = f"https://eodhd.com/api/eod/{ticker}"
    params = {
        "api_token": API_KEY,
        "fmt": "json",
        "from": start,
        "to": end,
        "order": "a"   # ascending — oldest first
    }
    response = requests.get(url, params=params)
    response.raise_for_status()
    df = pd.DataFrame(response.json())
    df["date"] = pd.to_datetime(df["date"])
    df = df.set_index("date")
    return df

# Fetch one year of daily OHLCV for Apple
df = get_eod("AAPL.US", "2024-01-01", "2024-12-31")
print(df.head())

Output:

            open    high     low   close  adjusted_close      volume
date
2024-01-02  185.47  186.03  183.61  185.17  184.23          79013800
2024-01-03  183.80  184.40  182.00  184.25  183.33          55153200
2024-01-04  182.15  183.09  180.63  181.23  180.32          53307100

The response includes both raw close and adjusted_close — already corrected for splits and dividends. That field is the one you should always use for returns, backtesting, and ML features. Raw close without adjustment produces incorrect results around stock split events, and it's a silent bug that's easy to miss.

2. Build a multi-ticker price matrix

tickers = ["AAPL.US", "MSFT.US", "GOOGL.US", "NVDA.US"]
frames = {}

for ticker in tickers:
    df = get_eod(ticker, "2024-01-01", "2024-12-31")
    frames[ticker] = df["adjusted_close"]

prices = pd.DataFrame(frames)
print(prices.tail(3))

Output:

            AAPL.US   MSFT.US   GOOGL.US  NVDA.US
date
2024-12-26  258.60    432.10    192.34    134.25
2024-12-27  255.42    428.78    190.11    131.88
2024-12-28  253.12    426.45    189.08    129.64

3. Compute returns and volatility

# Daily returns
returns = prices.pct_change().dropna()

# Annualized volatility (252 trading days)
volatility = returns.std() * (252 ** 0.5)
print("Annualized Volatility:")
print(volatility.round(4))

# Cumulative return over the period
cumulative = (1 + returns).prod() - 1
print("\nCumulative Return 2024:")
print((cumulative * 100).round(2))

Output:

Annualized Volatility:
AAPL.US     0.2341
MSFT.US     0.2019
GOOGL.US    0.2678
NVDA.US     0.5812

Cumulative Return 2024:
AAPL.US      30.12
MSFT.US      17.84
GOOGL.US     35.47
NVDA.US     171.20

From here you can build correlation matrices, Sharpe ratios, or any portfolio analytics layer you need. The data is clean enough that none of this requires sanitization first. That's rare with free sources.

Why Data Quality Is Not a Detail — It's the Foundation

Here's something most tutorials skip entirely.

A backtesting model running on bad data doesn't tell you your strategy is wrong. It tells you the data is wrong. And you won't know which one it is until you've spent days debugging a problem that never existed in the first place.

Bad stock data comes in predictable forms.

Unadjusted splits. Apple did a 4:1 split in August 2020. If your data doesn't account for that, you'll see a sudden 75% price drop in your chart. Your model will flag it as a crash event. Your backtester will generate a massive false signal. Everything downstream breaks — quietly.

Survivorship bias. Many free datasets only include companies that still exist. Lehman Brothers, Enron, Bear Stearns — gone from the index, gone from the data. If your training set only has survivors, your model learns from a market that never actually existed. The result: systematically overoptimistic backtests that fall apart in live trading.

Timezone mismatches. A closing price timestamped ambiguously — UTC vs exchange local time — puts data from different sessions in the same row when you join two sources. This is the kind of bug that corrupts results in a way that's nearly impossible to catch visually.

Missing trading days. Some free sources skip market holidays or return empty rows instead of omitting those dates cleanly. A moving average computed across a gap behaves differently than one across a clean series — and the difference shows up as noise in your signals.

EODHD addresses all of these directly. Adjusted close prices are normalized for splits and dividends. Data gaps follow exchange convention. Timestamps are consistent. And the data is sourced from multiple providers and cross-validated — the same institutional-grade pipeline that powers financial products, accessible through a simple REST endpoint.

This is the difference between data that looks fine in a notebook and data you can actually trust in production.

Advanced Use Cases

Use Case 1: Correlation matrix for portfolio analysis

Understanding how assets move together is core to portfolio construction. A correlation matrix built on dirty data produces misleading diversification signals.

import matplotlib.pyplot as plt

# Daily returns matrix (already computed above)
corr = returns.corr()

fig, ax = plt.subplots(figsize=(7, 5))
im = ax.imshow(corr, cmap="coolwarm", vmin=-1, vmax=1)
plt.colorbar(im, ax=ax)

labels = [t.split(".")[0] for t in corr.columns]
ax.set_xticks(range(len(labels)))
ax.set_yticks(range(len(labels)))
ax.set_xticklabels(labels)
ax.set_yticklabels(labels)

for i in range(len(corr)):
    for j in range(len(corr)):
        ax.text(j, i, f"{corr.iloc[i, j]:.2f}", ha="center", va="center", fontsize=9)

plt.title("Return Correlation Matrix — 2024")
plt.tight_layout()
plt.savefig("correlation_matrix.png", dpi=150)

This outputs a clean matrix you can drop into a report or feed into mean-variance optimization. The correlation between NVDA and the other tech names in 2024 tells a clear story about factor exposure — something that only shows up cleanly with adjusted, consistent prices.

Use Case 2: RSI indicator from scratch

The Relative Strength Index (RSI) is one of the most common momentum indicators. Building it from raw OHLCV data — rather than relying on a TA library — gives you full control over the calculation and forces you to validate the underlying data at each step.

def compute_rsi(series, period=14):
    delta = series.diff()
    gain = delta.clip(lower=0)
    loss = -delta.clip(upper=0)
    avg_gain = gain.ewm(com=period - 1, min_periods=period).mean()
    avg_loss = loss.ewm(com=period - 1, min_periods=period).mean()
    rs = avg_gain / avg_loss
    return 100 - (100 / (1 + rs))

df = get_eod("AAPL.US", "2024-01-01", "2024-12-31")
df["rsi_14"] = compute_rsi(df["adjusted_close"])

overbought = df[df["rsi_14"] > 70][["adjusted_close", "rsi_14"]]
oversold   = df[df["rsi_14"] < 30][["adjusted_close", "rsi_14"]]

print("Overbought periods:")
print(overbought.head())

print("\nOversold periods:")
print(oversold.head())

Output:

Overbought periods:
            adjusted_close  rsi_14
date
2024-03-05          169.12   71.34
2024-07-15          234.40   72.81

Oversold periods:
            adjusted_close  rsi_14
date
2024-04-19          165.00   28.42
2024-08-05          209.82   27.19

Clean adjusted prices matter here. If the data has a split event that isn't properly adjusted, the RSI values around that date will be meaningless — the price delta will look like a 75% single-day move and RSI will spike to extreme values for days, producing phantom overbought/oversold signals.

Use Case 3: Backtesting a moving average crossover

A classic entry point into systematic trading: go long when the 20-day SMA crosses above the 50-day, exit when it crosses back below.

df = get_eod("MSFT.US", "2023-01-01", "2024-12-31")

df["sma20"] = df["adjusted_close"].rolling(20).mean()
df["sma50"] = df["adjusted_close"].rolling(50).mean()

# Signal: 1 = long, 0 = flat
df["signal"]   = (df["sma20"] > df["sma50"]).astype(int)
df["position"] = df["signal"].shift(1)  # shift to avoid look-ahead bias

# Compare strategy vs buy-and-hold
df["market_return"]   = df["adjusted_close"].pct_change()
df["strategy_return"] = df["market_return"] * df["position"]

cumulative = df[["market_return", "strategy_return"]].dropna().cumsum()
cumulative.apply(lambda x: (1 + x).cumprod() - 1).plot(
    title="SMA Crossover vs Buy & Hold — MSFT 2023–2024",
    figsize=(10, 5)
)
plt.ylabel("Cumulative Return")
plt.tight_layout()
plt.savefig("backtest_result.png", dpi=150)

Note the shift(1) on the position — this prevents the strategy from using today's signal to trade at today's close, which would be look-ahead bias. Small detail. Large impact on results.

Two years of clean daily OHLCV. One API call. No parsing gymnastics.

Use Case 4: Multi-asset momentum ranking

Momentum strategies rank assets by recent return and rotate into top performers. This requires consistent, clean historical data across all assets in the universe — a place where data quality failures compound fast.

universe = [
    "AAPL.US", "MSFT.US", "GOOGL.US", "NVDA.US",
    "AMZN.US", "META.US", "TSLA.US", "JPM.US"
]

frames = {}
for ticker in universe:
    df = get_eod(ticker, "2024-01-01", "2024-12-31")
    frames[ticker] = df["adjusted_close"]

prices = pd.DataFrame(frames)

# 3-month momentum (~63 trading days)
momentum = prices.pct_change(63).iloc[-1].sort_values(ascending=False)

print("3-Month Momentum Ranking — end of 2024:")
print((momentum * 100).round(2).to_string())

Output:

3-Month Momentum Ranking — end of 2024:
NVDA.US     42.18
META.US     31.04
GOOGL.US    18.77
AAPL.US     12.43
AMZN.US     11.89
MSFT.US      8.21
TSLA.US      6.44
JPM.US       4.12

This ranking, run monthly on a broader universe, is the core of a momentum rotation strategy. The output is only as reliable as the price data underneath it. One ticker with a bad split adjustment skews the entire ranking.

Free vs Paid: What Changes When You Upgrade

Feature	Free (20 calls/day)	From $19.99/mo
Historical depth	1 year	30+ years
Daily call limit	20	100,000
Real-time WebSocket	❌	✅ (from $29.99)
Intraday data (1m, 5m)	❌	✅
Fundamental data (P/E, EPS)	❌	✅
Bulk exchange download	❌	✅
Crypto + Forex + ETFs	Limited	Full coverage
Splits & dividends history	1 year	Full history

For prototyping and learning, the free tier is genuinely enough. When you need production depth — multi-year histories, intraday resolution, or fundamentals for DCF models — the starter plan at $19.99/mo gives you 100,000 calls/day and removes every limitation that matters.

FAQs

❓ Is EODHD really free, or is there a catch?
✅ The free plan is real — 20 API calls per day after registration, no credit card required. There's also a demo key (no registration needed) limited to a handful of tickers like AAPL.US and TSLA.US, useful for testing your code structure before committing. The limitation is depth: the free tier returns data for the past year only, and 20 calls/day means you need to be deliberate about what you pull.

❓ How does EODHD compare to yfinance for historical data?
✅ EODHD is a purpose-built API with documented endpoints, stable JSON, and official support. yfinance scrapes Yahoo Finance's internal interface and breaks without warning. For anything beyond personal experiments, EODHD is significantly more reliable. It also returns adjusted close prices that match official exchange records, which yfinance sometimes gets wrong around split events — a silent error that corrupts backtest results.

❓ Do I need to install any special library to use EODHD with Python?
✅ No. All you need is requests and pandas — both are standard in any Python data environment. The EODHD REST API returns clean JSON that converts to a DataFrame in one line. No additional SDK required.

❓ Can I get historical data for international stocks, not just US?
✅ Yes. EODHD covers 60+ global exchanges. Tickers follow the format SYMBOL.EXCHANGE — for example, BARC.LSE for Barclays on the London Stock Exchange, or BMW.XETRA for BMW on Xetra. Non-US exchanges are covered from 2000 onward on most plans.

❓ Why does adjusted close matter so much for backtesting?
✅ When a company does a stock split, the raw price drops proportionally — a 4:1 split makes a $400 stock appear to close at $100 the next day. Without adjustment, your model sees a 75% single-day loss that never happened. Adjusted close normalizes all past prices to account for splits and dividends, giving you a historically continuous series that's valid for returns calculations.

❓ How many years of historical data can I get for free?
✅ The free plan returns up to 1 year of end-of-day historical data per ticker. Paid plans starting at $19.99/mo unlock 30+ years for US stocks (some tickers go back to 1972) and 20+ years for international markets.

❓ Can I use EODHD for crypto historical data too?
✅ Yes. EODHD covers 2,600+ crypto pairs. The endpoint format is the same — for Bitcoin in USD, use BTC-USD. The free plan gives access to 1 year of daily crypto OHLCV. Historical crypto data goes back to the asset's origin on paid plans.

❓ Is the free tier suitable for machine learning projects?
✅ It depends on your dataset size. 20 calls/day means you can pull 20 full-year price histories per day — enough to build and validate a model on a focused universe. For larger training sets spanning hundreds of tickers or multiple years, a paid plan is more practical. The free tier is ideal for development and prototyping.

Closing

Most developers waste weeks on brittle workarounds for something that should take an afternoon.

Clean, adjusted, production-grade historical stock data is not a premium feature. It's the minimum requirement for any analysis you'd trust with a real decision.

EODHD gives you that foundation for free — and a clear upgrade path when your project outgrows it.

👉 Get your free EODHD API key — 20 calls/day, no credit card, instant access.

Looking for technical content for your company? I can help — LinkedIn · kevinmenesesgonzalez@gmail.com

Beyond ERC-4337: Ethereum’s Transition into a Programmable Trust Layer

Ankita Virani — Sat, 25 Apr 2026 09:50:30 +0000

The misconception that quietly breaks real systems

Most engineers still think Ethereum is improving along familiar axes:

cheaper gas
better wallets
improved UX

That framing is shallow.

What is actually happening is structural:

Ethereum is separating who validates, who pays, who executes, and who proves

Once those responsibilities decouple:

a “transaction” stops being a primitive
it becomes a programmable pipeline

This shift is not incremental.
It changes how systems are designed, verified, and trusted.

Reconstructing Ethereum as a system

Instead of thinking in features, anchor on layers:

Ethereum = {
  Execution Layer
  Commitment Layer
  Verification Layer
}

Execution → computes state transitions
Commitment → compresses state into cryptographic structure
Verification → proves correctness of execution

Most engineers study these in isolation.

That is a mistake.

The real system emerges from how these layers interact.

ERC-4337 is not account abstraction

ERC-4337 is widely misunderstood.

It is not:

a wallet upgrade
a UX improvement

It is:

a contract-based execution engine that replaces protocol-level transaction validation

This is a fundamental shift in where logic lives.

From transactions to execution pipelines

Legacy model

User → sign transaction → protocol validates → execute

Rigid. Non-programmable. Single path.

New model

User → UserOperation → Bundler → EntryPoint
     → validateUserOp()
     → execute()

Now execution becomes:

Execution = Validation + Execution

That separation is everything.

The hidden constraint: deterministic validation

Most failures in ERC-4337 systems happen here.

Validation must be:

deterministic
simulation-safe
independent of external state

Forbidden patterns:

block.timestamp
block.number
dynamic balance reads
external contract dependencies

Why this matters:

Bundlers simulate execution before including it on-chain

If your validation diverges:

the transaction is dropped
the bundler loses money
your system becomes unreliable

This is not theoretical. This is where production systems break.

Execution phase: full power, full liability

Once validation passes:

full EVM execution is allowed
arbitrary DeFi interactions
cross-contract calls

But:

failure still consumes gas

So execution is not just computation. It is economic exposure.

Gas is not a fee. It is risk.

Most developers treat gas as cost.

Wrong model.

Total Gas = Validation + Execution + Overhead

But for bundlers:

Gas = capital at risk

If estimation is wrong:

execution fails
bundler absorbs loss

This creates a new class of system design constraints:

predictable execution paths
bounded gas usage
defensive validation

Paymasters: decoupling who pays

The introduction of Paymasters changes the economic model entirely.

They enable:

gasless UX
token-denominated fees
sponsored transactions

But they also introduce:

new attack surfaces
griefing vectors
economic exploits

Common failure modes:

Attack Type	Root Cause	Mitigation Strategy
Gas draining	Cheap validation paths	Strict gas caps
Replay	Weak domain design	Domain separation
Reentrancy	Unsafe postOp logic	CEI pattern

Changing who pays changes the entire security model.

Smart accounts: identity becomes programmable

Smart accounts replace EOAs.

They enable:

multisig policies
session keys
social recovery
passkey-based authentication

But they introduce:

complexity that shifts bugs from protocol layer to application layer

This is not simplification.
This is moving responsibility to developers.

Signature evolution: from static to programmable

Current state

ECDSA signatures
fixed verification logic

With ERC-4337

custom validation logic
multi-sig schemes
WebAuthn integration

Emerging direction

BLS aggregation
zk-based authentication

Trade-off:

Property	Benefit	Cost
Aggregation	O(1) verification	Infra complexity
zk-auth	Privacy + proofs	Prover overhead

ERC-7702: collapsing the migration barrier

ERC-7702 changes the adoption curve.

Before

EOA → deploy smart account → migrate

After

EOA → temporary programmable execution

Impact:

no migration friction
backward compatibility preserved
faster ecosystem adoption

This is a bridge between legacy accounts and programmable execution.

Modular accounts: identity as composition

The direction is clear:

Account = Core + Modules

Modules define:

authentication
execution logic
policy constraints

This leads to:

composable identity systems

But also:

fragmented standards and integration complexity

The convergence: execution, commitment, verification

This is not just blockchain anymore.

This is:

a system that computes and proves state transitions

ZK systems change the endgame

Zero-knowledge proof systems require:

deterministic execution
efficient state commitments

ERC-4337 provides:

programmable validation
flexible execution paths

Together:

execution becomes programmable
verification becomes provable

Future flow: programmable + provable systems

User (Passkey)
 ↓
Smart Account
 ↓
Batched Execution
 ↓
ZK Rollup
 ↓
State Commitment (Verkle)
 ↓
Proof to L1

At that point:

Ethereum becomes a verification layer
not the primary execution engine

When ERC-4337 is the wrong choice

Be honest about trade-offs.

Use Case	Better Approach
High-frequency trading	EOA
Simple transfers	EOA
Consumer apps	ERC-4337
ZK-native systems	4337 + ZK

If you use it everywhere, you’re overengineering.

What most engineers still miss

They study:

Merkle structures
account abstraction
ZK proofs

Separately.

That leads to fragmented understanding.

The real system is:

execution + commitment + verification interacting continuously

Final perspective

Ethereum is not evolving in features.

It is evolving in how it defines:

execution
identity
verification

That leads to a deeper conclusion:

Ethereum is becoming a programmable trust layer

Not just a place to run contracts.
A system that defines how truth is computed, encoded, and proven.

Offline React Native Apps: How to Cache Files That Must Open Without Network

running squirrel — Sat, 25 Apr 2026 09:41:36 +0000

If you search for “offline React Native,” you will find a lot of guidance about images, lists, and optimistic UI. That is useful, but it often misses the assets that actually stop work in the field: PDFs, JSON manifests, small binaries, audio clips, and other HTTP-hosted files your app must open right now, even when connectivity is unreliable.

One of the best libraries for that specific “cache downloads to disk, open them later” capability is react-native-nitro-cache with it's simplistic api anyone can use easily.

This post is about that second category: file caching for offline-capable React Native apps.

Why “offline React Native” advice often skips the hard part

Most offline guidance optimizes what users see immediately: scrolling, perceived speed, optimistic updates. That matters, but field workflows also depend on what users can open from storage when the network disappears.

Operational apps tend to fail for file reasons, not layout reasons:

a PDF checklist did not download before the technician walked into a basement
a rules manifest is stale after a midnight policy change
a small binary or audio instruction is missing when the user is already offline

What you want in those situations is not a prettier loading state. You want a predictable HTTP file cache with explicit freshness and cleanup tools.

That is the shape of problem a file cache is meant to solve: downloads you can treat as local files, with TTL, forced refresh, and simple ways to inspect and clean up what is on disk—so your app can open operational assets offline, not only render UI faster.

The offline-first file workflow

Think in layers:

Prefetch the critical path while the user still has good connectivity (login, sync screen, “prepare for today” action).
Serve from disk during the session using stable local file paths.
Revalidate on a schedule using TTLs that match how often each asset class changes.
Force refresh when the server says “this version is invalid” (feature flags, emergency policy updates).
Observe and prune using cache stats/entries so support and QA can reason about what is on-device.

This maps cleanly to the react-native-nitro-cache primitives:

getOrFetch(url, options?) — return a valid cached file or download it
get(url) — read-through without downloading
has(url) — fast synchronous membership check against the in-memory index
getBuffer(url) — read bytes into an ArrayBuffer for small in-memory consumers
remove(url) / clear() — targeted invalidation vs nuclear reset
getStats() / getEntries() — operational visibility

Example: different TTLs for different file classes

In real apps, “freshness” is not one number. Treat manifests, templates, and media differently.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function cacheManifest(url: string) {
  // Changes frequently: short TTL 10mins
  return rnNitroCache.getOrFetch(url, { ttl: ttl: 60 * 10 });
}

export async function cachePdfTemplate(url: string) {
  // Changes rarely: longer TTL 7days
  return rnNitroCache.getOrFetch(url, { ttl: 60 * 60 * 24 * 7 });
}

When an entry is returned, you typically care about:

url: absolute on-disk path you can hand to viewers/players
contentType: useful for routing and validation
size: useful for UI and telemetry
expiresAt: 0 if the entry has no TTL; otherwise the expiry instant in milliseconds since epoch

Example: parse cached JSON without inventing a parallel storage system

For small JSON blobs, getBuffer can be convenient if your consumer wants bytes in JS.

import { rnNitroCache } from 'react-native-nitro-cache';

export async function readCachedJson(url: string) {
  const buf = await rnNitroCache.getBuffer(url);
  if (!buf) return null;

  const text = new TextDecoder().decode(buf);
  return JSON.parse(text) as unknown;
}

Invalidation that matches real product events

Offline support is not only “store more.” It is also “remove the right things at the right time.”

Common triggers:

User logs out → clear() if your policy requires wiping cached HTTP assets from the device
Tenant/workspace switch → clear() or selective remove(url) for tenant-scoped URLs
Server publishes a new bundle version → getOrFetch(url, { forceRefresh: true }) for the entry points that must update immediately

Observability: treat the cache as part of your release story

If you have ever debugged “it works on Wi‑Fi,” you know the missing ingredient is visibility.

import { rnNitroCache } from 'react-native-nitro-cache';

const stats = await rnNitroCache.getStats();
console.log('cache entries:', stats.totalEntries, 'bytes:', stats.totalSize);

const entries = await rnNitroCache.getEntries();
console.log(entries.map(e => ({ path: e.url, type: e.contentType, bytes: e.size })));

This is valuable for:

QA scripts (“did we prefetch the manifest?”)
internal diagnostics screens
coarse “disk budget” warnings before downloads

Installation and platform reality (so your readers do not get stuck)

What I would emphasize in a Medium conclusion

Offline React Native is getting more attention because teams are shipping more serious mobile workflows. But it is not just "more caching", it is the right kind of caching:

operational files you can open from disk under poor connectivity
explicit freshness (TTL) and forced refresh paths
disk-first retrieval for large assets
targeted invalidation and introspection APIs

If your roadmap includes offline inspections, offline forms, offline training content, or any “must open on-site” PDFs and manifests, a general-purpose file cache belongs in your architecture review alongside your sync and persistence strategy.

Repo link

To learn more about the library checkout it's repository on GitHub

Our Indie Horror Journey: Passion Over Perfection

Mattia Santangelo — Sat, 25 Apr 2026 09:41:15 +0000

Ottima idea. Per rendere il post su DEV.to davvero "possente", dobbiamo trasformare il fatto che i modelli non siano ancora perfetti in un punto di forza: la trasparenza e il progresso.

Ecco una versione migliorata, professionale e coinvolgente in inglese. Ho aggiunto dei dettagli tecnici per far capire che sai il fatto tuo:

Title: Our Indie Horror Journey: Passion Over Perfection 🛠️🧟
Hi everyone!

I wanted to share a quick update on the horror game I'm developing with my friend. Currently, we are in the "heavy lifting" phase of creation.

The Art & Models
My friend has already been incredibly busy creating a lot of 3D models for the game. Are they perfect? Not yet. Are they AAA-quality? Not for now. But they are made with 100% passion.

We believe in the "Iterative Process":

Create the basic shape.

Test it in the Unity scene.

Refine and polish later.

As the programmer, I’m already working on integrating these models into the engine. Even if they aren't "beautiful" yet, seeing them move and interact with the environment is the best feeling in the world.

Our Philosophy
We prefer to have a working prototype with simple models than a perfect-looking game that doesn't play well. Once the mechanics (like the car breaking down and the survival system) are solid, we will go back and polish every single texture and vertex.

We are learning everything from scratch, and every small bug we fix is a huge victory for us.

Stay tuned for more updates

Building Production-Ready NestJS Apps: Introducing Nestier - A Hexagonal Architecture Boilerplate

Brahim — Sat, 25 Apr 2026 09:40:52 +0000

Building Production-Ready NestJS Apps: Introducing Nestier

Starting a new NestJS project? Tired of setting up the same architecture patterns, authentication, and infrastructure code over and over? I've been there too.

That's why I built Nestier — a production-ready NestJS boilerplate that demonstrates best practices in enterprise application development.

What is Nestier?

Nestier is a comprehensive NestJS boilerplate that implements Hexagonal Architecture (ports & adapters) and the Generic Repository Pattern. It's designed to help you build scalable, maintainable applications from day one.

Key Features

✨ Hexagonal Architecture - Clean separation of concerns with domain, application, infrastructure, and presentation layers

🔐 JWT Authentication - Complete auth flow with password reset

📊 Generic Repository Pattern - Reusable CRUD operations via TypeORM

🔍 Advanced Search - Dynamic filtering with multiple comparators

📝 80%+ Test Coverage - 212 tests (127 unit + 85 E2E)

🐳 Docker Ready - Full stack with MongoDB and SonarQube

📚 Swagger/OpenAPI - Auto-generated API documentation

🛡️ Security First - Helmet, rate limiting, input validation

Architecture Overview

The project follows a strict hexagonal architecture with four distinct layers:

Domain Layer      → Business logic, entities, repository interfaces
Application Layer → Use cases, services, orchestration
Infrastructure    → TypeORM repositories, adapters, external services
Presentation      → Controllers, DTOs, validation

This architecture ensures that your business logic remains independent of frameworks and external concerns, making your code more testable and maintainable.

Three Implementation Examples

Nestier includes three example modules that demonstrate different implementation approaches:

Category Module - Simple CRUD using base components
Product Module - Extended with custom use cases and repository methods
User Module - Full custom implementation with JWT authentication

This gives you flexibility to choose the right pattern for each feature in your application.

Quick Start

Getting started is straightforward:

# Clone the repository
git clone https://github.com/BrahimAbdelli/nestier.git
cd nestier

# Install dependencies
npm install

# Set up environment
cp .env.example .env

# Start the app
npm run start:dev

The API will be available at http://localhost:3000/api with Swagger docs at http://localhost:3000/docs.

Why Hexagonal Architecture?

Traditional layered architectures often lead to tight coupling between layers. Hexagonal architecture solves this by:

Isolating business logic from infrastructure concerns
Making testing easier through dependency inversion
Enabling flexibility to swap implementations (e.g., switch databases)
Improving maintainability with clear boundaries

Here's a simple example of how the repository pattern works:

// Domain layer - Repository interface (port)
interface BaseRepository<T> {
  findById(id: string): Promise<T | null>;
  findAll(): Promise<T[]>;
  create(entity: T): Promise<T>;
}

// Infrastructure layer - TypeORM implementation (adapter)
class TypeOrmBaseRepository<T> implements BaseRepository<T> {
  // TypeORM-specific implementation
}

What's Included

✅ JWT authentication with password reset flow
✅ Advanced search with filtering and pagination
✅ Soft delete functionality
✅ AutoMapper for entity ↔ domain ↔ DTO mapping
✅ Winston logger with structured logging
✅ Mailjet integration for emails
✅ Comprehensive error handling
✅ Docker and Docker Compose setup
✅ CI/CD with GitHub Actions
✅ SonarQube integration for code quality

Perfect For

🚀 Starting new NestJS projects
📚 Learning hexagonal architecture patterns
🏢 Building enterprise applications
🎓 Teaching clean architecture principles
⚡ Rapid prototyping with production-ready foundation

Get Started Today

Ready to build your next application with a solid foundation?

👉 Star the repository: github.com/BrahimAbdelli/nestier
👉 Article: brahimabdelli.dev/articles/2026/nestier/

Have questions or suggestions? Feel free to open an issue or start a discussion!

What patterns do you use in your NestJS projects? Share your thoughts in the comments below! 👇

How to Bulk Delete Your X (Twitter) History for Free (No API Keys Needed!)

Aero — Sat, 25 Apr 2026 09:40:36 +0000

We’ve all been there. You look at your X (formerly Twitter) profile and realize you have thousands of old tweets, cringy replies, and outdated retweets from a decade ago. It’s time for a clean slate.

In the past, you could just plug your account into a free third-party app and wipe your history in minutes. But ever since X changed its API pricing, almost all of those free tools have either shut down or started charging hefty subscription fees.

So, how do you clean up your digital footprint without opening your wallet?

Enter twitter-x-cleaner-automation: a completely free, open-source tool that runs directly on your computer to bulk delete your X history.

In this article, I’ll explain how this tool works, why it’s safe to use, and how absolutely anyone—even non-developers—can set it up in minutes.

🚀 What is this tool?

This tool is a lightweight script that automates the tedious process of deleting your X content. Instead of using expensive API keys to talk to X's servers behind the scenes, this tool uses Browser Automation.

Imagine hiring a tireless digital assistant who sits at your computer, opens Google Chrome, scrolls through your profile, clicks the three-dot menu on every single post, and hits "Delete." That is exactly what this script does, just much faster.

What can it clean up?

Posts: Deletes your original tweets.
Replies: Removes all the replies you’ve left on other people's posts.
Retweets (Reposts): Undoes retweets on your timeline.
Likes: Un-hearts posts you’ve previously liked.

🧠 How it Works (No Coding Degree Required)

You don't need to be a programmer to use this, but understanding how it works will give you peace of mind.

The script uses a technology called Puppeteer. Puppeteer is an invisible "puppeteer" for your web browser. When you run the tool, it does the following:

Opens Chrome: It launches a local version of Google Chrome right on your screen.
Logs You In: It uses a secure, local profile. The first time you run it, you'll log in just like you normally do. After that, it remembers you.
Scans and Clicks: It automatically navigates to your profile, uses visual cues to find posts that belong to you, clicks the specific "Delete" or "Unlike" buttons, and confirms the prompt.
Keeps Receipts: As it works, it saves a neat little log file (like a digital receipt) on your computer, so you always know exactly what text was deleted and when.

Because it mimics human behavior—actually clicking buttons on the website—it completely bypasses the need for API keys. Furthermore, it has built-in smarts. If X notices you are deleting things too fast and tries to pause you (a "rate limit"), the script will automatically wait for 60 seconds and resume.

🔒 Why This is the Safest Way to Clean Your Account

When you use sketchy third-party web apps, you are often asked to authorize their app to access your account. This means giving a stranger's server permission to post, delete, or read your messages.

This tool is entirely different:

100% Private: It runs only on your computer. Your passwords and data are never sent to any cloud server.
Transparent: It’s open-source. Anyone can look at the code to verify it does exactly what it says and nothing else.
No Account Bans: By mimicking normal browser clicks and respecting X's rate limits, it avoids triggering bot-detection alarms.

🛠️ Step-by-Step Guide: How to Use It

Ready to nuke your timeline? Here is how to get started.

Prerequisites

Before you begin, ensure you have the following installed on your Windows PC:

Google Chrome (Your everyday browser).
Node.js (Version 18 or newer). Just download the Windows installer and click "Next" until it's finished.

Step 1: Download the Tool

Go to the GitHub Repository. Click the green <> Code button and select Download ZIP. Extract the folder anywhere on your computer (like your Desktop).

Step 2: Open your Terminal

Open your computer's Command Prompt (or Terminal) and navigate to the folder you just extracted.
(Tip: You can open the extracted folder, click the address bar at the top of the window, type cmd, and press Enter. This opens a terminal right in that folder!)

Step 3: Install the Magic

In the terminal window, type the following command and press Enter:

npm install

This downloads the small set of instructions the script needs to run.

Step 4: Run the Cleaner

Now, start the tool by typing:

node script.js

Step 5: Choose Your Adventure

The tool will greet you with a friendly menu:

What would you like to do? (enter numbers separated by commas)
  1) Delete posts
  2) Delete replies
  3) Undo retweets
  4) Unlike posts
  5) All of the above

Your choice (e.g. 1,3,4):

Just type the numbers for what you want to do and press Enter.

A Chrome window will pop up. If it's your first time, the terminal will ask you to sign into X. Just log in manually in that Chrome window, switch back to your terminal, and press Enter

Sit back and watch. The tool will auto-detect your username and start scrubbing your profile. You can literally watch the posts disappear one by one!

📂 Advanced Options

If you want to be more specific, you can give the tool extra commands right from the start.

Want to delete exactly 100 posts?

node script.js @yourhandle 100

Want to start a completely fresh log file instead of keeping a running list?

node script.js @yourhandle 100 overwrite

All of your deleted history will be saved neatly inside the output/ folder in the tool's directory, categorized by actions (e.g., deleted-posts.json).

🏁 Final Thoughts

Taking control of your digital footprint shouldn't cost you a monthly subscription. Thanks to browser automation, we can take back control of our data for free, securely, and privately.

If this tool helped you clean up your timeline, be sure to head over to the twitter-x-cleaner-automation GitHub repo and give it a ⭐ Star to support the project!

Happy cleaning! 🧹✨

Why We Switched from Direct API Calls to Kafka and What Broke Along the Way

Sheikh Shahzaman — Sat, 25 Apr 2026 09:38:22 +0000

TL;DR: We migrated 10+ microservices from direct HTTP calls to Kafka event-driven communication. Reliability improved massively but the migration was harder than expected. Here are the real lessons including the mistakes.

Our system started as a monolith. Then we split it into microservices. The services talked to each other using direct HTTP calls. Service A would POST to Service B which would POST to Service C. It worked fine when we had 3 services.

Then we had 10.

The Day Everything Cascaded

One Tuesday morning our notification service crashed because of a memory leak. No big deal right? Restart it and move on.

But the order service was calling the notification service directly during checkout. When notification service was down the order endpoint started timing out. Users could not place orders. The billing service was also calling notification service to confirm payment receipts. Billing started failing too.

One crashed service took down three other services because they were all directly dependent on it.

That was the day we decided to move to event-driven architecture.

How We Set It Up

The concept is simple. Instead of Service A calling Service B directly Service A publishes an event to Kafka. Service B listens for that event and processes it on its own time.

// Before: Direct coupling
class OrderService {
    public function complete($order) {
        $order->markComplete();
        Http::post('billing-service/invoice', $order->toArray());
        Http::post('notification-service/email', $order->toArray());
        Http::post('analytics-service/track', $order->toArray());
    }
}

// After: Event-driven
class OrderService {
    public function complete($order) {
        $order->markComplete();
        KafkaProducer::publish('order.completed', [
            'order_id' => $order->id,
            'tenant_id' => $order->tenant_id,
            'total' => $order->total,
            'completed_at' => now()->toIso8601String(),
        ]);
    }
}

The order service does not know or care who listens to that event. Billing creates an invoice. Notifications send an email. Analytics tracks a metric. Each service subscribes to the event independently.

What Broke During Migration

I wish I could say the migration was smooth. It was not.

Problem 1: Event ordering. We assumed events would arrive in the order they were published. They mostly did. But when we had high throughput some consumers processed events out of order. An "order.updated" event arrived before "order.created" and the consumer crashed because the order did not exist yet.

The fix was adding an event version number and having consumers check if they had already processed a newer version before applying changes.

Problem 2: Duplicate events. Kafka guarantees at-least-once delivery. That means consumers can receive the same event twice. We had a bug where a payment was processed twice because the consumer was not idempotent.

The fix was adding a unique event ID and checking if we had already processed that ID before taking action.

class InvoiceConsumer {
    public function handle($event) {
        if (ProcessedEvent::where('event_id', $event['id'])->exists()) {
            return;
        }

        $invoice = Invoice::createFromOrder($event['order_id']);

        ProcessedEvent::create(['event_id' => $event['id']]);
    }
}

Problem 3: Debugging was harder. With direct API calls you could trace a request from start to finish in one log. With events the flow is split across multiple services and multiple time periods. Finding out why an invoice was not created required checking logs in three different services.

We solved this by adding a correlation ID to every event. When the order service publishes an event it includes a unique request ID. Every downstream consumer includes that same ID in their logs. Now you can search for one ID and see the entire flow across all services.

The Patterns That Saved Us

Dead letter queue. When a consumer fails to process an event after 3 retries it goes to a dead letter topic. We have a dashboard that shows failed events and lets us replay them after fixing the bug.

Schema registry. We define the structure of every event in a shared schema. If a producer tries to publish an event that does not match the schema it fails at publish time not at consume time. This prevented so many bugs.

Consumer lag monitoring. We track how far behind each consumer is. If the notification consumer falls 10,000 events behind we get an alert. This caught performance issues before users noticed them.

The Results

After 3 months on event-driven architecture:

Zero cascading failures. One service going down does not affect any other service.
We can deploy services independently without coordinating with other teams.
Adding a new consumer takes 30 minutes instead of modifying 5 different services.
Event replay lets us reprocess historical data when we add new features.

What I Would Do Differently

I would have implemented idempotency from day one not after the duplicate payment bug. Every consumer should be idempotent by default.

I would have invested in better tooling earlier. A good event viewer that shows the flow of events across services would have saved weeks of debugging time.

And I would not have migrated everything at once. We tried to move all 10 services in one sprint. It should have been gradual. Start with the least critical services and work toward the most critical.

Event-driven architecture is powerful but it adds complexity. If you have 3 services that rarely fail direct API calls are probably fine. If you have 10+ services and reliability matters events are worth the investment.

Have you migrated from direct API calls to event-driven architecture? What surprised you the most?

I built Daymint instead of using Todoist + Habitica. Here's why.

sourav swain — Sat, 25 Apr 2026 09:36:53 +0000

https://play.google.com/store/apps/details?id=com.souravsn.daymint

I Built a Habit Tracker App Instead of Using Todoist + Habitica

For 2 years, I juggled 3 different apps for productivity:

Todoist for tasks
Habitica for habits
Google Calendar for planning

Every morning, I'd switch between them 10+ times. It was exhausting.

So I built Daymint - and it's completely changed how I work.

The Problem: App Fatigue

The fundamental issue with using multiple productivity apps:

Context switching - Your brain loses focus switching between apps
Fragmented data - Your tasks are in one place, habits in another
Inconsistency - You miss tracking because you forget which app to use
Cost - Premium features cost $50-100/year combined
Complexity - Learning 3 UIs instead of mastering one

I'm not alone. According to a study by the American Psychological Association,
context switching reduces productivity by 40%.

Why These Apps Weren't Enough

Todoist

✓ Powerful task management

✓ Beautiful UI

✗ Terrible for habit tracking

✗ Habit features feel bolted-on

Habitica

✓ Great habit tracking with gamification

✓ Community features

✗ Overkill if you just want simple tracking

✗ Not designed for task management

Google Calendar

✓ Essential for scheduling

✗ Not designed for habit tracking or tasks

✗ Messy mixing of events with habits

The core problem: No single app did all three well.

What I Built Instead

I spent 3 months building Daymint specifically to solve this problem.

Core Features

1. Daily Planner (Multiple Views)

Today view - see all your tasks + habits for today
Calendar view - plan your entire week
Timeline view - time-block your day
See everything at a glance

2. Habit Tracker (Built for Real Habit Building)
This is what sets it apart.

Most habit apps just count streaks. Daymint:

Tracks WHY you're building the habit (motivation)
Shows progress analytics (visual proof you're improving)
Displays streaks (the most motivating metric)
Reminds you intelligently (not annoying notifications)

The research is clear: Visual progress is the #1 motivator for habit building.

3. Task Manager (Simple but Powerful)

Add tasks with priorities, due dates, reminders
Organize with labels and categories
Search, filter, sort (find anything instantly)
Snooze reminders (deal with tasks when you're ready)

4. Everything Offline + Private

Works completely offline (no internet required)
Your data never leaves your device (no cloud)
No tracking, no ads, no servers
Completely free forever

Key Differences: Daymint vs The Alternatives

Feature	Daymint	Todoist	Habitica	Google Cal
Daily Planning	✓	✓	✗	✓
Habit Tracking	✓	✗	✓	✗
Task Management	✓	✓	✗	✗
Offline	✓	✗	✗	✗
Free Forever	✓	✗ (requires Pro)	✓	✓
Privacy	✓	✗	✓	✗
Single App	✓	✓	✓	✓
All 3 Together	✓	✗	✗	✗

The Technical Side

Why I built it this way:

Built with:

Kotlin for Android (clean, modern language)
Room Database for offline-first architecture
Material Design 3 for modern UI
MVVM architecture for maintainability
Zero dependencies on servers or cloud services

I deliberately chose offline-first + local storage because:

Privacy - Your habits are personal
Reliability - No internet issues
Speed - Everything instant, no network latency
Control - You own your data

What I Learned

1. The Power of Focus

Building ONE app that does three things well > THREE apps doing one thing each.

The feature creep temptation was real. But I forced myself to ask:
"Does this help with daily planning + task management + habit tracking?"

If not, it got cut.

2. Offline-First Changes Everything

Most apps assume cloud sync. When you design offline-first:

Users feel more in control
Privacy concerns disappear
Speed improves dramatically
Trust increases

3. Habit Building is Psychological, Not Technical

The best feature isn't the algorithm or the sync. It's:

Visual progress (streaks)
Consistent reminders (at the right time)
Celebration of wins (30-day milestones)
Low friction (1-tap to complete)

Results So Far

Launched 2 weeks ago on Android:

50+ downloads
4.2+ rating (from early users)
100% positive feedback
Completely free, no ads

Should You Use Daymint?

Yes, if you:

Want everything in ONE app
Value privacy + offline
Don't need cloud sync
Want a simple, clean UI
Can't afford $50+/year for premium tools

No, if you:

Love Todoist's power features
Need cross-device sync
Want gamified habit tracking (Habitica)
Use teams/collaboration

Get Started

Download Daymint completely free on Google Play Store:
[Play Store Link]

No ads, no tracking, no premium features. Just a simple, powerful
daily planner + habit tracker.

What's Next?

I'm actively developing Daymint based on feedback. Currently working on:

Recurring task templates
More analytics on habit progress
Custom habit schedules
Export features

I'd love to hear from you:

What features would make it 5 stars for you?
What's missing compared to your current setup?
What's one thing you struggle with in productivity?

Drop a comment below or email me at s22542273@gmail.com

Have you felt the pain of using multiple productivity apps?
What's your setup? Let me know in the comments!

Building a 3D Zombie Survival Horror in Unity: Day 1 of Our Journey

Mattia Santangelo — Sat, 25 Apr 2026 09:35:26 +0000

🧟‍♂️ The Road of the Dead: A New Indie Horror Adventure

Hi everyone! I’m a 12-year-old developer and today I’m officially starting a big project with my friend and classmate, Dardan. We decided to stop just playing games and start building our own.

💡 The Concept

Our game is a 3D Survival Horror. The core idea is simple but intense:
You are trapped in a car driving through a wasteland infested with monsters and zombies.

The Car is your Armor: It has its own HP. If the zombies damage it too much, it breaks down.
The Switch: When the car stops, you HAVE to get out. That’s when the game changes from a driving simulator to a third-person survival fight against scary bosses.

👥 The Team

We’ve split the roles to work like a real indie studio:

Me (Lead Programmer): I’m handling the C# scripts, the car physics, and the health systems using Unity.
Dardan (Lead Designer): He’s in charge of the 3D models, environment design, and making the monsters look terrifying.

🛠️ The Tech Stack

We are developing this project using Unity (URP).
I am currently working on my Dell Latitude 7290. It’s a great challenge to optimize a 3D game for mobile-grade hardware, but it teaches me a lot about performance!

🚀 What's Next?

Right now, I’ve just finished the basic car movement script and a simple health system. Dardan is working on the first "Scary Boss" model.

We know we have a lot to learn, but we are excited!

What do you think about the "Car HP" mechanic? Any tips for a young dev team starting with Unity?

Unity #GameDev #IndieDev #Horror #Programming #Beginner

The State of Agent Identity — Q2 2026

Pico — Sat, 25 Apr 2026 09:33:28 +0000

I'm building AgentLair — cross-org behavioral trust infrastructure for AI agents. The AAT spec, JWKS verification, and audit trail are live. Reach out: team@agentlair.dev

Previously: World ID for Agents Is L1/L2 — Here's Why L4 Still Doesn't Exist | Five Identity Frameworks, Three Gaps | Microsoft Built the Intranet of Agent Trust

Forem

Beyond the Cloud: Mastering On-Device GenAI with MediaPipe and Gemini Nano on Android

The Architecture of On-Device Intelligence

The System-Level AI Provider Model

Why the AICore Ecosystem Matters

The "Room Database" Analogy

Gemini Nano and the Science of Quantization

Under the Hood: Why 4-bit?

Mapping AI Concepts to Modern Kotlin 2.x

1. Asynchronous Inference with Coroutines

2. Streaming Responses with Flow

3. State Management with Context Receivers

Building the Production-Ready Implementation

Step 1: Dependencies

Step 2: The LLM Repository (Hardware Orchestration)

Step 3: The ViewModel (State Management)

Detailed Execution Flow: What Happens When You Click "Generate"?

Common Pitfalls and How to Avoid Them

1. Main Thread Blocking

2. Memory Overload (OOM)

3. Incorrect Model Path

4. Ignoring the Native Lifecycle

The Future: Local AI Summarizers

Conclusion

Let's Discuss

How I Set Up Ollama With n8n and Brought My AI API Costs to Zero

How I Set Up Ollama With n8n and Brought My AI API Costs to Zero

What I Was Using AI For in My Workflows

Installing Ollama

The Docker Networking Problem

Setting Up the n8n Credential

Replacing Each Workflow — What Happened

Email Classification

Document Type Detection

Lead Scoring Summaries

Weekly Report Drafting

My Current Model Setup

What My Costs Look Like Now

Would I Recommend This?

Frequently Asked Questions

Does Ollama work as well as OpenAI GPT-4 for n8n automations?

Can I run Ollama on a VPS server without a GPU?

How do I connect n8n in Docker to Ollama on the host machine?

Which Ollama model should I start with for n8n automation?

How to Get Historical Stock Data for Free with Python (and Actually Use It)

Why Unofficial APIs Break (and What to Use Instead)

What Is EODHD and What's Free

Getting Historical Stock Data in Python: Step by Step

1. The base request

2. Build a multi-ticker price matrix

3. Compute returns and volatility

Why Data Quality Is Not a Detail — It's the Foundation

Advanced Use Cases

Use Case 1: Correlation matrix for portfolio analysis

Use Case 2: RSI indicator from scratch

Use Case 3: Backtesting a moving average crossover

Use Case 4: Multi-asset momentum ranking

Free vs Paid: What Changes When You Upgrade

FAQs

Closing

Beyond ERC-4337: Ethereum’s Transition into a Programmable Trust Layer

The misconception that quietly breaks real systems

Reconstructing Ethereum as a system

ERC-4337 is not account abstraction

From transactions to execution pipelines

Legacy model

New model

The hidden constraint: deterministic validation

Execution phase: full power, full liability

Gas is not a fee. It is risk.

Paymasters: decoupling who pays

Smart accounts: identity becomes programmable

Signature evolution: from static to programmable

Current state

With ERC-4337

Emerging direction

ERC-7702: collapsing the migration barrier

Before

After

Modular accounts: identity as composition

2. Streaming Responses with `Flow`