Diferencias entre cliente y servidor en aplicaciones web

Understanding client state vs server state boosts clarity and confidence when building Lovable apps. Here you’ll see how the client (front end) talks to the server (back end in Supabase), how RLS (row-level security) protects data, and how edge functions make API calls to external providers like OpenAI so your app can respond fast and securely.

What is the client side in your front end?

The client is the interface your user connects through. Think of the photo renaming app: it’s the front end where interactions happen and where the user sees their email or photos after data comes back from the server.

• The client is the front end where your code runs and users interact.
• It sends requests to the server and waits for responses.
• It displays user-specific data such as email or photos.
• In a table tennis view, the client “pings” a request to the server.

How does the server side work with Supabase, RLS and the database?

The server is your back end in Supabase. Before the database is accessed, RLS checks who the user is and what rows they can see. With the right permissions, the database sends the allowed data back through the “firewall” to the client.

• The server holds the database, RLS and edge functions.
• RLS acts like a firewall that filters access to data by user.
• With valid permissions, the server returns the requested data to the client.

How do permissions and roles affect data access?

Access is driven by identity and roles. If a user is logged in, they see only their rows. If the user has an admin role, they can see all rows.

• Logged-in user: show only that user’s data.
• Admin role: show all data across the system.
• System roles extend what a user can access based on their role.

How to visualize client-server with a table tennis metaphor?

Each user action is a “ping” from client to server. The server processes the request and “pongs” the response back.

• Client sends a request: ping to the server.
• Server validates via RLS and queries the database.
• Server returns a response: pong back to the client.

Why use API calls and edge functions to reach external providers?

Edge functions run on the server to make API calls to an external provider (for example, OpenAI). They fetch data, optionally save it to the database, and return it to the front end.

• Edge functions contact external services securely.
• They can persist results to the database or return them directly.
• This keeps sensitive logic on the server side and data flowing smoothly to the client.

Have questions or a use case you want to discuss? Share a comment and let’s explore how to model your client and server state effectively.