Cross-Platform Social App Architecture Responsibilities

Welcome. This course will take you from the basic workflow of programming to a working cross-platform social app that can run in a browser and on Android. We will build foundations first: before writing code, you need a reliable mental model of where each part of an app runs and which part is responsible for what.

A social app may appear to be one product, but it is a collaboration between several systems. In this lesson, you will map the four core responsibilities:

• the client that people use;
• the backend that enforces the app’s rules;
• the database that stores structured social data;
• media storage that holds large image and video files.

By the end, you should be able to take a feature such as “publish a photo post” and explain how information moves through the architecture without confusing a screen, an API, a database record, and a media file.

---

The app is not just the screen

When someone opens your future social app, they see profiles, a feed, post buttons, group pages, messages, photos, and videos. That visible experience is important, but it is only the client side of the system.

A client is the software running on the user’s device:

• a web app running in Chrome, Edge, or another browser on a laptop;
• the app running on an Android phone;
• eventually, an iOS app running on an iPhone.

For this course, Expo and React Native will let us build much of that client interface from one codebase and run it on both web and Android. The client is responsible for presenting information and responding immediately to user interaction: tapping “Follow,” typing a message, opening a profile, or choosing an image.

The client should not be the final authority on important rules. A person can inspect or alter code that runs on their own device. So even if the client hides a “Delete post” button, that alone cannot guarantee that someone cannot try to delete another user’s post. That decision must be checked somewhere the user cannot control: the backend and its security policies.

The diagram shows a traditional web application. It is useful because it separates the browser, web application, database, and static files. A modern mobile or single-page app changes some implementation details, but the fundamental separation of responsibilities remains.

The term frontend is often used interchangeably with client. In this course, “client” emphasizes where the software runs: on the person’s phone or in their browser. “Frontend” emphasizes what it does: it creates the interface.

---

Requests, responses, and APIs

The client and backend communicate across the internet. The usual web language for this is HTTP. You do not need to memorize its technical details yet; the essential idea is that the client sends a request, and the server sends a response.

For example, suppose Maya opens the profile for a user named riley.

1. The client asks for the profile associated with riley.
2. The backend checks what information Maya is allowed to see.
3. The backend obtains the permitted profile information from the database.
4. The backend returns a response, commonly structured data called JSON.
5. The client turns that data into a profile screen: avatar, display name, biography, follower count, and posts.

An API—application programming interface—is the agreed interface used for these conversations. It specifies what the client can ask for, what information it must provide, and what kind of reply it receives. An API is not necessarily a separate machine; it is a boundary and a set of rules between the client and the server-side parts of your system.

For a social app, API requests might express intentions such as:

User intention in the client	Backend operation
“Show Riley’s profile”	Retrieve public profile data and posts
“Follow Riley”	Check the signed-in user, prevent duplicates, store a follow relationship
“Publish this text post”	Validate the content and create a post record
“Send a message”	Confirm conversation membership and save the message
“Load my feed”	Find posts from followed accounts, order them, and return a limited page

Notice that the client can request an action, but the backend decides whether the action is valid and permitted.

A response can report success, but it can also explain failure. For instance, an attempt to follow a nonexistent account might receive a “not found” response; an attempt to delete someone else’s post should receive a “not allowed” response. The client is responsible for displaying these outcomes clearly. The backend is responsible for making the decision correctly.

---

The four responsibilities in a social app

The cleanest way to make architectural decisions is to ask one question repeatedly:

Is this about displaying and collecting input, applying trusted rules, storing structured relationships, or storing large files?

That question leads to the four-part map below.

1. Client: interface, interaction, and temporary screen state

The client is responsible for making the app usable across devices. It displays data it receives and collects user input.

Typical client responsibilities include:

• rendering a scrolling feed, profile screen, group page, and conversation;
• showing buttons, forms, image previews, loading indicators, and error messages;
• responding to taps, typing, and navigation;
• doing basic immediate validation, such as telling a user that a caption is too long;
• requesting data and actions through the API;
• temporarily holding interface state, such as “the upload is 60% complete” or “this tab is selected.”

The client can make the experience pleasant and responsive, but it cannot be trusted as the sole enforcer of safety or ownership rules.

For example, the client may disable the “Post” button until a caption is present. That improves usability. But the backend must still reject an empty or invalid post request, because a malicious or modified client could send one anyway.

2. Backend: trusted decisions and coordination

The backend is server-side code and managed server-side services. Its central role is to apply the app’s trusted rules before data is read or changed.

In a social app, backend responsibilities include:

• identifying the signed-in user;
• checking authorization: “May this user edit this profile?” or “May this person read this private group post?”;
• validating data according to the real rules;
• coordinating multiple actions, such as creating a post record only after an upload succeeds;
• querying and updating the database;
• creating secure upload permissions for media storage;
• returning only the data the client needs;
• triggering server-side work such as notifications or moderation workflows.

A useful distinction is:

• Client validation helps users fix mistakes early.
• Backend validation protects the system and must always be enforced.

Later in this course, Supabase will provide several backend capabilities—authentication, database access, security policies, storage, and real-time updates. This does not remove backend responsibilities. It gives you managed tools for implementing them, rather than requiring you to run every server component yourself.

3. Database: structured, queryable app facts

A database stores the structured facts that your app must preserve and search. These facts are not simply loose pieces of text; they have relationships.

For a social platform, typical database records include:

• a user account and public profile;
• a post, including its author, caption, publication time, and visibility;
• a follow relationship between two users;
• a group and its memberships;
• a conversation and its messages;
• a report submitted against a user, post, group, or message.

The database is good at questions such as:

• Which posts belong to this profile?
• Who follows this account?
• Does a follow relationship already exist?
• What are the latest 20 messages in this conversation?
• Which groups is this user allowed to view?

A database record for a post might look conceptually like this:

Field	Example value	Why it belongs in the database
id	post_4821	Identifies one post uniquely
author_id	user_107	Connects the post to its author
caption	“Sunset walk”	Stores post text
created_at	a date and time	Enables chronological ordering
media_url	a storage address	Locates the image or video file
visibility	public	Supports access rules

The crucial point is that the database often stores a reference to media, not the raw video or image itself.

4. Media storage: the large files

Images and videos are very different from usernames, captions, timestamps, and follow relationships. A single video can be many megabytes or much larger. Storing and serving such files requires a system designed for that task: media storage, sometimes called object storage or file storage.

Media storage is responsible for:

• receiving uploaded image and video files;
• keeping the file bytes reliably;
• serving a file efficiently when the client needs it;
• organizing files with storage paths;
• enforcing who may upload or view particular files;
• potentially supporting different versions or optimized forms of media.

A media-storage system should not decide whether a user is permitted to create a post. That is a backend authorization concern. Likewise, the database should not normally hold the full bytes of every video file. Instead, it stores metadata and a reference to the uploaded file.

---

A complete example: publishing a photo post

Now map one feature across all four responsibilities. Suppose a signed-in user selects a photo, writes “First spring flowers,” and presses Publish.

On the client

The app lets the person select a photo from their Android media library or browser. It shows a preview, collects the caption, and may check simple conditions such as whether a file was selected and whether the caption is within a visible character limit.

The client then asks the server-side system for permission to upload, or uses a carefully configured storage client. It displays upload progress so the person is not left wondering whether anything is happening.

In the backend and security layer

The backend verifies the person’s identity and checks that they are allowed to upload. It must enforce rules such as permitted file type, maximum file size, and the storage location that belongs to that user.

Once the file is stored, the backend validates the post data. It makes sure the caption satisfies the rules and that the media reference corresponds to a file the current user is actually permitted to attach.

In media storage

Media storage saves the actual JPEG, PNG, or video file under a controlled path. It can later provide the file to viewers who are authorized to see it.

In the database

The database stores the post’s structured record: author ID, caption, timestamp, visibility, and the URL or storage path for the media. It does not need to duplicate the full image bytes inside the post row.

Back on the client

After the operation succeeds, the client receives confirmation and updated post information. It renders the new post in the user’s profile or feed.

Here is the architecture map in a compact form:

Part	Owns this responsibility	Does not own this responsibility
Client	Screen, controls, previews, user feedback, requests	Final permission decisions; secret credentials
Backend	Authentication checks, authorization, validation, app rules, coordination	Rendering every pixel of the interface; long-term storage of video bytes
Database	Structured records and relationships that must be queried	The user interface; normally the raw files themselves
Media storage	Image and video files, controlled file delivery	Follow relationships, feed ordering rules, post ownership decisions

This division prevents common beginner mistakes. For example:

• Storing every image directly in a database makes file handling inefficient.
• Letting the client choose its own author ID enables impersonation.
• Putting database administration credentials in the client exposes the whole system.
• Making one giant “backend” function handle screen layout, data storage, file uploads, and permissions makes the app difficult to test and change.

---

Cross-platform does not mean four separate apps

Your goal is to support browsers, PCs, laptops, and mobile devices. The client must adapt to each environment: an Android phone has a small touch screen and a media library; a desktop browser may have a wide screen, keyboard, mouse, and file picker.

But the underlying social data should be consistent. Riley’s profile, a post’s author, a group membership, and a message should mean the same thing whichever device is used.

That is why a shared backend, database, and media-storage system are valuable:

• the web client and Android client request the same profile data;
• both clients follow the same authorization rules;
• both display the same stored posts and media;
• a photo posted from Android can appear in a browser feed.

The client varies by device experience. The server-side systems preserve the shared truth of the product.

One nuance matters: some managed services allow client apps to access data through their official SDKs without you writing a traditional custom server for every request. Firestore, for example, describes client SDK access alongside security rules. Even in this arrangement, the architecture still has a trusted server-side boundary: authentication and security rules control access, and clients receive restricted credentials rather than administrative database access. “Direct access” does not mean “the client can do anything it wants.”

---

A practical architecture sketch for this course

As the course develops, a practical first version of your app will have these conceptual layers:

The diagram intentionally shows the logical responsibilities. A service such as Supabase can host several of these pieces. That is convenient, but it does not collapse their roles: a database table, a storage bucket, an authentication service, and a client screen still have different jobs.

As you plan a feature, use this short checklist:

1. Client: What must the person see, enter, choose, or receive as feedback?
2. Backend: What rules must be enforced even if the client is altered?
3. Database: What structured facts and relationships must persist?
4. Media storage: Are there images, videos, or other large files? What record will refer to each file?

---

Key takeaways

A cross-platform social app is a system of cooperating parts, not one program running in one place.

• The client runs in the browser or on the phone and owns the interface and interactions.
• The backend is the trusted decision-maker: it checks identity, permissions, and app rules.
• The database stores structured, related facts such as profiles, posts, follows, groups, and messages.
• Media storage stores the large image and video files; the database usually stores their paths or URLs.
• HTTP requests and responses, often structured through an API, let clients communicate with server-side systems.
• Web and Android clients can differ in layout and device capabilities while sharing the same backend, database, and media storage.

Next, you will turn an app idea into a user story with observable acceptance criteria. That will give each future feature—such as following a user or publishing a post—a clear definition of what “working” actually means.