REST vs RPC Structure

[HasithDeAlwis]

We need to decide the architecture of our API now, REST vs RPC. For our CMS, we are using GraphQL, so this is not referring to that.

[HasithDeAlwis]

ARGUMENT FOR REST

I just like the structure of REST and how it's stateless, I also like the "CRUD" system of REST a lot, and I think it applies well to us.

REST is a lot more about "nouns" and the actions we can perform on it. I think the term is resource-centric architecture and our system is resource centric (we have users, teams). The action's we're doing are fundamentally basic (ex. join a team, leave a team, register for the hackathon), if we used an RPC model for this, it wouldn't be taking advantage of the inherent action based design philosophy of RPC. More often than not we're going to be an action specific to a model, which is what REST excels at. Also just at a pure organisational level, our REST endpoints will look exactly like our file structure.

user
--> router
--> services
--> midelware
etc.

^all our routes are organized the same way (ex. POST /user, GET /user?userID=asdf)

Also, we'd want to expose these resources down the line for other clients to access (ie. we want to have a blog on our website that users can comment on, we want to take this resource straight from our existing API/databse for our portal). At a fundamental level, REST does this better than RPC because RPC architecture is about actions, not resources.

[HasithDeAlwis]

We also have to account for the fact that RPC structures very tightly couples our client with our server, is this something we want? It'll complicate how we make our internal tools

[MFarabi619]

Isn't REST just RPC over HTTP?

Also, how difficult is it to migrate?

[HasithDeAlwis]

REST is not necessarily just RPC over HTTP, it's a fundamentally different way of writing your API. Its a different architectural pattern that focuses on resources. REST only uses HTTP, but RPC can use different protocols.

The migrations would be quite difficult, with RPC you load the functions directly into the client, there is no isolation. The API and the client live alongside one another, so migrating that, would not be an easy task.

Here's a good example of how REST would differentiate from RPC syntax wise:

REST EXAMPLE

// server.js
const express = require('express');
const bodyParser = require('body-parser');
const cors = require('cors');

const app = express();
const PORT = process.env.PORT || 3000;

// Middleware
app.use(cors());
app.use(bodyParser.json());

let users = []; // In-memory user storage
let nextId = 1; // Simple ID counter

// Create User
app.post('/users', (req, res) => {
  const { name, email } = req.body;
  const newUser = { id: nextId++, name, email };
  users.push(newUser);
  res.status(201).json(newUser);
});

// Get User by ID
app.get('/users/:id', (req, res) => {
  const user = users.find(u => u.id === parseInt(req.params.id));
  if (user) {
    res.json(user);
  } else {
    res.status(404).send('User not found');
  }
});

// Update User
app.put('/users/:id', (req, res) => {
  const userIndex = users.findIndex(u => u.id === parseInt(req.params.id));
  if (userIndex !== -1) {
    const { name, email } = req.body;
    users[userIndex] = { id: users[userIndex].id, name, email };
    res.json(users[userIndex]);
  } else {
    res.status(404).send('User not found');
  }
});

// Delete User
app.delete('/users/:id', (req, res) => {
  const userIndex = users.findIndex(u => u.id === parseInt(req.params.id));
  if (userIndex !== -1) {
    users.splice(userIndex, 1);
    res.json({ success: true });
  } else {
    res.status(404).send('User not found');
  }
});

// Start the server
app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

RPC EXAMPLE

// trpcRouter.js
import { initTRPC } from '@trpc/server';
import { z } from 'zod';

const t = initTRPC.create();

let users = [];
let nextId = 1;

export const userRouter = t.router({
  createUser: t.procedure
    .input(z.object({ name: z.string(), email: z.string().email() }))
    .mutation(({ input }) => {
      const newUser = { id: nextId++, ...input };
      users.push(newUser);
      return newUser;
    }),

  getUser: t.procedure
    .input(z.number())
    .query(({ input }) => {
      const user = users.find(u => u.id === input);
      if (!user) throw new Error('User not found');
      return user;
    }),

  updateUser: t.procedure
    .input(z.object({ id: z.number(), name: z.string(), email: z.string().email() }))
    .mutation(({ input }) => {
      const userIndex = users.findIndex(u => u.id === input.id);
      if (userIndex === -1) throw new Error('User not found');
      users[userIndex] = { ...users[userIndex], ...input };
      return users[userIndex];
    }),

  deleteUser: t.procedure
    .input(z.number())
    .mutation(({ input }) => {
      const userIndex = users.findIndex(u => u.id === input);
      if (userIndex === -1) throw new Error('User not found');
      users.splice(userIndex, 1);
      return { success: true };
    }),
});

ALSO, we have very complex state management in our app, it will guarantee to lead to problems if we use RPC since it's stateless. We will get some nasty bugs with this :/