DEV Community: Maxim

Kafka, RabbitMQ, or Postgres? The Messaging Tools Comparison (2026)

Maxim — Wed, 29 Apr 2026 10:28:40 +0000

PostgreSQL: DB with Transactional Message Queue.
MQTT (Mosquitto): Lightweight IoT Messaging Protocol.
AWS SQS: Managed Serverless Message Queue.
RabbitMQ: Enterprise Message Broker (AMQP).
Redis Streams: In-memory Append-only Event Log.
BullMQ (Redis on Nodejs): Distributed Task Management System.
NATS (on Go): Ultra-fast Cloud-Native Messaging.
ActiveMQ: Classic Multi-protocol Enterprise Broker.
Apache Kafka: High-throughput Distributed Event Store (Immutable Log).

Choosing the right messaging tool depends on your needs and tradeoffs. Here is a breakdown of the most popular options, from database triggers to massive data streams.

Before we jump into the comparison, I want to mention Disk Paging.

It's a technique used when RAM is full: the OS moves inactive pages to a "page file" on the Disk (paging out) and brings them back only when needed (paging in). In our case, this is the "safety net" that keeps a broker from crashing when the queue exceeds available memory capacity. It saves your server from an OOM (Out of Memory) crash, but the price is latency—reading from a disk is orders of magnitude slower than reading from RAM.

1. PostgreSQL (LISTEN/NOTIFY)

The most simple, no-setup required.
Max Message Size (Payload): 8 KB — don't try to send the "cargo." Send the "tracking number" (ID). It’s built for notifications, not data transport.
Max Queue Capacity (Backlog): Very Low (Shared Buffer)
Storage Strategy: RAM (Volatile)
Scalability Type: Vertical — Increasing the power of a single server (more CPU cores, more RAM, faster NVMe SSD).

✅ Props: Built into database. No extra installation. It is strictly transactional, and the message is ONLY sent IF your data is actually saved (committed).

❌ Cons: No storage. No Disk Paging technique. It is a "shout and forget" system. If your application is offline or restarting for one second, it misses the message forever.

🛡️ Security (4/5): Very safe. It stays inside your database and uses existing DB users. Safe if your database is locked behind a firewall.

🎯 Use Case: Instant cache invalidation, real-time UI updates (like WebSockets or Push Notifications), or internal database triggers.

Resource Usage:

🧠 RAM: Very low. It only keeps a small list of active listeners in memory.
💾 Disk: 0%. It never writes notifications to the disk. They are not saved in logs or tables.
⚙️ CPU: Very low. The database just "pokes" the listener when a change happens.

The "Memory-Only" Reality:

Speed: Incredibly fast because there is no disk "write" time.
Volatile: If the server restarts, all pending notifications disappear instantly.
Capacity: Designed for "pings" and signals, not for holding high-volume data streams.

2. 💡 MQTT (Mosquitto)

The King of IoT & Real-time

Have to mention: It's a protocol.

Standard Mosquitto (is single-threaded) — does not support native clustering. You scale it by giving the server a faster CPU and more RAM.

Note: If you need Horizontal scale, you have to move from Mosquitto to a "clustered" broker like EMQX or HiveMQ.

Max Payload: 256 MB (Protocol limit).
Max Queue Capacity: Thousands (RAM dependent).
Storage: RAM or Disk (Persistence for restarts).
Scalability Type: Vertical (Single Node).

✅ Props: Fast and tiny. Saves battery and data. Great for unstable internet connections.

❌ Cons: Not designed for complex data processing. Weak default settings, no disk paging technique.

🛡️ Security (2/5): Depends 100% on you. Usually "open" by default. You must manually add passwords and SSL/TLS to secure the connection.

🎯 Use Case: IoT sensors, smart homes, and mobile apps with poor signal.

Small/IoT project? Vertical (Mosquitto) is enough.
Global/Fleet project? You must go Horizontal (EMQX/HiveMQ).

3. ☁️ AWS SQS

The King of Serverless

Consumers go offline for a weekend? These tools won't blink. For ActiveMQ or Kafka, just make sure you have enough disk space. For SQS? Just hold your wallet!

But it's true simplicity, no management and holds your messages safely for up to 14 days. Click a button -> get a URL -> and start sending messages.

Max Payload: 1 MB (Updated in 2025/26)
Max Queue Capacity: Virtually Unlimited
Storage Strategy: Managed Cloud
Scalability Type: Infinite Horizontal — you just send more requests and get more (it depends on your wallet)

✅ Props: Zero maintenance and No servers to manage, AWS runs the servers. It scales to high message volumes automatically.

❌ Cons: Locked into Amazon (Vendor lock-in). Can have higher latency compared to self-hosted tools.

🛡️ Security (5/5): Highest safety out-of-the-box. AWS manages security patches and forces strict access rules (IAM).

🎯 Use Case: Connecting cloud apps without managing any physical hardware or software installation.

4. RabbitMQ

The King of Routing

In a Cluster all servers are in sync like "married." Every node knows exactly what is happening on every other node.

Max Payload: 128 MB+
Max Queue Capacity: Millions (using Lazy Queues)
Storage: RAM + Disk
Scalability Type: Horizontal (Clustered)

✅ Props: Advanced routing logic (Exchanges). Reliable "mailbox" that waits for your app to be ready.

❌ Cons: Uses a lot of RAM in default mode. Horizontal scaling requires careful configuration.

🛡️ Security (3/5): Good, but you must change the default "guest" password and close the admin portal to the public.

🎯 Use Case: Business tasks like processing orders, background jobs, or sending emails.

The Two Modes:

1. Normal Queues (RAM-First):

How it works: Keeps messages in RAM for speed. Moves to Disk only if RAM is full (Disk Paging technique).
✅ Pros: Extremely fast.
❌ Cons: High RAM usage. If RAM fills up, the system may lag while moving data to disk.

2. Lazy Queues (Disk-First):

How it works: Stores messages on the Disk immediately.
✅ Pros: Can store millions of messages without crashing the server. Very stable.
❌ Cons: Slower because writing to Disk is not as fast as RAM.

5. ⚡ Redis Streams For Events (Kafka Lite)

The King of Speed
Chatbot History / Live Feed, Agents, RAG systems 🔥

The high-performance, in-memory log.

Redis 7.0+, messaging is no longer a 'toy.' With the introduction of Sharded Pub/Sub, it learned how to 'breathe' in massive clusters without wasting bandwidth on unnecessary junk or redundant data. Redis Streams gives you 80% of Kafka's capabilities, but with ms latency and without the need to manage a massive Java-based infrastructure.

Max Payload: 512 MB (The limit of a Redis string).
Max Backlog: RAM-dependent. Unlike ActiveMQ, Redis lives in your memory. If backlog is too large, there is 2 scenarios: run out of RAM or start evicting old data.
Storage Strategy: In-Memory. While it has RDB/AOF persistence to survive a restart, it does not do "Disk Paging" in the middle of a live session to save RAM.
Scalability Type: Horizontal (Clustered/ Sharding).

You scale it using Redis Cluster. You shard the data so that different nodes handle different "keys" (Streams).

🛠 How it Works?

Redis Streams is an append-only log data structure. Unlike a standard Redis List (LPUSH/RPOP), a Stream allows:

Consumer Groups: Just like Kafka, multiple consumers can join a group to split the work (this is a unique game-changer for Redis).
Acknowledge (ACK): Redis tracks which consumer has processed which message. If a consumer dies, another can "claim" the pending messages.
Message IDs: Every entry gets a unique ID based on a timestamp (e.g., 1626451200000-0).

6.🐂 BullMQ (Task Queue)

Best for Tasks Management
LLM Inference, RAG Integration, AI Agents (Orchestration) 🔥

Have to mention: It’s a Library Node.js, not a standalone server.

BullMQ leverages Redis via Lua scripts (Runtime Logic) in RAM

Think of it like this: Node.js says, 'Hey Redis, take this script, run the logic atomically inside your own memory, and just give me
the result.

This eliminates unnecessary network round-trips and guarantees that a task is never lost—even if a worker crashes mid-process—because the state is managed entirely within Redis.

Need a massive horizontal scale for the storage layer itself? Use BullMQ with Redis Cluster.
Max Payload: 512 MB (Redis limit), but it's by best practice it < 100 KB (pass IDs, not the entire data object).
Max Queue Capacity: Millions of tasks (dependent strictly on your Redis RAM).
Storage: Redis (In-memory) + Persistence on Disk with (RDB/AOF for recovery after restarts), RDB is a Snapshot , AOF Journal with every single write command (like Git History).
Scalability Type: Horizontal (Spin up more Workers).

✅ Props: manage states (States: Waiting, Active, Completed, Failed, Delayed). Features out-of-the-box: Parent-Child Job Flows, automatic Exponential Backoff Retries (Exponential delays, first time wait 1s, second 2s, third time wait 4s), and Task Prioritization.

❌ Cons: Hard dependency on Redis. IF Redis RAM is full and "eviction" is misconfigured (LRU), the queue will break. Requires careful tuning of lockDuration for long-running tasks.

🛡️ Security (4/5): Inherits Redis security features. Supports ACLs (Access Control Lists) and SSL/TLS. Data is usually not encrypted.

🎯 Use Case: LLM integrations (handling long-running API requests), video/image processing, high-volume notification systems, and complex financial workflows.

Standard background task? BullMQ + Single Redis node will be enough.

Huge AI Pipeline? BullMQ Flows (Parent-Child) + Redis Cluster.

7. NATS

The King of Edge & Speed

History: It started in Ruby, then NATS was re-engineered in Go to maximize concurrency.

The connective tissue for modern distributed systems.

To understand NATS in 2026, you have to know it has two "modes":

Strategy: Pure RAM. It doesn’t even try to save messages to disk.
The Catch: If a subscriber isn't online, the message is lost forever (reminds you a Postgres?)
Speed: 10+ million messages per second.
Use Case: Real-time signals, heartbeats, and "I don't care if I miss one" data.

2. NATS JetStream (The "Persistence" mode)

Strategy: Smart, it adds Disk Persistence, Consumer Groups, and Acknowledgments.
Storage Strategy: File or Memory. You can configure it to store messages on disk, acting as your "Disk Paging" safety net.
Weekend Outage Test: When JetStream enabled, it won't blink if consumers go offline—it just stores the data in a stream.

8. ActiveMQ

The King of Enterprise

You don't have one big super-server. Instead, you have multiple independent brokers connected by a "bridge" in a Network of Brokers and the servers are "neighbors." They are independent (not like RabbitMQ).

Max Payload: Unlimited (Disk bound)
Max Queue Capacity: Hundreds of Millions (The king)
Storage Strategy: Disk Paging
Scalability Type: Horizontal (Network)

Why use "Network" instead of "Cluster"?

Geographic Distribution: one broker in New York, one in London.
Store-and-Forward logic: This allows the system to scale horizontally across different physical locations and unreliable networks.

✅ Props: Supports many protocols (JMS, AMQP, STOMP). Highly flexible for different programming languages.

❌ Cons: Slower than newer, lightweight tools. Can feel complex to manage.

🛡️ Security (4/5): Strong potential, but requires expert knowledge in setup because supporting many protocols means more ports to lock down.

🎯 Use Case: Corporate Java apps and integrating various systems that use a bunch of protocols.

9. Apache Kafka

The King of Throughput

Massive data & Event streaming capabilities.
Go offline for a weekend, tool won't blink (same as SQS) but keeps data until the disk is full.

Max Payload: 1 MB (Default) / 100 MB+
Max Queue Size: Petabytes (Log Retention)
Storage Strategy: Disk (Immutable Log)
Scalability Type: Native Horizontal

✅ Props: Huge throughput. It is a "distributed Log" system that saves everything, so you can "rewind" and read old data.

❌ Cons: Complex and high learning curve. Requires significant infrastructure to run properly.

🛡️ Security (4/5): Can be the most secure, but carries a high risk of human error (a lot of complex security settings to manage).

🎯 Use Case: Event streaming, Analytics (real-time), Logs aggregation, and fraud detection.

The Messaging & Queuing Decision Matrix

Choose PostgreSQL for tasks that require absolute data safety and guaranteed database transactions (ACID).
Choose MQTT for IoT devices and mobile apps that need to stay connected over slow or unstable networks.
Choose AWS SQS for serverless projects, infinitely scalable queue without managing any servers.
Choose RabbitMQ for complex business logic that requires smart message routing and flexible delivery rules.
Choose Redis Streams for real-time AI chatbots and RAG systems that need ultra-fast, in-memory event history.
Choose BullMQ for Node.js AI pipelines that need to manage complex task states and automatic retries.
Choose NATS for ultra-fast microservices that require the lowest possible latency for instant communication.
Choose ActiveMQ for large enterprise systems that need to connect old Java apps using different messaging protocols.
Choose Apache Kafka for massive data streams where you need a permanent, history of every events (Immutable Logs)

🔗 Connect with me: GitHub, LinkedIn

От векторов 70-х к современным AI-агентам 🧩

Maxim — Mon, 27 Apr 2026 13:05:52 +0000

Я, как всегда, со своим скрупулезным подходом — решил залезть под капот и разобраться, как это всё работает на самом деле. А там... старый добрый pipeline.

Идеи сходства (similarity) и поиска ближайших соседей (nearest neighbors) — это вообще не ново. Эти концепции десятилетиями использовались в поиске, computer vision, распознавании образов и исследовательских системах еще задолго до публичного AI-бума.

Новое здесь — только обертка:

Vector DB: Назвали их «новым» типом баз для массового рынка (Pinecone и другие), хотя по сути это просто эффективные индексы для векторов.
API и Cloud services: Удобный способ доставки и масштабирования.
RAG-пайплайны и LLM: Просто интерфейс для конечного пользователя.

Векторные представления (Embeddings) были стандартом еще в 70x! «Новизна» лишь в том, что теперь мы можем ворочать огромными объемами данных через API.

2. Что под капотом? (The Pipeline) ⚙️

Когда мы пишем запрос (prompt), запускается тот самый pipeline:

Tokenizer

Текст режется на куски (токены). Слово или символ превращается в ID. По сути, это простая структура данных (Map) и алгоритм нарезки.

В open-source: это файлы tokenizer.json, vocab.json, merges.txt.
В managed API: это спрятано внутри runtime провайдера.

const userQuestion = "How does Vector DB work?"

// Процесс токенизации (упрощенно):
// input  -> ["How", " does", " Vector", " DB", " work", "?"]
// output -> [2437, 857, 12944, 6212, 990, 30]

Элементарный маппинг: каждый токен получает свой уникальный ID.

Embedding Layer

Токены попадают в модель и заменяются на векторы (координаты в многомерном пространстве):
2437 -> [0.12, -0.03, 0.88, ...]

Attention (Механизм внимания)

Здесь модель вычисляет, какие токены в контексте связаны друг с другом. В вопросе "How does Vector DB work?" токен "work" должен «внимательно» смотреть на "Vector DB", чтобы понять смысл. Это почти как поиск по ключевым словам (Keywords) для определения интента вопроса.

Matrix Multiplication

Основная математика. Векторы умножаются на веса (weights) уже обученной модели.
Weights — это как взвешенное среднее. Входные данные с бóльшим весом сильнее влияют на итоговый результат.

Важно понимать: в момент запроса модель не учится. Она просто прогоняет данные через готовую функцию:
$$weights \times vectors$$

Next Token Prediction

На выходе мы получаем вероятности для следующего токена. Выбираем один, добавляем в контекст и уходим на новый круг (Loop):
Context -> Trained Function -> Prediction.
И так токен за токеном, пока не соберется ответ.

"Это мне как раз напомнило курс Andrew Ng. Там параметры шли через функцию, мы считали ошибку (cost) и двигались к минимуму (loss). Только тут prediction — не class label, а следующий токен из словаря."

Кстати, курс Эндрю Ына вышел уже 12 лет назад!

И тут я задумался: если эти идеи публично преподавались так давно, сколько закрытых систем использовали их раньше?

Системы ПВО, спутниковая разведка, медицинские экспертные системы (вроде MYCIN из 70-х).
Всё это живет на этих принципах десятилетиями!

3. Проблема «памяти» и RAG 🧠

Context window — это жесткий limit на количество токенов за один request.
Модель не «забыла» информацию — просто если данных слишком много, приложение отрезает старое по принципу FIFO.

while (countTokens(messages) > contextLimit) {
  messages.shift() // Старый контекст просто не отправляется в новый запрос
}

Чтобы использовать модель эффективно, нужно «подкармливать» её свежими данными через метод RAG (Retrieval-Augmented Generation).

Как это работает: Вопрос пользователя ⮕ Поиск по документам ⮕ Найденные фрагменты + Вопрос ⮕ Языковая модель ⮕ Ответ.

Зачем это нужно:

Устраняет «галлюцинации»: Модель опирается на факты из поиска, а не на свою «память».
Актуальность: RAG позволяет использовать свежие данные без дорогостоящего переобучения и надежды на магию.

4. Кто рулит этим процессом? (Оркестрация) 🎮

Это не делает сама модель. Она не решает, какую историю чата взять и какие инструменты вызвать. Этим занимается orchestration layer.

Когда нам стало мало обычного чат-бота, то появились такие штуки как LangGraph (State Machine), которая работает вокруг модели. Оркестратор создает макро-flow:

Запрос пользователя ⮕ Слой оркестрации.
Проверка состояния / памяти.
Определение маршрута (Route).
Поиск в Vector DB.
Вызов инструментов (Tools).
Формирование финального контекста ⮕ Вызов LLM.
Валидация ответа ⮕ Конец или новый цикл.

Если LLM — это вероятностный движок, то LangGraph — это императивный контроль. Он говорит: "Сначала сходи в SQL за фактами, если мало — загляни в Vector DB, проверь результат, если хрень — иди на повторный цикл".

Архитектура вместо магии 🏗️

Современный AI-агент — это архитектура. Называть её «интеллектом» в полном смысле слова странно, но то, что мы сейчас все живем в статистической матрице — это факт!

From 70s Vectors to Modern AI Agents

Maxim — Mon, 27 Apr 2026 11:40:27 +0000

🧩 AI Agent Architecture: From 70s Vectors to Modern RAG Pipelines

1. Nothing New Under the Sun ☀️

As usual, with my meticulous approach, I decided to peek under the hood and figure out how it all actually works. And there it was... the pipeline! Tadam !

The ideas of similarity and nearest neighbor search are nothing new. These concepts have been used for decades in search, computer vision, pattern recognition, and research systems long before the public AI boom.

The only "new" thing is the wrapper:

Vector DB: Marketed as a "new" type of database (Pinecone and others), though they are essentially just efficient indices for vectors.
API and Cloud services: A convenient way to deliver and scale.
RAG pipelines and LLMs: Simply a high-level interface for the end user.

Vector representations—or Embeddings—are essentially data mapped as spatial coordinates, much like X, Y, and Z in 3D space. This was already a standard in the 70s, known back then as Vector Space Models. The only real 'novelty' today? We’re doing it in thousands of dimensions and processing massive datasets via an API.

2. What's Under the Hood? (The Pipeline) ⚙️

When we write a prompt query, that same pipeline kicks in:

The Tokenizer

Text is sliced into chunks (tokens). A word or symbol becomes an ID. Essentially, it’s a simple data structure (Map) and a slicing algorithm.

In open-source: these are tokenizer.json, vocab.json, and merges.txt files.
In managed APIs: this is hidden inside the provider's runtime.

const userQuestion = "How does Vector DB work?"

// Tokenization process (simplified):
// input  -> ["How", " does", " Vector", " DB", " work", "?"]
// output -> [2437, 857, 12944, 6212, 990, 30]

Elementary mapping: each token gets its own unique ID.

Embedding Layer

Tokens enter the model and are replaced by vectors (coordinates in a multi-dimensional space):
2437 -> [0.12, -0.03, 0.88, ...]

Attention Mechanism

Here, the model calculates which tokens in the context are related to each other and how strongly. In the question "How does Vector DB work?", the token "work" must "attentively" look at "Vector DB" to understand the meaning. It’s almost like a keyword search for the intent of the question.

Matrix Multiplication

The fundamental math. Vectors are multiplied by the weights of the pre-trained model.
Weights act like a weighted average. Input data with a higher weight influences the final result more strongly.

It’s important to understand: the model does not learn at the moment of the request. It simply runs the data through a pre-set function:
$$weights \times vectors \rightarrow \text{probabilities}$$

Next Token Prediction

On the output, we get probabilities for the next token. We choose one, add it to the context, and start a new circle (Loop):
Context -> Trained Function -> Prediction.
And so on, token by token, until the answer is complete.

"This reminded me exactly of Andrew Ng's Machine Learning course on Coursera. Parameters went through a function, we calculated the error (cost), and moved toward the minimum. Only here, the prediction is not a class label, but the next token from the vocabulary."

By the way, Andrew Ng's course was released over 12 years ago! And then it really made me think: if these ideas were being taught publicly so long ago, how many closed systems were using them even earlier?

Air defense systems, satellite intelligence, medical expert systems (like MYCIN from the 70s). All of this has been living on these principles for decades!

3. The "Memory" Problem and RAG 🧠

Context window is a hard limit on the number of tokens per request.
The model hasn't "forgotten" information—it's just that if there is too much data, the application cuts off the old stuff based on the FIFO (First In, First Out) principle.

while (countTokens(messages) > contextLimit) {
  messages.shift() // Old context is simply dropped from the request
}

To use the model effectively, you need to "feed" it fresh data using the RAG (Retrieval-Augmented Generation) method.

How it works: User question ⮕ Document search ⮕ Found fragments + Question ⮕ Language model ⮕ Answer.

Why it matters:

Eliminates "hallucinations": The model relies on facts from the search rather than its own internal "memory."
Relevance: RAG allows the model to use fresh data without expensive retraining or hoping for magic.

4. Who Runs the Process? (Orchestration) 🎮

The model doesn't manage the flow itself. It doesn't decide which chat history to keep or which tools to call. This is handled by the orchestration layer.

When a simple chatbot isn't enough, we use tools like LangGraph—a State Machine that works around the model. The orchestrator creates the macro-flow:

User query ⮕ Orchestration layer.
Check state / memory.
Determine route.
Search Vector DB.
Call tools.
Build final context ⮕ Call LLM.
Validate / post-process answer.
Finish or loop again.

This is a great reminder of the difference between imperative and declarative programming approaches

Declarative (The LLM): You describe what you want (the goal), and the model predicts the path.
Imperative (The Orchestrator): You explicitly define how the agent must behave ("If SQL fails, try Vector DB; if that fails, ask for human help").

It says: "First, go to SQL for facts; if that's not enough, look into the Vector DB; check the result; if it's junk, go back for another cycle."

Architecture Instead of Magic 🏗️

A modern AI agent is architecture. Calling it "intelligence" in the full sense of the word is strange, but the fact that we are all now "vibe-coders" living in a statistical matrix is a reality!

The 2026 React Native Blueprint

Maxim — Sat, 28 Mar 2026 16:50:48 +0000

I didn’t write this post to chase trends. I wrote it to make sense of the noise, especially all the AI hype, and get back to what actually helps. Boilerplates still matter. They just need to be built with more care for the realities of modern development.

we do need boilerplates
but we need better ones

At first, it felt fine. It helped us move quickly, and early on, that was exactly what we needed.

As data has grown exponentially — driven by IoT — thousands of events, heavier logging, deeper syncing, more real-world complexity — that early convenience started to show its limits..
The app felt sluggish, and dependencies upgrades became something to approach carefully rather than casually.

Around that same time, I had a couple of months to step back and rethink what I wanted from a modern mobile stack. I explored newer tools, like Biome for a more unified code-quality setup. And because my access to the database and cloud code was limited, I had to be more creative — which is what pushed me toward TanStack Query and its built-in caching, background refetching, persistence support, and offline-friendly patterns.

Eventually, I came to a simple conclusion:

I didn’t want to keep extending an old foundation.

I wanted to build one that reflected how I want to develop now.

That’s why I built react-native-bare-starter.

The Storage Shift: MMKV over AsyncStorage

Storage is one of those things users never think about — until they feel it.

If saving a preference causes a small pause, or if reading persisted data slows down the experience, the app starts to feel less polished than it should.

That’s why I moved to MMKV as it's widely known for being significantly faster than AsyncStorage, and more importantly, it feels better in the places that matter: startup time, persistence, reads, and those tiny moments where responsiveness shapes trust.

I also wasn’t trying to build around the most experimental path possible. I chose a version that works well, with a setup that feels practical and stable.

Because a starter should not be a demo.
It should be a dependable base.

Agnostic by Design, Flexible on Purpose

Most apps begin with one backend, but very few stay that simple forever.

Maybe the first version uses Firebase.

Maybe the company already has a REST API.

Maybe the team prefers GraphQL.

Over time, needs change. Teams evolve. Infrastructure shifts.

And when that happens, I don’t want the UI layer to absorb the cost.

So this starter is built around an agnostic transport layer. The goal is straightforward: feature logic should not care where data comes from.

By using adapters, the app stays flexible without becoming chaotic.

Decoupled logic keeps features independent from the underlying transport.
Swappable adapters make it easier to move between Firebase, REST, GraphQL, WebSockets, or mock services.
Minimal UI impact means backend changes don’t force a rewrite of every screen.

It’s a way to build for the backend you have today without overcommitting the product to it forever.

Server State and Offline-First Thinking

Offline support is easy to postpone when everything works nicely on stable Wi-Fi.

But mobile apps don’t live in perfect conditions. People use them in elevators, on trains, in parking garages, and in places where connectivity is inconsistent at best.

So in this starter, offline-first thinking is part of the foundation.

By combining TanStack Query, MMKV persistence, and queue/replay logic, the app is designed to handle temporary network loss with more grace.

That matters because reliability on mobile is not just about features.

It’s about behavior when conditions are less than ideal.

Permission Mapping, So You Spend Less Time Hunting Docs (A Gift file)

I also included a pre-mapped catalog of native permissions for Bare React Native.

It’s a small addition, but it saves real time — especially when switching contexts between JavaScript and native configuration, check **repo doc

Under the Hood (v1.0.2)

This starter currently includes:

Bare React Native 0.82.1 — full native control means full!
React Navigation 7.x — stacks, tabs, and modals already wired
Zustand 5.x — lightweight global state
MMKV Storage — react-native-mmkv via Nitro Modules
🔌 Pluggable transport — adapters for REST, GraphQL, WebSocket, and Firebase, so you can change backend strategy without rewiring the app
SVG automation — scripted icon generation with npm run gen:icons
Biome 2.x — a single source of truth for formatting and linting
Theming - system / light / dark
i18next 25.x — typed translations with a custom useT() hook
BootSplash 6.x — native splash screen setup

As i mentioned above: the goal wasn’t to chase trends.

It was to assemble a stack that feels durable, understandable, and easier to maintain as the app becomes more complex.

Get the Code

maximcoding/react-native-bare-starter

This starter is still being pressure-tested in real work, and I’m planning to carry it into my next few ideas as well. If you’d like to jump in, contribute, and help shape where it goes next, you’re more than welcome.