Frontend System Design/The RADIO Framework
Lesson 7 of 17 · Episode 7

RADIO — Interface Definition

Defining clean interfaces between client and server, and between components.

RADIOInterfacesContracts
Watch on YouTube ↗

Components and the server depend on each other — but how do they talk? The I step defines the contracts: the interfaces (APIs) that sit between any two parts of the system and spell out exactly what flows across.

The map

Where we are in RADIO

We have components and data. Now we define how they communicate. Tap I:

I · Interface Definition
Define the contracts: between components (props / events) and between client and server (the API).
The I in RADIO

What an interface is

Say “API” and everyone pictures the frontend calling the backend. That's one case — but an interface is more general: it's the agreed-upon layer between any two parts of a system that depend on each other. Define that layer well and the two sides can evolve independently.

Three kinds

The layers an API connects

The same idea shows up at three boundaries. In frontend system design we focus on the first two:

The pattern

Anatomy of an API

Every interface — at any layer — has the same three parts. Step through them on our feed endpoint:

GET /feed?size=10&cursor=p_42→ { posts: Post[], nextCursor }

What the endpoint does — the name and its job: fetch a page of feed posts.

Functionality · Parameters · Response
Functionality is what it does. Parameters are the input you send. Response is the output you get back. Name those three and you've defined the interface.
Layer one

Client ↔ server

For the feed, the contract is a paginated fetch. The functionality is getFeed; the parameters are a page size and a cursor marking the last post you saw; the response is the next batch of posts plus a nextCursor. Send no cursor and the server can't know where to continue — it might hand back the same posts every time.

Watch the contract in motion — each request carries the cursor, each response brings the next page and a fresh one. Flip it to Autoplay to let it run, or drive it yourself in Manual:

InteractivegetFeed — request & response
🖥
Client
🗄
Server
No posts yet — watch the request fly…
0 / 12 posts · cursor ∅
Note
How that call is actually made — REST, GraphQL, WebSockets, polling — is a deeper topic the course covers later. Here we only define the contract.
Layer two

Client ↔ client

Inside the UI, the same anatomy maps onto props and events. A Post passes its comments down to CommentsList (parameters), and the list sends events up when something changes (response). Tap the boxes:

Props flow down; events flow up. Tap a box.
Try it

Classify the API parts

Drop each item into the part of the API it represents:

0/6 sorted
getFeed — fetch a page of posts
cursor = p_42
{ posts: Post[], nextCursor }
size = 10
Passing comments[] down to a child component
Child emits onNewComment back to its parent
Practice

Check your understanding

Q1Multiple choice
What are the three parts of any interface?
Q2Sort each scenario
Which layer is this interface?
GET /feed?size=10 returning JSON
A parent passing props to a child
A child emitting an onChange event
Fetching the user profile from an API
Q3Multiple choice
Why does the feed request send a cursor parameter?
Try it yourself

Design challenge

Define the interfaces for a “like” feature:

  1. Write the client↔server API: functionality, parameters, response.
  2. Write the client↔client contract between the post and its like button (props down, events up).
  3. Note what the response should include so the UI can update optimistically.
Key takeaways
  • →An interface is the contract between any two parts that depend on each other — not just frontend↔backend.
  • →It appears at three layers: client↔server, client↔client, and server↔server (mostly backend).
  • →Every interface has three parts: functionality, parameters, and response.
  • →In the UI, parameters are props passed down and the response is events emitted up.
← Previous
6. RADIO — Core Entities
Next →
8. RADIO — Optimizations & Deep Dive