Edit

RPC vs GraphQL/REST

See Overview > RPC if you don't know what RPC is.

TL;DR

A GraphQL/RESTful API is only needed if:

• You want to give third parties access to your database.
• You are a very large company with very complex databases.

Otherwise, you can use RPC for a significant increase in development speed.

Contrary to common belief, you can use RPC while having a decoupled frontend-backend development.

Third Parties

The most eminent use case for REST and GraphQL is giving third parties access to your database.

For example, Facebook's API is used by ~200k third parties. It makes sense that Facebook uses (and invented) GraphQL, as GraphQL enables any third-party developer to extensively access Facebook's database, thus enabling all kinds of applications to be built on top of Facebook's data.

GraphQL/RESTful APIs are generic: they are meant to serve frontends without knowing the frontends' data query/mutation requirements.

In contrast, as discussed in Guides > Event-based telefunctions, telefunctions (RPC endpoints) are tailored to your frontend's UI components. This means that your telefunctions are only useful for your frontend and third parties cannot use them to build third-party frontends.

⚗️

Research Area. It's theoretically possible to also use RPC to give third parties access to your database, but this hasn't been done so far. Reach out to the Telefunc maintainers if you're interested in exploring this topic.

Decoupled frontend-backend

A common misbelief is that GraphQL/REST is required to decouple the frontend development from the backend development.

It is true that GraphQL/REST induces a decoupling: as seen in the last section, a GraphQL/RESTful API is generic which means that the frontend team can develop independently of the backend team.

But you can as well achieve a decoupled frontend-backend development with RPC by using what we call a Telefunc Server.

Telefunc Server

You usually install Telefunc as a Node.js server middleware. This induces a tight coupling between your frontend and your Node.js server.

For example, let's consider this telefunction:

// TodoList.telefunc.js
// Environment: server
 
import { getContext } from 'telefunc'
 
// This telefunction is tightly coupled to the frontend: it returns exactly and
// only what the <TodoList /> component needs.
 
export async function getInitialData() {
  const { user } = getContext()
  if (!user) {
    return { isNotLoggedIn: true }
  }
  const todoItems = await database.query(
    'SELECT id, text FROM todos WHERE authorId = :authorId',
    { authorId: user.id }
  )
  const { firstName } = user
  return {
    user: { firstName },
    todoItems
  }
}

If you change your <TodoList> component to also show the to-do items' creation date, then you need to change the SQL query of your getInitialData() telefunction from SELECT id, text to SELECT id, text, created_at.

This means that the frontend developers need to make changes to the Node.js server and re-deploy it.

If you are a small team of full-stack developers, then such frontend-backend coupling is not a problem. But, as you grow, you may want to have a frontend team that develops independently of a backend team.

You can achieve a decoupling by using a Telefunc Server: a dedicated Node.js server with the sole purpose of serving telefunctions.

The frontend and the Telefunc server are developed & deployed hand-in-hand, while the backend (another Node.js server, Ruby on Rails, ...) can be developed & deployed independently.

Multiple Frontends

Another common misbelief is that GraphQL/REST is required to develop several frontends.

You can develop multiple frontends as well with RPC by having one Telefunc Server per frontend.

The rise of edge computing, such as Cloudflare Workers, makes Telefunc Servers very performant, cheap (with generous free tiers), and easy to set up.

Complex Databases

A less common but nonetheless widespread use case is the usage of GraphQL in very large companies.

The databases of large companies can become too complex for the frontend team.

Instead of the frontend team directly accessing the databases with Telefunc & SQL/ORM queries, you create a GraphQL API that is simpler to use. You essentially use GraphQL to abstract away the complexities of your databases.

For performance-critical apps deployed at large scale, such as Twitter or Facebook, it is common to use several database technologies at once. You can then even use GraphQL to simplify the life of not only the frontend developers but also the backend developers: the backend developers then also use the GraphQL API instead of directly accessing your databases.

A GraphQL API enables an independent database development which can become a crucial strategy at scale.

GraphQL is the state-of-the-art for this use case; a RESTful API would be too limiting.

Which one to choose?

RPC enables your frontend to directly use ORM/SQL queries which is not only a fundamentally simpler approach, but also more powerful (you can achieve more with ORM/SQL queries than with GraphQL/RESTful queries). So you should use RPC whenever you can for a significant increase in development speed.

Also, RPC is a natural fit for the increasingly ubiquitous practice of full-stack development with frameworks such as Next.js.

On the other hand, you need GraphQL/REST if you need to give third parties access to your database.

Also, using a GraphQL API can be a crucial strategy for very large companies with very complex databases.

In general, a sensible default is to start with RPC and use GraphQL/REST only when the need arises.