DEV Community: Shiv Rai (S_RAI)

Why A Generator Built for the Second Run Makes Sense

Shiv Rai (S_RAI) — Sun, 04 Oct 2026 18:36:15 +0000

First impressions

At first, I understood little of what Jostraca does.

The first line, "Regenerate a file tree after manual edits," may raise the question, "Why would someone do that?". Because that's not the normal workflow.

Scaffold?
The examples of scaffolds or starter templates may sound more common and understandable -
"create-next-app" simply creates a Next.js starter app that you can begin customizing. But after you have made edits, there is almost never a need to re-generate the app (by deleting the project and generating it again, or by generating a fresh copy elsewhere).
But that is not what Jostraca does.
It is not related to commands that spin up a starter project with templates you are meant to edit and never touch the generation command again.

Layer?
After reading a bit, I started to think "Is it a layer over existing generators?". Consider generators like Prisma Generator: you write the specifications, run the generator, and now have the artifacts needed for your project and can use them.
If Jostraca is a layer between the existing generator and its generated output, you could edit that output and still preserve those edits when regenerating artifacts after specification changes.
And the answer is "NO". Jostraca is not a layer that sits on top of existing generators such as Prisma Generator.

Generator Framework
Like how Nextjs is a framework for creating websites, Jostraca is a framework for creating generators.

The homepage might seem a bit ambiguous and not easily understandable but complete the tutorial at https://jostraca.org/docs/tutorial/ (or https://github.com/jostraca/jostraca/blob/main/docs/tutorial.md) and you will have most of the information about how to work with Jostraca.

Where Jostraca finds its place

Jostraca finds its place among developers who are building generators.
Generators like:

SDK generators that need to be regenerated when APIs change.
Internal company templates that evolve over time.
Boilerplate systems shared across multiple teams.
Code generators where developers are expected to customize generated output.

Any system or product where regeneration should not erase hours of work is a potential use case for Jostraca.

Where Jostraca does not find its place

Jostraca does not find its place in one-time scaffolding tools, starter templates, or generators whose output is never expected to be regenerated. If the generation is meant to run only once, then Jostraca has little benefit.
For these cases, a simpler scaffolding approach is both - sufficient and efficient.

Following the tutorial

Following the tutorial will give you the knowledge needed to use Jostraca effectively - as the generator framework it is meant to be.
Although you might not understand everything in the tutorial immediately, as you progress in the tutorial, much of it will make sense.

Coding Example

To explore Jostraca beyond the tutorial, I built a small Math Toolkit Generator. The generator takes a simple configuration object (project name, version, functions, and feature flags) and produces a small project containing JavaScript functions, documentation, configuration files, and a basic HTML interface.

Coding example at Github: https://github.com/ShivRaiGithub/Jostraca-math-toolkit

The goal was to observe how different files and different modes behave when the generator is run a second time after a developer has modified them.

The project contains several file types, each using a different regeneration strategy:

basicFunctions.js is fully generated from configuration. If a new function such as power() is added to the config, the file is completely regenerated. This makes sense because it is pure generated code and should always reflect the latest configuration.
customFunctions.js contains user-owned code and a generated section. On regeneration, only the generated block is updated while user-written functions remain untouched. This allows developers to extend the project safely.
userNotes.md is protected using JOSTRACA_PROTECT. Since notes are entirely user-owned content, the generator never modifies the file after creation.
README.md and package.json are regenerated every run because they are derived entirely from the current configuration and should stay synchronized.
index.html uses Jostraca's merge functionality. Generated UI elements, such as operation buttons, can be updated while preserving user customizations like additional styling or custom sections.
latest-updates.txt demonstrates preservation. When regenerated, the previous version is stored as a backup, allowing the history of generated output to be retained.
config-summary.json demonstrates diff mode. Instead of automatically replacing content, Jostraca writes explicit EXISTING and GENERATED blocks so changes can be reviewed before being accepted.

There are two scripts, run and run2, in package.json that execute the generator using two different configuration files. Running the generator clearly demonstrated how each regeneration strategy behaves and, more importantly, why different files often require different update policies.

Observations after working with Jostraca

The Complexity in theory

You might think you understand what Jostraca does at first, but questions start to arise once you think more deeply about it. The complexity is not in using Jostraca. It's in understanding what problem it solves. Most developers are familiar with one-time scaffolding tools, but not with tools designed for regeneration.

The Simplicity in working

You only need a single package, jostraca (installable via npm install jostraca), to get started.
Even simple generators can be created by executing a single file containing Jostraca code.

Although understanding the problem Jostraca solves may take some time, getting a basic generator running requires surprisingly little code.

The 5 modes

Jostraca provides five modes that determine what happens to an already-generated file. The 5 modes being write, preserve, present, diff,merge - each enabling a specific action to be taken. This allows different files in a generated project to follow different regeneration policies rather than treating every file the same way.

My favorite part

The feature I found most interesting in Jostraca was "JOSTRACA_PROTECT".
This essentially provides a very strong option for the user to safeguard any generated file and prevent any further edits by the generator.
Any file containing this string is protected from modifications triggered by regeneration.

A point to note

One behavior that surprised me was template path resolution. When using Fragment with an HTML template, the from path is resolved relative to the output folder, not the generator script itself. This meant I had to reference the template from the perspective of ./out, which felt unusual at first.

Final Verdict

Jostraca is not a tool for every developer, and it does not try to be. Most application developers will never need regeneration-aware code generation. However, for developers building generators, SDK tooling, or long-lived templates, Jostraca provides a practical set of mechanisms for handling generated files after users start modifying them.

Event driven systems: Webhook vs EventBridge-style API vs Event Sourcing vs CQRS

Shiv Rai (S_RAI) — Fri, 18 Sep 2026 14:40:48 +0000

What are Event-Driven Systems?

Instead of requesting information or invoking functionality directly, event-driven systems communicate by publishing facts about things that have already occurred.

Examples include:

Order placed
Payment completed
User registered
Invoice generated
Shipment delivered

The event itself does not tell consumers what to do. It simply communicates that something happened. Consumers decide independently whether and how to react.

Modern systems are often composed of many independent services, applications, and teams. Direct communication creates dependencies between those systems. Events reduce coupling by allowing producers and consumers to evolve independently.

Common use cases include:

System integration
Business process automation
Distributed architectures
Audit and compliance systems
Event-driven workflows
Data synchronization
Reactive applications

Messaging systems and event-driven systems are often used together, but they are not the same thing. Messaging systems provide transport infrastructure, while event-driven systems define how systems communicate and coordinate through events.

This article covers: Webhook, EventBridge-style API, Event Sourcing, CQRS

Event-Driven Integration vs Event-Driven Architecture

This category contains two related but distinct concepts.

Event-Driven Integration focuses on moving events between systems.

Examples include:

Webhooks
EventBridge-style APIs

The goal is integration and event distribution.

Event-Driven Architecture (EDA) focuses on how applications are internally designed around events.

Examples include:

Event Sourcing
CQRS

The goal is modeling, storing, and processing business behavior through events.

A useful rule of thumb:

Integration technologies help systems communicate.
Architectural patterns help systems organize and process information internally.

The Purpose

Technology	Type	Primary Purpose
Webhooks	Event-Driven Integration Mechanism	Notify external systems when events occur
EventBridge-style APIs	Event Routing & Integration Platform	Distribute events across multiple systems and consumers
Event Sourcing	Architectural Pattern	Store application state as a sequence of events
CQRS	Architectural Pattern	Separate command and query responsibilities

These technologies are frequently combined:

A webhook may notify an external system about an event generated internally.
EventBridge-style platforms may distribute events originating from Event Sourcing systems.
Event Sourcing and CQRS are often used together to build event-driven applications.
CQRS systems frequently consume events transported through messaging infrastructure.

Decision Tree

Integration and internal architecture are independent decisions — a system may need one, the other, or both at the same time.

How should events be integrated externally?

Webhooks are usually the simplest choice for notifying external systems.
EventBridge-style APIs become valuable when events must be routed to multiple consumers or across many systems.

flowchart TD

A1[How should events be<br/>integrated externally?] --> B1{Need simple notifications<br/>to external systems?}

B1 -->|Yes| WEBHOOKS[Webhooks]
B1 -->|No — multiple consumers<br/>or systems involved| EVENTBRIDGE[EventBridge-style APIs]

How should events be handled internally?

Event Sourcing is most useful when event history itself becomes a business requirement.
CQRS is most useful when read and write workloads have significantly different requirements.
Event Sourcing + CQRS often appears in complex event-driven systems where auditability, scalability, and specialized read models are important.

flowchart TD

A2[How should events be<br/>handled internally?] --> D{Need a complete historical<br/>record of state changes?}

D -->|No| E{Need independent read and<br/>write models or optimized queries?}

E -->|No| F[Traditional Architecture]
E -->|Yes| CQRSONLY[CQRS Alone]

D -->|Yes| G{Need independent read and<br/>write models or optimized queries?}

G -->|No| ES[Event Sourcing Alone]
G -->|Yes| ESCQRS[Event Sourcing + CQRS]

A system might, for example, use Webhooks for external notifications while internally combining Event Sourcing with CQRS — the two trees are meant to be walked separately, not as a single either/or choice.

Comparison

Aspect	Webhooks	EventBridge-style APIs	Event Sourcing	CQRS
Category	Event-Driven Integration	Event Routing & Integration	Architectural Pattern	Architectural Pattern
Abstraction Level	Integration Mechanism	Event Distribution Platform	State Management Pattern	Read/Write Separation Pattern
Primary Purpose	Notify external systems	Route and distribute events	Store state changes as events	Separate commands and queries
Stores Events?	No	Sometimes platform-dependent	Yes	No
Event Routing?	Basic	Core capability	No	No
External Integration?	Yes	Yes	Indirectly	Indirectly
Internal Architecture?	No	No	Yes	Yes
Historical Replay?	Limited	Platform-dependent	Core capability	No — only available when paired with Event Sourcing
Complexity	Low	Medium	High	Medium to High
Typical Use Cases	Third-party integrations, notifications	Event distribution, cloud integrations	Auditability, financial systems, workflow tracking	High-scale systems, specialized read models
Strengths	Simple, widely supported, easy adoption	Centralized event routing and fan-out	Complete event history and replayability	Flexible scaling and optimized read/write paths
Weaknesses	Limited routing and reliability guarantees	Additional infrastructure and operational complexity	Significant modeling and operational complexity	Additional architectural complexity

Webhooks

Webhooks emerged in the mid-2000s. Webhooks were never a formal protocol. They evolved as a practical integration pattern. Early APIs polled data:

Your App
    |
GET /status
    |
No Change

Wait

GET /status
    |
No Change

Wait

GET /status

As SaaS products grew, polling became inefficient.

Companies needed a better way to notify customers about events.

Webhooks answer: How can one system notify another system immediately when something happens?

Instead of:

Consumer
   |
"Anything new?"

repeatedly,

the producer says:

"I'll call you when
something happens."

This transformed API integrations.

Webhooks think in callbacks

Core assumption: The consumer provides a URL and waits for events.

Instead of:

Client ---> Server

you get:

Client gives URL

Server ---> Client

The direction reverses.

Example

Suppose a payment succeeds.

Provider sends:

POST /webhook

Content-Type: application/json

Body:

{
  "event": "payment.succeeded",
  "amount": 100
}

Your application receives:

app.post("/webhook", (req, res) => {
  console.log(req.body);

  res.sendStatus(200);
});

Output:

{
  "event": "payment.succeeded",
  "amount": 100
}

Pros and Cons

Pros	Cons
Extremely simple	Reliability must be handled carefully
Real-time notifications	Consumer must expose a public endpoint
Eliminates polling	Duplicate deliveries can occur
Uses standard HTTP	Debugging failures can be difficult
Easy cross-company integrations	No built-in replay mechanism
Widely supported by SaaS platforms	Not ideal for high-volume streams
Low infrastructure requirements	Limited delivery guarantees

EventBridge-Style APIs

Cloud-native event buses emerged in the late 2010s as cloud providers looked to formalize the producer-announces, consumers-react pattern as a managed service. AWS EventBridge launched in 2019, followed by comparable services like Azure Event Grid and Google Eventarc. These platforms popularized event-driven integration at scale, giving teams a managed event bus instead of building and operating one themselves.

As systems became more distributed, organizations ended up with architectures like:

User Service
     |
     +--> Email Service
     |
     +--> Analytics
     |
     +--> Billing
     |
     +--> CRM

Every new consumer required another integration.

Over time:

One Event
      |
Ten Integrations
      |
Twenty Integrations

became difficult to manage. EventBridge-style systems answer: How can services publish events once and allow anyone to react without creating direct integrations?

Instead of:

Producer
   |
Many Consumers

they introduce:

Producer
   |
Event Bus
   |
Many Consumers

The producer knows only about the bus.

EventBridge thinks in business events

Core assumption: Systems should announce facts, not call other systems.

Instead of:

Order Service
   |
Call Email Service

you get:

Order Service
   |
OrderCreated Event
   |
Event Bus
   |
Email Service Reacts

Example

Publish Event

{
  "source": "orders",
  "type": "OrderCreated",
  "data": {
    "orderId": 123
  }
}

Event Rule

{
  "type": "OrderCreated"
}

Target

Email Service

When an order is created:

Order Service
      |
OrderCreated
      |
Event Bus
      |
Email Service

The email service automatically receives the event.

Pros and Cons

Pros	Cons
Loose coupling between services	Harder debugging and tracing
Easy to add new consumers	Eventual consistency
Excellent for event-driven systems	Event schema versioning challenges
Centralized routing rules	Hidden dependencies can emerge
Strong cloud integration	Not suitable for request/response
Scales organizationally	Added architectural complexity
Enables automation workflows	Less predictable execution paths

Event Sourcing

Event Sourcing became a mainstream architectural pattern around 2008–2012.

Most applications store current state and lose history.

Example:

500 -> 700 -> 400 -> 900

After updates, only 900 remains.

Organizations wanted auditability, traceability, and rebuildability without relying on fragile audit tables. Event Sourcing answers: What if we stored every change instead of only the latest state?

Instead of:

Current Balance = 900

store:

AccountOpened
MoneyDeposited(200)
MoneyWithdrawn(300)
MoneyDeposited(500)

The current state can always be reconstructed.

Event Sourcing thinks in facts, not state

Core assumption: The sequence of events matters more than the current state.

Instead of:

User
------
Name: Alice
Plan: Pro

store:

UserRegistered
PlanUpgraded

Current state becomes a derived value.

Example

Traditional CRUD

UPDATE accounts
SET balance = 500
WHERE id = 1;

Result:

Balance = 500

Previous history may be lost.

Event Sourcing

Append event:

{
  "type": "MoneyDeposited",
  "amount": 100
}

Then:

{
  "type": "MoneyWithdrawn",
  "amount": 50
}

Current balance is computed from events:

+100
-50
----
50

Pros and Cons

Pros	Cons
Complete audit trail	Significant complexity
Event replay capability	Event schema evolution challenges
Time-travel debugging	Eventual consistency
Strong compliance support	Steep learning curve
Natural fit for event-driven systems	Storage growth over time
Easier historical analysis	More infrastructure and tooling
Rebuild projections anytime	Overkill for simple CRUD systems

CQRS

CQRS (Command Query Responsibility Segregation) was introduced by Greg Young around 2010.

Most applications use a single model for both:

Reading Data
Writing Data

Example:

User Table
      |
 Read Users
 Update Users
 Delete Users
 Create Users

This works well initially.

But large systems often discover that read traffic doesn't match write traffic.

For example, Instagram might see millions of reads but only thousands of writes per second.

CQRS answers: What if reads and writes were treated as separate concerns?

Instead of one model for everything, CQRS introduces:

Write Model
     |
Read Model

Each side can be optimized independently.

CQRS thinks in commands and queries

Core assumption: The way you update data is often different from the way you retrieve it.

Example: Updating an order:

Validate
Authorize
Apply Business Rules

Viewing an order:

Fetch
Format
Display

These concerns do not necessarily belong in the same model.

Example

Traditional CRUD

Orders Table

Used for:

SELECT *
FROM orders

and:

UPDATE orders
SET status='shipped'

Same model.

CQRS

Write side:

ShipOrder Command

Read side:

OrderDetails Query

Two separate paths.

Command
   |
Write Model

Query
   |
Read Model

Pros and Cons

Pros	Cons
Independent read/write optimization	Significantly more complexity
Better scalability	Eventual consistency issues
Cleaner domain logic	More infrastructure required
Flexible read models	Harder debugging
Excellent for read-heavy systems	More moving parts to maintain
Natural fit for event-driven architectures	Steeper learning curve
Can improve performance dramatically	Overkill for many applications

Key Takeaways

Use Webhooks when...

External systems need notifications
Integration requirements are relatively simple
You want the lowest operational overhead

Use EventBridge-style APIs when...

Events must be distributed to multiple consumers
Systems are highly decoupled
Centralized event routing is valuable

Use Event Sourcing when...

Event history is a business requirement
Auditability and replayability matter
State changes must be preserved permanently

Use CQRS when...

Read and write workloads have different requirements
Query performance becomes a concern
Independent scaling of commands and queries is beneficial

Use Event Sourcing + CQRS when...

Building complex event-driven systems
Historical event storage and specialized read models are both required
Additional architectural complexity is justified by business needs

Messaging Systems: MQTT vs AMQP vs RabbitMQ vs Kafka vs NATS vs Apache Pulsar

Shiv Rai (S_RAI) — Thu, 17 Sep 2026 13:50:50 +0000

What are messaging systems?

Messaging systems enable applications to communicate by exchanging messages through shared infrastructure rather than communicating directly with each other.

In direct communication models, a sender typically expects the receiver to be available and responsive at the time of the interaction. Messaging systems remove this dependency by introducing intermediaries that can receive, store, route, and deliver messages independently of the sender and receiver.

This approach exists because distributed systems are inherently asynchronous. Services fail, networks become unreliable, workloads spike unexpectedly, and systems evolve independently. Messaging infrastructure helps absorb these realities by decoupling producers from consumers.

Common building blocks include:

Brokers that receive, route, and deliver messages
Queues that distribute work among consumers
Topics that publish messages to multiple subscribers
Consumers that process messages independently of producers

Common use cases include:

Background job processing
Microservice communication
Event distribution
Data pipelines
IoT telemetry
Workflow orchestration
Stream processing
System integration

This article covers: MQTT, AMQP, RabbitMQ, Kafka, NATS, Apache Pulsar

Understanding the Technologies

Not all technologies in this category solve the same problem or exist at the same architectural layer. Some define how messages are transmitted, while others provide the infrastructure that stores, routes, and delivers those messages.

Technology	Category	Primary Focus
MQTT	Messaging Protocol	Lightweight communication for constrained devices and unreliable networks
AMQP	Messaging Protocol	Standardized broker-based messaging and routing
RabbitMQ	Message Broker	Traditional queue-based messaging and work distribution
Kafka	Event Streaming Platform	Durable event streams and large-scale data pipelines
NATS	Messaging System	Lightweight, low-latency messaging and service communication
Apache Pulsar	Messaging & Streaming Platform	Unified messaging and event streaming infrastructure

Some choices are complementary rather than competing.

For example:

MQTT messages are often transported through MQTT brokers.
RabbitMQ commonly implements AMQP concepts and protocols — specifically the AMQP 0-9-1 dialect, not the later OASIS-standardized AMQP 1.0. AMQP is the protocol specification; RabbitMQ is one concrete, operable broker that implements it.
Kafka and Pulsar are typically chosen for event-streaming workloads rather than traditional work queues.
NATS focuses on lightweight messaging rather than long-term event storage.

Decision Tree

MQTT is typically chosen when devices operate on unreliable, low-bandwidth, or battery-constrained networks.
AMQP is a protocol standard rather than a product you deploy directly; in practice, most teams get AMQP-style messaging by choosing RabbitMQ, which implements the widely-adopted AMQP 0-9-1 dialect.
RabbitMQ is often the default choice for traditional queues, task distribution, and workflow orchestration.
Kafka is most compelling when messages become long-lived streams of data that must be replayed and processed repeatedly.
NATS is optimized for lightweight, low-latency service communication.
Pulsar becomes attractive when both messaging and streaming capabilities are needed within the same distributed platform.

flowchart TD

A[Need Messaging Infrastructure] --> B{Communicating with<br/>devices over unreliable<br/>or constrained networks?}

B -->|Yes| MQTT[MQTT]

B -->|No| C{Need durable event streams,<br/>replay, and data pipelines?}

C -->|Yes| D{Need large-scale multi-tenancy,<br/>geo-distribution, or both messaging<br/>and streaming in one platform?}

D -->|Yes| PULSAR[Apache Pulsar]
D -->|No| KAFKA[Kafka]

C -->|No| E{Need traditional queues,<br/>routing, and work distribution?}

E -->|Yes| RABBIT[RabbitMQ<br/>implements AMQP 0-9-1]

E -->|No| G{Need lightweight,<br/>low-latency service messaging?}

G -->|Yes| NATS[NATS]
G -->|No| RABBIT

Comparison

Aspect	MQTT	AMQP	RabbitMQ	Kafka	NATS	Apache Pulsar
Category	Protocol	Protocol	Broker Platform	Event Streaming Platform	Messaging System	Messaging & Streaming Platform
Primary Model	Pub/Sub messaging	Broker-based messaging standard	Queues and routing	Distributed event log	Lightweight messaging and pub/sub	Unified messaging and streaming
Messaging vs Streaming	Messaging	Messaging	Messaging	Streaming-first	Messaging	Messaging + Streaming
Message Persistence	Optional	Protocol-dependent	Strong persistence support	Core design principle	Optional	Core design principle
Delivery Guarantees	Configurable QoS levels	Protocol-defined guarantees	Strong acknowledgment model	Strong durability and replay	Configurable depending on deployment mode	Strong durability and acknowledgment model
Throughput Profile	Device-oriented workloads	Moderate	Moderate	Very high	High	Very high
Latency Profile	Low	Moderate	Low to moderate	Low	Very low	Low
Scalability Model	Device fleets	Broker-dependent	Clustered broker scaling	Distributed partitions	Distributed messaging fabric	Distributed storage and brokers
Ordering Model	Limited and workload-dependent	Implementation-dependent	Queue ordering	Partition ordering	Subject ordering	Partition ordering
Operational Complexity	Low	Varies by implementation	Medium	High	Low	High
Ecosystem Maturity	Mature	Mature standard	Very mature	Very mature	Mature	Mature
Typical Use Cases	IoT, telemetry, edge devices	Enterprise interoperability	Background jobs, workflows, task queues	Event streaming, analytics, CDC, data platforms	Service communication, cloud-native systems	Multi-tenant platforms, messaging and streaming
Strengths	Efficient on constrained networks	Standardized interoperability	Mature queueing and routing model	Replayability, durability, ecosystem, scale	Simplicity, speed, low operational overhead	Combines queueing and streaming capabilities
Weaknesses	Not intended for large-scale stream processing	Requires a broker implementation	Less suited for event-streaming workloads	More complex than traditional messaging systems	Not designed as a long-term event log	More operationally complex than simpler alternatives

Messaging vs Streaming

If you need...	Usually Start With
Background jobs and work queues	RabbitMQ
Task distribution	RabbitMQ
Enterprise broker-based messaging	RabbitMQ / AMQP
Device communication	MQTT
Service-to-service messaging with minimal latency	NATS
Durable event streams and replay	Kafka
Unified messaging and streaming	Pulsar

If messages are consumed once and discarded -> Messaging
If messages become a durable history that multiple consumers may replay-> streaming

MQTT

MQTT (Message Queuing Telemetry Transport) was created in 1999. At the time, many devices operated under severe constraints:

Oil Pipeline Sensors
Satellite Links
Industrial Equipment
Remote Monitoring Systems

These environments often had:

High latency
Expensive bandwidth
Intermittent connectivity
Low-power hardware

HTTP was considered too heavy. The goal of MQTT was:

Minimal Bandwidth
Minimal Power Usage
Minimal Complexity

MQTT thinks in topics and subscriptions

The model breaks down into:

Publishers
Topics
Subscribers

Instead of:

Device A ---> Device B

you get:

Device A
    |
 Publish
    |
temperature/room1
    |
 MQTT Broker
    |
 Subscribe
    |
Device B

Example

Publisher

client.publish(
  "temperature/room1",
  "24.5"
)

Subscriber

client.subscribe(
  "temperature/room1"
)

Whenever a message arrives:

def on_message(msg):
    print(msg.payload)

Output:

24.5
25.1
24.8

Quality of Service (QoS)

MQTT lets each subscription choose its own delivery guarantee:

QoS 0 – at most once (fire and forget)
QoS 1 – at least once (may deliver duplicates)
QoS 2 – exactly once (highest overhead)

Constrained devices often default to QoS 0 or 1 to save bandwidth and battery, reserving QoS 2 for messages that can't tolerate loss or duplication.

Pros and Cons

Pros	Cons
Extremely lightweight	Requires broker infrastructure
Excellent for IoT	Poor fit for request/response APIs
Low bandwidth usage	Topic design can become complex
Supports unreliable networks	Harder to debug than HTTP
QoS delivery guarantees	Security must be carefully managed
Publisher/subscriber decoupling	Not ideal for CRUD applications
Huge industry adoption	Less suitable for large analytics pipelines

AMQP

AMQP (Advanced Message Queuing Protocol) was first developed around 2003–2006. A stable specification shipped in 2008, with formal standardization through OASIS following in 2012. Large enterprises were building systems that relied heavily on messaging:

Banking
Trading
Payments
Order Processing
Enterprise Integration

Every vendor had its own protocol which often couldn't communicate with each other. AMQP aimed to create a standard protocol for reliable enterprise messaging.

The goal was:

Guaranteed Delivery
Reliable Routing
Transactions
Interoperability

AMQP thinks in a standardized routing model

Core assumption: Routing behavior should be defined by the protocol itself, not by whichever broker happens to run it — so producers, consumers, and brokers from different vendors can all agree on the same messaging semantics.

This is a different mental model from "call a specific broker's API." AMQP is a wire-level specification: it describes exchanges, bindings, and queues as protocol concepts that any compliant broker must implement the same way.

Messages
+
Routing Rules

Example

Producer

channel.basic_publish(
    exchange="orders",
    routing_key="created",
    body="Order #123"
)

Consumer

channel.basic_consume(
    queue="order-service"
)

Producer sends:

Order #123

Consumer receives:

Order #123

Exchanges and Routing

AMQP's "sophisticated" routing comes from exchanges sitting between producers and queues. A producer publishes to an exchange, not directly to a queue, and the exchange decides where the message goes based on its type:

Direct – routes by exact routing-key match
Topic – routes by pattern match (e.g., orders.*)
Fanout – broadcasts to every bound queue
Headers – routes based on message header values

This is what lets a single published message reach multiple queues, or be filtered before it ever reaches a consumer.

Pros and Cons

Pros	Cons
Very reliable delivery	More complex than MQTT
Powerful routing via exchanges	Higher operational overhead
Durable queues and acknowledgements	Heavier protocol footprint
Supports many messaging patterns	Not ideal for large event streams
Mature RabbitMQ ecosystem	Infrastructure can become complex
Strong enterprise adoption	Less suitable for constrained devices
Good for workflows and background jobs	Overkill for simple applications

Kafka

Apache Kafka was created at LinkedIn around 2010 and open-sourced in 2011. LinkedIn's infrastructure was generating massive amounts of events:

Page Views
Clicks
User Activity
Logs
Metrics
Analytics

Different systems needed access to the same data. This created tight coupling and scalability problems. Kafka was designed to answer, "How can thousands of systems continuously produce and consume events at massive scale?" The goal was:

Store Events
Replay Events
Process Events
Scale Horizontally

Kafka is not primarily a message queue.

Kafka is an event streaming platform.

Kafka thinks in event logs

Kafka's model centers on immutable event streams.

Core assumption: Events are valuable records that should be stored, not merely delivered.

Instead of:

Producer
   |
Queue
   |
Consumer
   |
Delete Message

Kafka's approach:

Producer
   |
Append Event
   |
Log
   |
Consumer Reads

The event remains in the log.

This is the most important concept in Kafka.

Example

Producer

producer.send(
    "orders",
    {
      "orderId": 123,
      "status": "created"
    }
)

Consumer

for msg in consumer:
    print(msg.value)

Output:

{
  "orderId": 123,
  "status": "created"
}

The key difference: The event remains stored even after consumption. Another consumer can read it later.

Partitions and Consumer Groups

A Kafka topic is split into partitions, each an ordered, append-only log. Partitioning is what lets Kafka scale horizontally — different partitions can live on different brokers and be written and read in parallel.

Consumers read partitions in consumer groups: Kafka assigns each partition to exactly one consumer within a group, so the group as a whole processes a topic in parallel while each individual partition stays strictly ordered.

Pros and Cons

Pros	Cons
Massive throughput	Operational complexity
Event replay capability	Higher resource requirements
Durable event storage	Not suited for RPC
Excellent scalability	Event schema management can be difficult
Decouples producers and consumers	Eventual consistency challenges
Strong ecosystem and tooling	Can be overkill for small systems
Ideal for analytics and event-driven systems	Steeper learning curve

NATS

NATS was created by Derek Collison and first released around 2011. Around the early 2010s, distributed systems (Microservices, Containers, Cloud Platforms, Service Meshes) were becoming increasingly common. Existing messaging systems often fell into two categories:

RabbitMQ → Feature Rich
Kafka → Massive Scale

But many teams wanted:

Simple
Fast
Reliable
Cloud Native

without operating a large messaging platform.

NATS was designed to answer: What's the simplest possible way for distributed services to communicate?

The philosophy was:

Small Protocol
Small Server
Low Latency
High Simplicity

NATS thinks in subjects

Core assumption: Services should communicate through lightweight, hierarchical subjects rather than pre-declared queues or topics.

Subjects are just dot-separated strings, and wildcards let a subscriber match many subjects at once without the publisher and subscriber agreeing on a fixed topic list in advance:

orders.created     # exact subject
orders.*           # matches orders.created, orders.cancelled, etc.
orders.>           # matches orders.created, orders.us.created, and deeper

Example

Publisher

nc.Publish(
  "orders.created",
  []byte("123")
)

Subscriber

nc.Subscribe(
  "orders.created",
  func(msg *nats.Msg) {
    fmt.Println(
      string(msg.Data)
    )
  },
)

Output:

JetStream

By default, core NATS messages are fire-and-forget — if no one is subscribed when a message is published, it's gone. JetStream is NATS's built-in persistence layer: it adds durable storage, message replay, and at-least-once delivery on top of core NATS subjects. It's what lets NATS take on some Kafka-like use cases, at the cost of some of the operational simplicity that makes core NATS attractive in the first place.

Pros and Cons

Pros	Cons
Extremely low latency	Smaller ecosystem
Operationally simple	Less suited for analytics workloads
Lightweight deployment	JetStream increases complexity
Excellent for microservices	Fewer integrations than Kafka
Supports pub/sub and RPC	Smaller talent pool
Cloud-native friendly	Not ideal for long-term event storage
Easier to run than Kafka/RabbitMQ	Less proven for huge data platforms

Apache Pulsar

Apache Pulsar was originally developed at Yahoo around 2013 and open-sourced in 2016. Yahoo operated some of the world's largest messaging and data systems:

Mail
News
Advertising
Search
Analytics

At that scale, traditional messaging systems began showing limitations. Particularly:

Storage Scaling
Broker Scaling
Multi-Tenancy
Geo Replication

Kafka was already successful, but Yahoo wanted a different architecture. Most messaging platforms looked like:

Broker
  |
Storage

Pulsar introduced:

Broker
  |
Storage Layer

as separate components.

Pulsar thinks in event streams with separated compute and storage

Core assumption: Messaging and storage should scale independently.

Instead of:

Broker
  |
Stores Data

Pulsar:

Broker
  |
Reads/Writes
  |
Storage System

This creates more flexibility at scale. In practice, it means brokers can be added or removed to handle more traffic without touching how data is stored, and storage capacity can grow independently to hold more history — something a coupled broker-and-storage design can't do without rebalancing both at once.

Example

Producer

Producer<String> producer =
    client.newProducer()
        .topic("orders")
        .create();

producer.send(
    "Order Created"
);

Consumer

Consumer<String> consumer =
    client.newConsumer()
        .topic("orders")
        .subscriptionName("billing")
        .subscribe();

Receive:

Message<String> msg =
    consumer.receive();

Looks very similar to Kafka but architecturally different.

Pros and Cons

Pros	Cons
Independent compute and storage scaling	More complex architecture
Built-in multi-tenancy	Smaller ecosystem
Native geo-replication	Fewer experienced operators
Supports queues, streams, and pub/sub	More moving parts
Durable storage via BookKeeper	Higher operational complexity
Strong cloud-native support	Kafka tooling ecosystem is larger
Excellent for large organizations	Often overkill for smaller systems

RabbitMQ

RabbitMQ was first released in 2007 by Rabbit Technologies and is one of the most widely adopted implementations of AMQP. Specifically, RabbitMQ is built around AMQP 0-9-1, an earlier and more widely deployed dialect than the later OASIS-standardized AMQP 1.0 — this is why RabbitMQ isn't automatically wire-compatible with every "AMQP" broker.

Before RabbitMQ, many applications communicated directly:

Service A
    |
Service B

This created problems:

Tight Coupling
Retries
Downtime Propagation
Traffic Spikes

Teams wanted a reliable middle layer that could:

Store Messages
Route Messages
Retry Delivery
Guarantee Processing

RabbitMQ answers: How can services exchange messages reliably without needing to be online at the same time?

Instead of:

Producer
    |
Consumer

you get:

Producer
    |
RabbitMQ
    |
Consumer

The broker acts as a buffer and router.

RabbitMQ thinks in exchanges you actually operate

Core assumption: The abstract routing model AMQP describes needs a real, operable broker behind it — with clustering, a management UI, plugins, and tuning knobs. RabbitMQ is that broker: it implements AMQP's exchange-and-queue routing model and adds its own operational tooling, protocol plugins (including MQTT and STOMP support), and ecosystem on top.

Example:

OrderCreated

Producer sends the message.

RabbitMQ decides:

Email Service
Analytics Service
Inventory Service

should receive it.

Example

Producer

channel.basic_publish(
    exchange="orders",
    routing_key="created",
    body="Order #123"
)

Consumer

channel.basic_consume(
    queue="email-service",
    on_message_callback=handler
)

Message:

Order #123

flows through RabbitMQ.

Pros and Cons

Pros	Cons
Mature and battle-tested	More complex than NATS
Powerful routing via exchanges	Not optimized for event streaming
Strong reliability guarantees	Scaling can become complex
Excellent worker queue support	Lower throughput than Kafka
Durable queues and retries	Ordering can be difficult at scale
Large ecosystem and tooling	More operational overhead
Supports multiple messaging patterns	Not ideal for long-term event retention

Key Takeaway

Choose MQTT for device communication.
Choose RabbitMQ (the practical way to get AMQP-style messaging) for traditional messaging and queues.
Choose NATS for lightweight, low-latency messaging.
Choose Kafka for durable event streams and data platforms.
Choose Pulsar when messaging and streaming must coexist within the same platform.

Real Time Communication: SSE vs WebSockets vs WebRTC

Shiv Rai (S_RAI) — Wed, 16 Sep 2026 11:27:20 +0000

Real Time communication

Real-time communication enables systems to deliver updates as soon as information changes, rather than waiting for clients to ask for new data.

In traditional request/response architectures, a client initiates every interaction. If new information is needed, the client must send another request. Real-time systems invert this pattern by allowing servers to push updates whenever events occur.

Many applications need information immediately. Waiting for users to refresh a page or repeatedly poll an API introduces unnecessary latency, wasted network traffic, and a poorer user experience.

Common use cases include:

Chat and messaging applications
Live dashboards and monitoring systems
Notifications and alerts
Financial market feeds
Collaborative editing tools
Multiplayer games
Live tracking and telemetry systems

The core idea is: instead of repeatedly requesting new information, clients subscribe to a stream of events, exchange messages continuously, or connect directly to another peer, and receive updates as they happen.

This article covers: SSE, WebSockets, WebRTC.

Decision Tree

Server pushes updates and clients mainly consume them -> SSE
Both sides need to exchange information continuously through the server -> WebSockets
Communication happens directly between peers, especially for voice, video, or low-latency data transfer -> WebRTC

flowchart TD

A[Need Real-Time Communication] --> B{Does communication happen<br/>directly between peers rather<br/>than through your server?}

B -->|Yes| C{Building voice/video, or need<br/>low-latency peer-to-peer<br/>data transfer?}

C -->|Yes| WEBRTC[WebRTC]

B -->|No| D{Do clients need to send<br/>real-time messages back<br/>to the server?}

D -->|Yes| WS[WebSockets]

D -->|No| SSE[SSE]

Comparison.

Aspect	WebSockets	Server-Sent Events (SSE)	WebRTC
Mental Model	Persistent conversation between client and server	Continuous stream of server-generated events	Direct peer-to-peer channel for media and data
Communication Direction	Bidirectional	Server → Client only	Bidirectional, directly between peers
Connection Type	Persistent full-duplex connection	Persistent HTTP response stream	Direct peer-to-peer connection, established with signaling assistance
Browser Support	Excellent in modern browsers	Excellent in modern browsers	Excellent in modern browsers
Complexity	Medium	Low	High
Scalability Considerations	Requires managing stateful bidirectional connections	Typically simpler infrastructure and scaling model	Scales well 1:1; group communication needs additional infrastructure (SFU/MCU)
Latency	Very low	Very low	Very low once a direct connection is established
Reconnection Behavior	Usually implemented by application or framework	Built-in automatic reconnection support	Requires handling ICE restarts and renegotiation
Typical Use Cases	Chat, collaboration, multiplayer systems, interactive applications	Notifications, dashboards, monitoring, live feeds, status updates	Video calls, voice calls, screen sharing, peer-to-peer file transfer
Strengths	Full-duplex communication, highly flexible, supports interactive workloads	Simple implementation, HTTP-friendly, automatic reconnection, efficient for broadcasts	Lowest latency for direct exchange, reduces server bandwidth, native media support
Weaknesses	More operational complexity and connection management	No native client-to-server real-time channel	Requires signaling, STUN/TURN infrastructure, and NAT traversal handling

WebSockets

The web followed a simple model:

Browser → Request
Server  → Response

This worked well for websites but became problematic for real-time applications.

Developers had to use techniques like Polling, Long Polling, Comet, and Hidden iframes to simulate real-time communication. These approaches were inefficient because browsers repeatedly asked, "Do you have new data yet?"

WebSockets became an official web standard in 2011 through RFC 6455 and introduced a persistent, full-duplex connection between client and server.

Instead of:

Client -> Request
Server -> Response
Connection Closed

WebSocket provides:

Client <=================> Server
         Always Open

Either side can send data at any time.

WebSockets thinks in conversations

WebSocket is for opening a connection and keeping it open. Once a connection has been established, both sides can continuously exchange messages. Core assumption: The application benefits from a long-lived connection where updates should be delivered immediately.

Example

Client

const socket = new WebSocket(
  "ws://localhost:8080"
);

socket.onmessage = (event) => {
  console.log(event.data);
};

socket.send("hello");

Server (Node.js)

wss.on("connection", (socket) => {
  socket.on("message", (msg) => {
    socket.send(`received: ${msg}`);
  });
});

Communication:

Client -> hello
Server -> received: hello

No new HTTP request is required.

Network compatibility note: Some restrictive corporate networks, proxies, firewalls, or legacy infrastructure can interfere with WebSocket connections. This is one reason some teams prefer SSE or fallback solutions in environments where connectivity is less predictable.

Pros and Cons

Pros	Cons
True real-time communication	Stateful connections
Full duplex messaging	More difficult to scale
Low latency	No built-in durability
Efficient for frequent updates	Harder debugging and observability
Native browser support	Cannot leverage HTTP caching
Reduces polling overhead	Requires connection management
Excellent for interactive applications	Not ideal for CRUD APIs

Server-Sent Events (SSE)

Server-Sent Events (SSE) were introduced as part of the HTML5 specification effort, with early browser implementations appearing around 2009–2011 and the standard later reaching W3C Recommendation status. Before SSE, web applications wanting real-time updates typically used:

Polling
Long Polling
Hidden iframes
Custom Hacks

A common pattern:

Browser
   |
GET /notifications
   |
No updates
   |
Wait 5 seconds
   |
GET /notifications
   |
Repeat forever

This wasted:

Network bandwidth
Server resources
Client resources

Developers needed a standardized way for servers to push updates to browsers. SSE introduced one-way real-time communication from server to client over standard HTTP.

Instead of constantly asking for updates, the browser opens a connection and the server sends updates whenever they occur.

SSE thinks in event streams

Core assumption: The client mostly listens.

Communication looks like:

Server
   |
Events
   |
Browser

not:

Browser <-> Server

SSE is fundamentally one-way.

Example

Server

app.get("/events", (req, res) => {
  res.setHeader(
    "Content-Type",
    "text/event-stream"
  );

  setInterval(() => {
    res.write(
      `data: ${Date.now()}\n\n`
    );
  }, 1000);
});

Browser

const events =
  new EventSource("/events");

events.onmessage = (event) => {
  console.log(event.data);
};

Output:

The browser receives updates automatically.

Pros and Cons

Pros	Cons
Extremely simple API	One-way only
Native browser support	Not ideal for interactive apps
Automatic reconnection	Limited binary support
Uses standard HTTP	Browser-oriented design
Efficient for notifications	Connection limits may apply
Easy to debug	Less flexible than WebSockets
Excellent for streaming updates	Requires separate channel for client-to-server communication

WebRTC

Before WebRTC, real-time voice and video in the browser required proprietary plugins like Flash, Skype's browser plugin, or similar. There was no native way for two browsers to establish a direct connection and exchange audio, video, or data without routing everything through a server.

Google open-sourced WebRTC in 2011, aiming to bring peer-to-peer voice, video, and data communication natively into the browser, without plugins.

WebRTC is now the default technology behind most browser-based video calling, voice calling, and screen-sharing products, and is also used for peer-to-peer data transfer and some multiplayer game architectures.

WebRTC thinks in peers

WebRTC is about connecting two peers directly, so media and data can flow between them without passing through an application server.

Core assumption: once two peers are connected, they exchange real-time media or data directly, with a server only needed to help establish that connection.

Example

Peer A

const peer = new RTCPeerConnection();
const channel = peer.createDataChannel("chat");

channel.onopen = () => {
  channel.send("hello");
};

Peer B

peer.ondatachannel = (event) => {
  event.channel.onmessage = (msg) => {
    console.log(msg.data);
  };
};

Communication:

Peer A -> hello
Peer B -> received directly, no server relay

Pros and Cons

Pros	Cons
Lowest latency for direct peer communication	Significantly more complex to implement
Native audio, video, and data channel support	Requires a signaling mechanism, which WebRTC itself doesn't provide
Reduces server bandwidth costs by avoiding relay	NAT traversal often requires STUN/TURN servers
True peer-to-peer data exchange	Group communication needs additional infrastructure (SFU/MCU)
Configurable reliable or unreliable data channels	Harder to debug than client-server protocols
Excellent for real-time media applications	Connection setup involves multiple negotiation steps
Works directly in modern browsers without plugins	Behavior can be less predictable across restrictive networks

A Note on Delivery Guarantees

Neither SSE nor WebSockets guarantee message delivery while a client is disconnected — messages sent during an outage or a reconnect window can simply be missed. Systems that require durable delivery, replay, or guaranteed-once semantics typically reach for messaging platforms such as Kafka, NATS, RabbitMQ, or Pulsar instead of (or alongside) a real-time transport layer.

Key Takeaways

Choose SSE when you need simple, one-way updates from server to client like: dashboards, notifications, and live feeds.
Choose WebSockets when both sides need to exchange information continuously through your server. Examples: Chat systems, collaborative applications, and multiplayer applications typically need this.
Choose WebRTC when communication should happen directly between peers like voice calls, video calls, screen sharing, or low-latency peer-to-peer data transfer.
Choose polling when updates are infrequent and simplicity or operational ease matters more than immediate delivery.

RPC Systems: JSON-RPC vs XML-RPC vs SOAP vs gRPC vs Apache Thrift vs Connect vs tRPC

Shiv Rai (S_RAI) — Tue, 15 Sep 2026 12:39:45 +0000

What are RPCs?

RPC (Remote Procedure Call) systems allow software running in one process, machine, or service to invoke functionality located somewhere else as if it were a local function call.

The core idea behind RPC is abstraction. Instead of thinking in terms of resources, endpoints, or data representations, developers think in terms of calling procedures, methods, or functions. The networking details are handled by the RPC framework.

In RPC interaction:

A client calls a remote method.
The request is serialized and transmitted over the network.
The remote service executes the procedure.
The result is returned to the caller.
The framework deserializes the response into native language objects.

RPC systems exist because many distributed systems are fundamentally action-oriented rather than resource-oriented. They provide a natural way to model service-to-service communication, business operations, workflows, and internal platform APIs.

Common use cases include:

Microservice communication
Internal platform APIs
Backend-to-backend communication
Distributed systems
Enterprise integrations
High-performance service meshes
Full-stack TypeScript applications

This article includes: XML-RPC, SOAP, JSON-RPC, gRPC, Apache Thrift, Connect, tRPC

How to Choose ?

Full-stack TypeScript development -> tRPC
Modern microservices, HTTP/2, and streaming -> gRPC
gRPC-style APIs needing broad HTTP compatibility (browser and backend) -> Connect
Existing Thrift ecosystems or cross-language protocol/transport flexibility -> Apache Thrift
Enterprise and standards-driven integrations -> SOAP
Lightweight RPC over JSON -> JSON-RPC
Legacy XML-RPC interoperability -> XML-RPC

flowchart TD

A[Need an RPC System] --> B{Entire stack uses TypeScript?}

B -->|Yes| C{Need end-to-end<br/>TypeScript inference?}
C -->|Yes| TRPC[tRPC]
C -->|No| D

B -->|No| D{Need broad HTTP compatibility<br/>across browser and backend clients?}

D -->|Yes| CONNECT[Connect]
D -->|No| E

E{Building internal<br/>microservices?}

E -->|Yes| F{Already using Thrift, or need<br/>flexible protocols/transports<br/>across many languages?}

F -->|Yes| THRIFT[Apache Thrift]
F -->|No| GRPC[gRPC]

E -->|No| G

G{Enterprise integration<br/>or WS-* requirements?}

G -->|Yes| SOAP[SOAP]
G -->|No| H

H{Must integrate with<br/>legacy XML-RPC systems?}

H -->|Yes| XMLRPC[XML-RPC]
H -->|No| JSONRPC[JSON-RPC]

Comparison

Aspect	JSON-RPC	XML-RPC	SOAP	Apache Thrift	gRPC	Connect	tRPC
Mental Model	Remote method calls	Remote method calls	Service operations and contracts	Shared contracts across languages	Fast, contract-driven function calls	Service methods	Type-safe function calls
Transport Protocol	Usually HTTP, WebSocket, TCP	Usually HTTP	Usually HTTP	Multiple transports	HTTP/2	HTTP/1.1 and HTTP/2	HTTP
Serialization Format	JSON	XML	XML	Binary protocols	Protocol Buffers	Protocol Buffers or JSON	Native TypeScript types over JSON
Performance	Medium	Low	Low	High	Very High	High	Medium
Type Safety	Low	Low	Medium	High	High	High	Very High
Browser Support	Excellent	Good	Good	Limited	Limited without proxies	Excellent	Excellent
Language Support	Broad	Broad	Broad	Broad	Broad	Broad	TypeScript-focused
Complexity	Low	Low	High	Medium	Medium	Medium	Low
Typical Use Cases	Lightweight APIs, protocol integrations	Legacy systems	Enterprise integrations	Polyglot backend systems	Microservices, platform infrastructure	Browser-friendly RPC, modern APIs	Full-stack TypeScript applications
Strengths	Simplicity, easy tooling, human-readable	Simplicity and legacy compatibility	Standardization, enterprise features	Efficient cross-language communication	Performance, streaming, ecosystem	Interoperability and browser support	Outstanding developer experience
Weaknesses	Weak contracts and typing	Verbose XML and limited capabilities	Complexity and operational overhead	Smaller ecosystem than gRPC	Browser constraints and operational complexity	Newer ecosystem	Limited outside TypeScript

Evolution View

Era	Common Technologies	Primary Goal
Early Web Services	XML-RPC, SOAP	Standardized remote communication over HTTP
Distributed Service Platforms	Apache Thrift	Efficient cross-language RPC
Cloud-Native Systems	gRPC	High-performance service communication
Modern Web-Friendly RPC	Connect	Better HTTP and browser interoperability
TypeScript-First Development	tRPC	End-to-end type safety and developer productivity

XML-RPC

In the late 1990s, distributed systems were difficult to integrate. Common approaches included:

CORBA
DCOM
RMI
Custom TCP Protocols

These were often:

Vendor-specific
Complex
Difficult to integrate across platforms

Developers wanted something that worked over HTTP using XML. XML-RPC was created in 1998 and provided a simple way to:

Call a function
Across a network
Using HTTP

It was one of the first widely adopted web-service protocols.

XML-RPC thinks in remote function calls

XML-RPC assumes: Services expose methods, and clients call those methods remotely. Instead of:

GET /users/123
POST /orders

XML-RPC says:

getUser(123)
createOrder(...)

Core assumption: Network services should look like callable functions.

Example

Request

<?xml version="1.0"?>
<methodCall>
  <methodName>getUser</methodName>
  <params>
    <param>
      <value>
        <int>123</int>
      </value>
    </param>
  </params>
</methodCall>

Response

<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value>
        <struct>
          <member>
            <name>id</name>
            <value><int>123</int></value>
          </member>
          <member>
            <name>name</name>
            <value>Alice</value>
          </member>
        </struct>
      </value>
    </param>
  </params>
</methodResponse>

This is effectively getUser(123) over HTTP.

Pros and Cons

Pros	Cons
Simple RPC model	Very verbose XML payloads
Cross-platform interoperability	Weak typing and contracts
Human-readable messages	Slow parsing compared to JSON/Protobuf
Uses standard HTTP transport	Large message sizes
Easy firewall traversal	Limited modern tooling
Historically important	Rarely used in new systems
Influenced later web-service designs	Mostly replaced by newer technologies

SOAP

As businesses started integrating systems across organizations, they needed more than simple remote procedure calls. Companies wanted:

Security
Reliability
Transactions
Formal Contracts
Interoperability

SOAP (Simple Object Access Protocol) was introduced in 1998 and became a W3C standard in the early 2000s. SOAP attempted to standardize enterprise communication across platforms and vendors.

SOAP thinks in contracts and messages

Core assumption: Distributed systems need formal agreements about communication.

A SOAP service is:

Contract (WSDL)
      +
Message Format
      +
Enterprise Standards

Example

SOAP Request

<soap:Envelope>
  <soap:Body>
    <GetUser>
      <Id>123</Id>
    </GetUser>
  </soap:Body>
</soap:Envelope>

SOAP Response

<soap:Envelope>
  <soap:Body>
    <GetUserResponse>
      <User>
        <Id>123</Id>
        <Name>Alice</Name>
      </User>
    </GetUserResponse>
  </soap:Body>
</soap:Envelope>

WS-* Standards

SOAP is commonly paired with a family of enterprise standards known as WS-* ("WS-star"), including:

WS-Security – message-level encryption, signing, and authentication
WS-ReliableMessaging – guaranteed, ordered message delivery even over unreliable networks
WS-AtomicTransaction – coordinating distributed transactions across multiple services

These standards are why SOAP remained the go-to choice for banking, insurance, and government systems that needed guarantees plain HTTP alone couldn't provide.

Pros and Cons

Pros	Cons
Strong formal contracts (WSDL)	Extremely verbose XML
Enterprise-grade security	High complexity
Reliable messaging support	Large payload sizes
Distributed transaction support	Slower than modern alternatives
Mature enterprise tooling	Difficult developer experience
Strong interoperability guarantees	Heavyweight for simple APIs
Common in regulated industries	Rarely chosen for new projects

JSON-RPC

JSON-RPC first appeared around 2005, emerging as a lightweight alternative to XML-RPC and SOAP.

Why was it created?

At the time, many RPC systems used XML-RPC and SOAP which were powerful but verbose and cumbersome.

Developers wanted:

Simpler payloads
Easier parsing
Better JavaScript compatibility
Less bandwidth usage

JSON-RPC replaced XML with JSON while keeping the RPC model. JSON-RPC provided a standard way to represent:

Method Name
Parameters
Result
Error

using JSON.

JSON-RPC thinks in remote function calls

Instead of:

POST /users
GET /users/123

JSON-RPC says:

createUser(...)
getUser(123)

The server exposes a set of methods. The client invokes them. Core assumption: APIs are collections of operations, not collections of resources.

Example

Request:

{
  "jsonrpc": "2.0",
  "method": "getUser",
  "params": {
    "id": 123
  },
  "id": 1
}

Response:

{
  "jsonrpc": "2.0",
  "result": {
    "id": 123,
    "name": "Alice"
  },
  "id": 1
}

The API feels like getUser(123) even though it is happening across the network.

Where JSON-RPC shows up today

JSON-RPC quietly powers several widely-used systems, including Ethereum and other blockchain node APIs, Bitcoin Core's RPC interface, and the Language Server Protocol (LSP) used by code editors like VS Code.

Pros and Cons

Pros	Cons
Very simple protocol	Not resource-oriented
Lightweight JSON payloads	Limited ecosystem
Transport agnostic	Weak standardization outside core spec
Natural fit for command-style APIs	Loses many HTTP benefits
Supports batch requests	Can become method-heavy over time
Easy to implement	Less tooling than gRPC or GraphQL
Works well over WebSockets	No built-in typing or schema system

gRPC

gRPC, open-sourced by Google in 2015, evolved from Stubby, Google's internal RPC framework. Google operated thousands of services communicating with each other across data centers. gRPC was designed to make service-to-service communication:

Faster
Strongly typed
Easier to maintain
Easier to generate clients for

gRPC thinks in fast, contract-driven function calls over HTTP/2

Local function:

getUser(123)

gRPC function:

userService.GetUser(123)

The client behaves as if it's calling a local function, but the execution happens on another machine.

Core assumption: "Modern service-to-service communication should feel like calling a local function, while running on HTTP/2 with strong typing, low latency, and native streaming." This is what separates gRPC from earlier RPC systems. It isn't just "remote functions," it's remote functions built for high-performance, cloud-native microservices.

Example

Service Definition

syntax = "proto3";

service UserService {
  rpc GetUser(GetUserRequest) returns (User);
}

message GetUserRequest {
  int32 id = 1;
}

message User {
  int32 id = 1;
  string name = 2;
}

Client call:

const user = await client.getUser({
  id: 123
});

Response:

{
  "id": 123,
  "name": "Alice"
}

Because gRPC uses Protocol Buffers with numbered fields, services can add new fields over time without breaking existing clients which is a key reason contract-first systems like gRPC and Thrift age well in large codebases.

Streaming in gRPC

Unlike JSON-RPC, XML-RPC, or SOAP, gRPC supports more than simple request/response calls. It defines four call patterns:

Unary RPC – one request, one response (a normal function call).
Server Streaming – one request, a stream of responses (e.g., live price updates).
Client Streaming – a stream of requests, one final response (e.g., uploading data in chunks).
Bidirectional Streaming – both sides stream independently at the same time (e.g., chat, live collaboration).

Example of a server-streaming method:

service UserService {
  rpc WatchUserUpdates(GetUserRequest) returns (stream User);
}

This built-in streaming is one of the main reasons teams pick gRPC over JSON-RPC or REST when they need continuous or real-time data flow, not just one-off calls.

Pros and Cons

Pros	Cons
Extremely fast and efficient	Poor native browser support
Strongly typed contracts	Binary protocol is harder to inspect
Automatic client/server code generation	Requires Protobuf tooling
Built-in streaming support	Higher learning curve
Excellent for microservices	More tightly coupled contracts
Multi-language support	Often unnecessary for simple CRUD APIs
HTTP/2 performance benefits	Public APIs usually favor REST

Apache Thrift

Apache Thrift was created at Facebook in 2007 and later donated to the Apache Software Foundation in 2008.

Facebook's infrastructure was growing rapidly and services were being written in different languages (PHP, Java, C++, Python). Each service needed to communicate with others. Without a common framework, teams had to manually create:

Serialization formats
Network protocols
Client SDKs
Server SDKs for every language combination.

Facebook wanted: "Define a service once, generate clients and servers everywhere." Thrift unified data serialization, RPC framework, and code generation into a single system.

Thrift thinks in shared contracts across languages

Core assumption: "A single Interface Definition Language (IDL) contract should let completely different languages, protocols, and transports interoperate without hand-written glue code for every combination."

Where Thrift distinguishes itself is flexibility: it doesn't lock a system into one protocol or one transport the way many RPC systems do.

Contract
   ↓
Generated Code (any language)
   ↓
Network Communication (any supported protocol/transport)

Instead of:

GET /users/123

Thrift says:

service UserService {
  User getUser(1:id)
}

Core assumption: "Cross-language communication in large, heterogeneous systems should be generated from a shared contract, with the freedom to choose the protocol and transport that fits each situation."

Example

Thrift IDL

struct User {
  1: i32 id
  2: string name
}

service UserService {
  User getUser(1:i32 id)
}

Generate code:

thrift --gen java user.thrift
thrift --gen go user.thrift
thrift --gen py user.thrift

Client:

user = client.getUser(123)

Response:

User(
  id=123,
  name="Alice"
)

Pros and Cons

Pros	Cons
Strong contract-first design	More complex than REST
Excellent multi-language support	Weak browser support
High-performance binary serialization	Smaller ecosystem than gRPC
Automatic code generation	Additional operational complexity
Flexible protocols and transports	Steeper learning curve
Mature RPC framework	Overkill for simple applications
Good fit for polyglot systems	More moving parts than REST

Connect

Connect was created by Buf Technologies and publicly introduced around 2021–2022.

Native gRPC works well between servers but struggles in browsers because browsers do not expose the full HTTP/2 capabilities that gRPC relies on. Developers had to build extra components for browser support.

Connect keeps the good parts of gRPC while making APIs work across browsers, mobile apps, backend services, and CLI tools, without requiring specialized infrastructure. Importantly, Connect isn't just "gRPC for browsers". Many teams adopt it purely for backend-to-backend communication, because it works over standard HTTP/1.1 and HTTP/2 without the operational overhead (proxies, specialized load balancers) that plain gRPC often requires.

Connect thinks in RPCs over standard HTTP

Core assumption: RPC contracts should work everywhere HTTP works, for browser and backend clients alike. Instead of choosing between:

REST for browsers
gRPC for services

Connect tries to provide:

One Contract
One API
Every Client

Example

Service Definition

Same .proto file as gRPC:

syntax = "proto3";

service UserService {
  rpc GetUser(GetUserRequest)
      returns (User);
}

Generate client/server code.

Client:

const response =
  await client.getUser({
    id: 123,
  });

console.log(response.name);

The difference is largely in transport and compatibility. Connect defines a protocol that works over ordinary HTTP. Unlike gRPC, it does not require specialized HTTP/2 behavior for basic usage.

Pros and Cons

Pros	Cons
Browser-friendly RPC	Smaller ecosystem
Reuses existing Protobuf contracts	Less industry adoption
Strong typing and code generation	Primarily useful for gRPC-style architectures
Works with standard HTTP infrastructure	Fewer learning resources
Supports Connect, gRPC, and gRPC-Web	Additional technology choice
Easier deployment than gRPC-Web stacks	Not as universally recognized as REST
Good full-stack developer experience	Can be overkill for simple APIs

tRPC

Modern TypeScript applications often looked like this:

Frontend
    |
 REST/GraphQL
    |
Backend

Even though both sides were written in TypeScript, developers still had to:

Define API routes
Create schemas
Generate types
Synchronize contracts This often felt redundant. Example:

type User = {
  id: number;
  name: string;
}

might need to be defined multiple times across frontend and backend. tRPC was created by Alex Johansson around 2021. It uses TypeScript itself as the contract.

tRPC thinks in TypeScript functions

Core assumption: The frontend and backend belong to the same codebase and can share types directly. tRPC uses TypeScript types as the source of truth.

Example

Server

const appRouter = router({
  getUser: publicProcedure
    .input(z.number())
    .query(({ input }) => {
      return {
        id: input,
        name: "Alice",
      };
    }),
});

Client

const user =
  await trpc.getUser.query(123);

console.log(user.name);

TypeScript automatically knows user.id and user.name without code generation.

Pros and Cons

Pros	Cons
End-to-end type safety	TypeScript-only ecosystem
No code generation required	Weak cross-language support
Excellent developer experience	Tight frontend/backend coupling
Fast development speed	Not ideal for public APIs
Great autocomplete and inference	Smaller ecosystem
Perfect for monorepos	Less suitable for large microservice environments
Minimal boilerplate	Harder to integrate with non-TypeScript systems

Key Takeaways

JSON-RPC – Choose it for lightweight, transport-agnostic method calls, especially when you already have a JSON-friendly client and don't need strong typing or contracts.
XML-RPC – Only relevant when integrating with legacy systems that already speak it. Avoid for new projects.
SOAP – Choose it when you need formal contracts (WSDL) and enterprise-grade guarantees like security, reliable messaging, or distributed transactions (WS-*) like banking, insurance, and government systems.
Apache Thrift – Choose it for large, polyglot backend systems, especially if you need protocol/transport flexibility or already have Thrift infrastructure in place.
gRPC – Choose it for modern, performance-sensitive microservices that benefit from HTTP/2, strong typing, and native streaming. Avoid for public browser-facing APIs without a proxy layer.
Connect – Choose it when you want gRPC-style contracts with simpler HTTP compatibility across browsers, backends, and mobile clients, without the operational overhead of plain gRPC.
tRPC – Choose it for full-stack TypeScript applications, especially monorepos, where end-to-end type safety and developer speed matter more than cross-language support.

Request/Response APIs: REST vs GraphQL vs OData vs Falcor

Shiv Rai (S_RAI) — Mon, 14 Sep 2026 14:08:50 +0000

What are Request/Response APIs?

Request/Response APIs are the most common way for applications to communicate across process, network, or service boundaries. A client sends a request for information or an action, and a server returns a response containing the result.

This model is simple, predictable, and well-suited to workloads where a consumer knows when it needs data and expects an immediate answer. Web applications, mobile apps, dashboards, internal tools, and third-party integrations all commonly rely on request/response communication.

Common use cases include:

CRUD applications
Web and mobile backends
Public developer platforms
Internal business systems
Reporting and analytics APIs
Data access layers for enterprise applications

This article includes: REST, GraphQL, Falcor, OData.

How to choose?

Simplicity, interoperability, and widespread ecosystem support -> REST
Clients need flexible access to complex data -> GraphQL
Efficient access to large, connected data graphs -> Falcor
Standardization, querying capabilities, and enterprise integration are primary concerns -> OData

flowchart TD

A[Need a Request/Response API] --> B{Need a standardized query language<br/>for business data and integrations?}

B -->|Yes| O[OData]
B -->|No| C{Do clients need precise control<br/>over returned fields and shapes?}

C -->|No| R[REST]
C -->|Yes| D{Are you building around a<br/>single logical data graph with<br/>heavy client-side navigation?}

D -->|Yes| F[Falcor]
D -->|No| G[GraphQL]

Comparison

Aspect	REST	GraphQL	Falcor	OData
Mental Model	Resources exposed through endpoints	Query a graph of data	Navigate a virtual JSON graph	Resources enhanced by a standardized query language
Data Fetching Flexibility	Low to Medium	High	High	Medium to High
Client Control	Limited by endpoints	High	High	Moderate
Complexity	Low	Medium to High	Medium to High	Medium
Caching	Excellent and well understood	More challenging	Good with graph-aware tooling	Good
Tooling	Extremely mature	Mature and growing	Smaller ecosystem	Strong enterprise ecosystem
Learning Curve	Low	Medium	Medium to High	Medium
Typical Use Cases	Public APIs, web services, CRUD systems	Frontend-heavy applications, aggregating multiple data sources	Rich data-driven applications with complex relationships	Enterprise systems, analytics, business applications
Strengths	Simplicity, scalability, broad adoption	Flexible queries, reduced over/under-fetching	Efficient graph traversal and data reuse	Standardized querying and interoperability
Weaknesses	Multiple requests for related data, endpoint proliferation	Increased operational and schema complexity	Smaller adoption and ecosystem	Can feel verbose and enterprise-oriented

REST

REST stands for REpresentational State Transfer. It was introduced by Roy Fielding, one of the creators of HTTP. He published his PhD dissertation in 2000 explaining why the World Wide Web scaled so well. According to him, the web succeeded because it followed certain architectural constraints. This architectural style became known as REST.

REST offered a simpler model than the RPC-style communication common between systems at the time:

Everything important is a resource
Resources have URLs
Standard HTTP methods operate on those resources
Clients and servers remain loosely coupled

REST isn't a protocol. It's an architectural style.

Note: Strict REST, as originally defined, includes additional constraints such as HATEOAS (Hypermedia as the Engine of Application State). In practice, many APIs commonly referred to as "REST APIs" do not fully implement every constraint from the original definition — what most teams build and call "REST" is closer to resource-oriented HTTP APIs.

REST thinks in resources

A resource is simply a thing your system exposes:

Users
Books
Orders
Authors

Instead of:

createUser()
getUser()
deleteUser()

REST is:

POST   /users
GET    /users/123
DELETE /users/123

Examples

Create a user:

Request

POST /users

Content-Type: application/json

{
  "name": "Alice"
}

Response

201 Created

{
  "id": 123,
  "name": "Alice"
}

Fetch a user:

Request

GET /users/123

Response

{
  "id": 123,
  "name": "Alice"
}

A representation of a resource is transferred during calls, not the resource itself.

Pros and Cons

Pros	Cons
Simple and easy to understand using standard HTTP methods (GET, POST, PUT, DELETE).	Can lead to overfetching (receiving more data than needed).
Universally supported across browsers, servers, mobile apps, proxies, and CDNs.	Can lead to underfetching (multiple requests needed to gather related data).
Leverages existing HTTP infrastructure and tooling.	No built-in strong typing or schema enforcement.
Cache-friendly through HTTP caching headers and CDN support.	API contracts are often documented separately and validated at runtime.
Resource-oriented design maps naturally to CRUD operations.	Modeling complex business actions can become awkward.
Stateless architecture improves scalability and reliability.	Real-time communication is not natively supported.
Human-readable requests and responses simplify debugging.	Versioning strategies can become complicated over time.
Loose coupling between clients and servers allows independent evolution.	Deeply nested or relational data often requires multiple round trips.
Easy to test using browsers, curl, Postman, or similar tools.	Performance may suffer in chatty client-server interactions.
Large ecosystem, mature best practices, and widespread adoption.	Different teams often interpret REST principles differently, leading to inconsistent APIs.

GraphQL

Facebook developed GraphQL internally in 2012 to tackle the difficulty of working with REST APIs as their mobile apps grew. Facebook open-sourced GraphQL in 2015.

Mobile clients often faced problems such as:

Slow networks
Limited bandwidth
Multiple API requests for a single screen
Different data requirements across platforms

REST forces the server to decide what data is returned. GraphQL lets the client decide. Instead of many endpoints, GraphQL provides a single endpoint, /graphql, through which all actions take place.

GraphQL thinks in queries

The client describes the exact structure of the response. The client requests fields, and the server assembles the response.

Example

A user has:

id
name
email
avatar

Client only needs name.

Query

query {
  user(id: 123) {
    name
  }
}

Response

{
  "data": {
    "user": {
      "name": "Alice"
    }
  }
}

Client needs name + email:

Query

query {
  user(id: 123) {
    name
    email
  }
}

Response

{
  "data": {
    "user": {
      "name": "Alice",
      "email": "alice@example.com"
    }
  }
}

Pros and Cons

Pros	Cons
Eliminates overfetching	More complex backend architecture
Reduces underfetching and multiple requests	Caching is harder than REST
Strong schema and typing	Can suffer from N+1 query issues
Excellent tooling and developer experience	Query complexity must be controlled
Flexible for multiple client types	Overkill for simple CRUD systems
Self-documenting schema	Additional learning curve
Easier API evolution	Monitoring and performance tuning are harder

Falcor

A note on relevance: Falcor is included here primarily for historical and conceptual understanding — it introduced ideas (like a unified virtual data graph) that are useful for building intuition. In practice, GraphQL became the dominant solution for flexible, client-driven data fetching.

Falcor was created by Netflix and open-sourced in 2015. Netflix applications needed data from many backend services:

Recommendations
User Profiles
Ratings
Viewing History
Search
Metadata

Building a screen often required multiple API calls. This created:

Overfetching
Underfetching
High latency
Complex frontend code

Falcor introduced a concept called the JSON Graph. Instead of exposing APIs as resources or functions, the server exposes a graph of interconnected data. The client requests paths through that graph.

Falcor thinks in graphs

Imagine application data as one giant object:

{
  users: {},
  movies: {},
  ratings: {},
  recommendations: {}
}

Clients don't call endpoints. They ask for paths inside the graph.

Example:

users[123].name
movies[42].rating

Core assumption: Application data is a graph, and clients should navigate that graph directly.

Example

Suppose the graph contains:

{
  users: {
    123: {
      name: "Alice"
    }
  }
}

Client requests:

model.get([
  "users",
  123,
  "name"
]);

Response:

{
  "jsonGraph": {
    "users": {
      "123": {
        "name": "Alice"
      }
    }
  }
}

Pros and Cons

Pros	Cons
Flexible graph-based data access	Steeper learning curve
Built-in client caching	Small ecosystem
Reduces API round trips	Limited adoption
Handles relationships naturally	GraphQL largely replaced it
Efficient for connected data	Fewer tools and community resources
Client-driven fetching	Complex mental model
Good Netflix-scale use cases	Rarely chosen for new projects

OData

As organizations exposed more data over HTTP, developers repeatedly faced the same problems:

GET /users
GET /products
GET /orders

Every API invented its own way to support:

Filtering
Sorting
Pagination
Searching
Expanding related data

Example:

GET /users?status=active

might work in one API, while another used:

GET /users?filter=status:active

There was no standard way to query data over HTTP. OData (Open Data Protocol) was introduced by Microsoft in 2007 and later standardized through OASIS. OData attempted to create SQL-like querying for HTTP APIs. Instead of every API inventing its own query language, clients could use a standard set of query operations.

Clarification — REST vs. OData: Traditional REST APIs usually expose fixed resource representations, meaning the server largely decides what shape a response takes. OData extends REST-style APIs with a standardized querying layer on top, giving clients more control over returned data (filtering, selecting fields, expanding relations) without changing the underlying request/response model.

OData thinks in queryable resources

Core assumption: APIs expose resources the same way REST does, but those resources are enhanced with a standardized query language — so clients can filter, sort, select fields, and expand relations without the server needing to build a custom endpoint for every variation.

Instead of:

GET /active-users
GET /users-by-country
GET /top-customers

you expose:

GET /users

and allow the client to specify the query. The server provides the data. The client decides how to filter it.

Example

Let's say:

GET /users

returns:

[
  {
    "id": 1,
    "name": "Alice",
    "country": "US"
  },
  {
    "id": 2,
    "name": "Bob",
    "country": "IN"
  }
]

Client requests:

GET /users?$filter=country eq 'US'

Response:

[
  {
    "id": 1,
    "name": "Alice",
    "country": "US"
  }
]

Pros and Cons

Pros	Cons
Powerful built-in querying	Query language complexity
Standardized filtering and sorting	Can expose expensive operations
Reduces endpoint proliferation	Tight coupling to data models
Metadata discovery support	Less flexible than GraphQL
Great for business datasets	Smaller ecosystem
Strong enterprise tooling	Rarely used for public APIs
HTTP and REST friendly	Requires careful security controls

Key Takeaways

Choose REST when you want simplicity, broad tooling support, strong HTTP caching, and your data access patterns are mostly straightforward CRUD.
Choose GraphQL when clients have varied or evolving data needs, over/underfetching is a real problem, and you can support the added backend complexity.
Choose OData when you need standardized, SQL-like querying (filtering, sorting, expanding relations) over business data, especially in enterprise or Microsoft-adjacent ecosystems.
Choose Falcor rarely, if ever, for new projects — it's mainly useful for understanding the "unified data graph" mental model.

Stellar programs for Developers

Shiv Rai (S_RAI) — Mon, 25 May 2026 09:48:52 +0000

If you have been looking for support to build the next big thing on Stellar, this is the article you must read!

Stellar is a decentralized, public blockchain that is not only faster and cheaper but also more energy-efficient than most public blockchains, with an average cost of $0.0006667 per transaction, a global reach of 180+ countries, $167M TVL, and 5.3s settlement time.

To help builders and developers, Stellar Development Foundation (SDF) has introduced various programs that you can apply to:

Instawards

Offered through local Stellar Ambassador Chapters, Instawards is a small funding opportunity for early-stage builders. It prioritizes builders with strong collaboration, commitment, and execution readiness.
Instawards are the first step toward bigger opportunities in the stellar ecosystem.

Build Award

Consisting of 3 tracks - Open, Integration, and RFP - the Build Award provides up to $150k in XLM for teams building on Stellar.

Open Track: Teams with a plan to build something new on Stellar.
Integration Track: Teams that are either incorporating an existing Stellar tool or dApp into their project OR already have existing significant traction on any chain or off-chain
RFP Track: Developers and teams building tools or services, who are prepared to build and ship.

Review Process:

Prescreen: Complete application and eligibility criteria are met
Panel Review: Projects are evaluated based on ecosystem value, technical feasibility, roadmap clarity, and team capability.
Revision Window: Teams are given time to make minor revisions to their submission. This happens before the community vote for Open Track; For the RFP and Integration Tracks, reviewers may request changes.
Community Vote (For Open Track): SCF community members vote on projects. This drives the final decision.

Audit Bank

SDF covers audits for SCF-awarded projects

Public Goods Award

Public Goods Award supports public goods maintained by the community - key infrastructure, tools for the ecosystem, data, governance, and more of the Stellar ecosystem.
It is managed through Soroban Governor.
Applications for the Public Goods Award are invitation-only. If you meet the eligibility requirements, make sure to check the #scf-governance discord channel for next review period.

Liquidity Award

The Liquidity Award provides funding for the initial liquidity needs of financial protocols that have completed security audits and are live on Stellar mainnet. Liquidity Award can provide a Base Liquidity Award of $50K with a Supplemental Liquidity Award of an additional $50k.

Growth Hack

It is an 8-week, competition-style GTM/PMF program where 10-15 teams compete with $20k in initial funding to run a 4-week acquisition + 4-week retention campaign. Top performers receive a share of $200k. The program helps teams find PMF and serves as a bridge between development funding and further growth.

Each program has its own requirements and rules. The funds are provided in XLM, which is the native currency of Stellar.

You can choose which program to apply for based on your stage. If you are just starting out, apply for Instawards. Later, you can apply for SCF.

Stellar focuses heavily on DeFi products like remittances, asset tokenization, wallets, and payments. So, if you are building something related, you should definitely apply to these programs.

For more information, read the SCF handbook here: https://stellar.gitbook.io/scf-handbook
For information on SCF projects, upcoming rounds, and submission forms for eligible projects: communityfund.stellar.org

Happy developing!

Pegasus: Your Document's Language Passport, Powered by Lingo.Dev

Shiv Rai (S_RAI) — Mon, 16 Mar 2026 12:56:40 +0000

If I asked you "How many languages are there in the world?", what will you say? "500"? "1000"? "5000"? Still not there yet. There are 7000+ languages in the world. Yet, most of us can name around 10-20. English, being the most common, since it is used globally. However, there are people who do not speak English and there are places, where English is not the preferred language for documents. And that is totally fine. Its a wide world. People are free to speak the language they choose.

However, this creates a gap in communication. One or sometimes more than one party, has to use a translator in order to communicate. People often use tools like Google Translate in such situations. But, what about documents?
Imagine you sent a pdf or docx to someone in English. That person requested a French version. What will you do ? you copy paste your content into a translator, copy paste the response back into your docx, save it, and share it back to the person. This was a single request. For 1 language. There are more than 20 languages spoken by more than half of the world’s population. Let's assume that just half of them requested a version in their language, which means 10. Are you going to repeat the process 10 times ? That's not sensible, right ? Let's assume you are a hard-worker and did it 10 times. Hurray! But wait... you just noticed there is a small change that needs to be done. You made the change in the original document. And then you realize, you have to do the translations again for the 10 requests.

At this point you are putting in more effort for preparing document for sharing than doing something productive. But what's the solution to this problem? What if you could just make a single file, with all the translations, rendered according to user's preference? Imagine how easy it would be. Create your file, add translations, share a single file, and you are done. Sounds simple, right? Worry not, it is simple with Pegasus.

What is Pegasus?

Imagine an app through which you can create a single file with all the required language translations you want, share it with your team, and they can view it in their preferred language, without even needing internet. How amazing would that be? Pegasus is that app!

How Pegasus works?

You choose your document (txt, docx, pdf), select the languages you want the translations of, add lingo dev API key, choose the output folder. And that's it. You get a .pgs file which you can share with whoever you want and they can open Pegasus, open this .pgs file, and view it in their language (without API key).

What if someone got the file but their language translation wasn't available? They can add the translations of their language within the .pgs file following the same steps to create the file. The best part, the current translations available aren't removed. New translations are added along with existing translations.

The app only requires internet connection when you need translations. Otherwise, it can be used to view files and their translations without the need of internet. Reason, the single file contains all the data required.

How it's made?

It's made using Electron.js + Vite + react in typescript, along with tailwindCSS and powered by Lingo.Dev
Lingo Dev's API is used for document content translation while Lingo Dev's Compiler is used to translate the UI content of Pegasus app.

GitHub Repo: https://github.com/ShivRaiGithub/pegasus

The Problem Pegasus solves

BILLIONS of digital documents require translations EVERYDAY. Business contracts, government papers, product manuals, etc are examples of some documents whose digital versions need various translations for multiple languages. Large companies usually maintain more than 5 language versions of same document. This piles up in costs, leading to thousands of dollars just to maintain few documents. These costs can be reduced multi-fold. What do you think is the market size of multilingual document translation ? More than $60B. But now,
Instead of:
policy_en.pdf
policy_fr.pdf
policy_es.pdf
policy_de.pdf
policy_hi.pdf
There can be a single:
policy.pgs

Costs reduced. Inefficiencies decreased. All through a single and simple app.

More about Pegasus and my experience
1) At first, Pegasus worked only for txt files. I later added features for it to work with docx files as well as pdf files. There were so many issues that arose while working with docx and pdf files. The reason for that is, unlike txt files, docx and pdf files have a structure and a layout. I tried few ways to ensure that the translations follow the actual layout as much as possible. Eventually I reached a satisfiable outcome for pdfs and docs too.
2) I wanted to make PPTs work with Pegasus too, but due to the time constraint, I wasn't able to. Working with PPTs requires better ways to extract text and place them back while making sure the bg is not affected. Working with PPTs and other file formats is something that can be done in the future.
3) Working with Hindi. Hindi characters weren't visible. I had to download another npm package that can be used to display devnagari script.
4) Due to time constraints, I wasn't able to make dedicated download files (like exe for windows). But the repo is self sufficient to build and run the application. All the steps are in the readme.
5) I wanted to try something new for demo video, so I created the demo video using AI generated clips + screen recordings.
6) I have done most of the app building and testing on WSL. I did test the app on windows, but not on iOS.

Study Table: Task-focused environment

Shiv Rai (S_RAI) — Sun, 01 Mar 2026 17:52:41 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

I built StudyTable for students, developers, and builders who regularly participate in focused study or work sessions — especially people who learn independently or work on side projects.

Many communities today (open-source contributors, students preparing for exams, hackathon participants, self-learners, etc.) struggle not with starting work, but with maintaining structured, distraction-free focus.

StudyTable is designed for anyone who values deep work and intentional learning.

What I Built

StudyTable is a frontend-only web app that helps users run structured focus sessions.

Instead of being just another timer, StudyTable treats work as a guided session:

Users create sessions with tasks with custom durations.
Each task runs as a timed focus block.
After completion, users intentionally transition into breaks or extend work time.
Sessions generate time reports showing how time was actually spent on the work.

The experience is designed to feel simple and calm — reducing decision fatigue while working.

Core idea:

Most productivity apps track time.
StudyTable helps users utilize time intentionally.

Demo

Website: https://studytable-psi.vercel.app/
Youtube: https://youtu.be/dbjE8EMlAHI

Code

Github Repo: https://github.com/ShivRaiGithub/studytable

How I Built It

StudyTable is intentionally built without a backend, keeping the architecture lightweight and accessible.

Technologies Used

Next.js (App Router) — application structure and routing
React — UI and state management
TypeScript — safer and maintainable code
Tailwind CSS — styling and layout

Solo Member: Shiv Rai (S_RAI)
Dev.to: https://dev.to/rai_shiv

Ouija Terminal - GitHub Copilot CLI Challenge

Shiv Rai (S_RAI) — Sun, 15 Feb 2026 12:42:36 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

A fun little project built fully using Github Copilot CLI only.
"Ouija Terminal", a terminal which seems normal at first, but all interaction ultimately lead to the paranormal.
There are various interactions you can do with the terminal through commands like saving name, changing theme of terminal, get current status, get time and date, etc. But each command changes it's behavior as you interact more.
Try it for yourself: https://ouija-terminal.vercel.app/

Demo

Demo: https://youtu.be/FMNh3W5Ccuw
Website: https://ouija-terminal.vercel.app/

Vibe coding video: https://youtu.be/LeKYyDMaXN0

Images

My Experience with GitHub Copilot CLI

This was actually the first time I used an AI from CLI. I haven't even used Claude Code before. I usually use Copilot Agent.
Using CLI felt a little slower as compared to Copilot Agent on the file generation and editing part. But at the same time I never had to click "Continue" anywhere which usually appears when working with Agent.
Also, there were different options available when executing a command which allowed you to set the permission to execute the commands for the entire CLI session which is a nice touch.

Team Members

Solo member: Shiv Rai (S_RAI) @rai_shiv
https://dev.to/rai_shiv