DEV Community: Shiv Rai (S_RAI)

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