Why server-side logic reduces client complexity in Supabase - Visual Breakdown

Process Flow - Why server-side logic reduces client complexity

Client sends request

↓

Server receives request

↓

Server processes logic

↓

Server sends back simple result

↓

Client receives simple data

↓

Client displays data easily

The client sends a request to the server, which handles the complex logic and returns simple data. This keeps the client code easy and clean.

Execution Sample

Supabase

const { data, error } = await supabase.rpc('get_user_profile', { user_id: 123 });
if (error) console.error(error);
else displayProfile(data);

Client calls a server-side function to get user profile data, handling only the display.

Process Table

Step	Action	Client State	Server State	Result Sent Back
1	Client calls server function 'get_user_profile' with user_id=123	Waiting for response	Received request with user_id=123	No data yet
2	Server runs logic to fetch user profile from database	Waiting for response	Fetching user profile data	No data yet
3	Server processes and formats user profile data	Waiting for response	User profile data ready	No data yet
4	Server sends back user profile data	Waiting for response	Sent data to client	User profile data sent
5	Client receives data and calls displayProfile(data)	Data received, ready to display	Idle	User profile data displayed
6	Execution ends	Profile shown to user	Idle	Process complete

💡 Client receives processed data; no complex logic needed on client side

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
client_state	Idle	Waiting for response	Waiting for response	Waiting for response	Waiting for response	Data received	Profile shown
server_state	Idle	Received request	Fetching user profile data	User profile data ready	Sent data	Idle	Idle
result_data	None	None	None	User profile data	User profile data	User profile data	Displayed

Key Moments - 3 Insights

Why doesn't the client handle the data fetching logic?

Because the server runs the complex logic (see execution_table step 2 and 3), the client only waits for the final data, keeping client code simple.

What happens if the server takes time to process the request?

The client stays in 'Waiting for response' state (execution_table steps 1-4), showing that server-side logic can delay response but keeps client code clean.

How does server-side logic help with security?

Server controls data access and processing (step 2), so sensitive logic is hidden from client, reducing risk of exposing secrets or complex code.

Visual Quiz - 3 Questions

Look at the execution_table, what is the client state at Step 3?

A Data received

B Idle

C Waiting for response

D Sending request

💡 Hint

Check the 'Client State' column at Step 3 in execution_table

At which step does the server send the processed data back to the client?

A Step 4

B Step 2

C Step 5

D Step 3

💡 Hint

Look for 'Server sends back user profile data' in execution_table

If the client had to fetch and process data itself, how would the client state change in the variable_tracker?

A Client state would remain 'Idle' throughout

B Client state would include 'Fetching data' and 'Processing data'

C Server state would change to 'Waiting'

D Result data would be 'None' at all times

💡 Hint

Think about client_state changes in variable_tracker and what happens if client does more work

Concept Snapshot

Server-side logic means the server does the hard work.
Client sends simple requests and gets simple results.
This keeps client code easy and fast.
Server controls data and security.
Client only displays data, reducing bugs and complexity.

Full Transcript

When using server-side logic, the client sends a request to the server. The server then runs the complex logic, like fetching and processing data. After that, the server sends back only the needed simple data. The client just waits and then shows the data. This way, the client code stays simple and easy to manage. The server also keeps control of data security and processing. This reduces mistakes and makes apps faster and safer.

Practice

1. Why does moving logic to the server reduce complexity on the client side in Supabase?

easy

A. Because the client does not need to handle complex rules or validations.

B. Because the client can store all data locally without syncing.

C. Because the client runs faster without any network calls.

D. Because the client can directly modify the database schema.

Solution

1. Step 1: Understand client responsibilities

   The client usually handles user interface and simple logic but complex rules can make it bulky.

2. Step 2: Role of server-side logic

   Moving complex rules to the server means the client only sends requests and receives results, simplifying its code.

3. Final Answer:

   Because the client does not need to handle complex rules or validations. -> Option A

4. Quick Check:

   Server logic reduces client complexity = A [OK]

Hint: Server logic handles rules, client stays simple [OK]

Common Mistakes:

• Thinking client stores all data locally
• Assuming client runs faster without network
• Believing client can change database schema

2. Which of the following is the correct way to define a PostgreSQL function in Supabase for server-side logic?

easy

A. CREATE FUNCTION check_user() RETURNS void AS $$ BEGIN IF NEW.age < 18 THEN RAISE EXCEPTION 'Too young'; END IF; END; $$ LANGUAGE plpgsql;

B. CREATE FUNCTION check_user RETURNS void BEGIN IF NEW.age < 18 THEN RAISE EXCEPTION 'Too young'; END IF; END;

C. FUNCTION check_user() RETURNS void { IF NEW.age < 18 THEN THROW 'Too young'; }

D. CREATE PROCEDURE check_user() BEGIN IF NEW.age < 18 THEN RAISE ERROR 'Too young'; END IF; END;

Solution

1. Step 1: Check PostgreSQL function syntax

   PostgreSQL functions use CREATE FUNCTION, specify RETURNS, and use $$ to wrap the body with LANGUAGE plpgsql.

2. Step 2: Identify correct syntax in options

   CREATE FUNCTION check_user() RETURNS void AS $$ BEGIN IF NEW.age < 18 THEN RAISE EXCEPTION 'Too young'; END IF; END; $$ LANGUAGE plpgsql; correctly uses CREATE FUNCTION, RETURNS void, $$ body $$, and LANGUAGE plpgsql.

3. Final Answer:

   CREATE FUNCTION check_user() RETURNS void AS $$ BEGIN IF NEW.age < 18 THEN RAISE EXCEPTION 'Too young'; END IF; END; $$ LANGUAGE plpgsql; -> Option A

4. Quick Check:

   Correct PostgreSQL function syntax = D [OK]

Hint: Look for CREATE FUNCTION with $$ and LANGUAGE plpgsql [OK]

Common Mistakes:

• Omitting RETURNS keyword
• Missing $$ around function body
• Using THROW or RAISE ERROR instead of RAISE EXCEPTION

3. Given this Supabase trigger function, what happens when a new user with age 16 is inserted?

CREATE FUNCTION check_age() RETURNS trigger AS $$ BEGIN IF NEW.age < 18 THEN RAISE EXCEPTION 'User too young'; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; CREATE TRIGGER age_check BEFORE INSERT ON users FOR EACH ROW EXECUTE FUNCTION check_age();

medium

A. The insert succeeds and the user is added.

B. The insert succeeds but age is set to 18 automatically.

C. The insert fails with an error 'User too young'.

D. The insert is ignored silently without error.

Solution

1. Step 1: Understand trigger behavior

   The trigger runs BEFORE INSERT and checks if NEW.age is less than 18.

2. Step 2: Analyze condition for age 16

   Since 16 < 18, the trigger raises an exception 'User too young', which stops the insert.

3. Final Answer:

   The insert fails with an error 'User too young'. -> Option C

4. Quick Check:

   Trigger raises error on age < 18 = C [OK]

Hint: Trigger raises error if condition met, blocking insert [OK]

Common Mistakes:

• Thinking insert succeeds despite error
• Assuming age auto-corrects to 18
• Believing insert is ignored without error

4. You wrote this trigger function in Supabase but it does not block invalid inserts as expected:

CREATE FUNCTION check_age() RETURNS trigger AS $$ BEGIN IF NEW.age < 18 THEN RETURN NULL; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql;

What is the main issue?

medium

A. The function must return OLD instead of NEW.

B. Returning NULL in BEFORE INSERT triggers causes the row to be skipped silently.

C. The trigger is missing the EXECUTE FUNCTION statement.

D. The function should use RAISE EXCEPTION to block inserts, not RETURN NULL.

Solution

1. Step 1: Understand RETURN NULL in triggers

   In BEFORE INSERT triggers, returning NULL silently skips the row without error.

2. Step 2: Correct way to block insert

   To block inserts with an error, the function must RAISE EXCEPTION instead of returning NULL.

3. Final Answer:

   The function should use RAISE EXCEPTION to block inserts, not RETURN NULL. -> Option D

4. Quick Check:

   Use RAISE EXCEPTION to block inserts = A [OK]

Hint: RETURN NULL skips silently; use RAISE EXCEPTION to block [OK]

Common Mistakes:

• Returning NULL expecting error
• Forgetting EXECUTE FUNCTION in trigger
• Returning OLD in insert triggers

5. You want to reduce client complexity by enforcing a rule that users must have unique emails and be at least 18 years old. Which combination of Supabase features best achieves this with minimal client code?

hard

A. Check email uniqueness and age on the client before sending data to Supabase.

B. Use a UNIQUE constraint on email and a BEFORE INSERT trigger function that raises an exception if age < 18.

C. Use a BEFORE INSERT trigger to check email uniqueness and age, but no database constraints.

D. Use only a UNIQUE constraint on email and let the client check age.

Solution

1. Step 1: Enforce email uniqueness

   A UNIQUE constraint on the email column ensures no duplicates at the database level.

2. Step 2: Enforce age rule server-side

   A BEFORE INSERT trigger function can check age and raise an exception if under 18, blocking invalid inserts.

3. Final Answer:

   Use a UNIQUE constraint on email and a BEFORE INSERT trigger function that raises an exception if age < 18. -> Option B

4. Quick Check:

   Database constraints + trigger enforce rules, reduce client code = B [OK]

Hint: Combine UNIQUE constraint and trigger for full server-side checks [OK]

Common Mistakes:

• Relying only on client-side checks
• Using triggers without constraints for uniqueness
• Ignoring age validation on server