Why Resource and request objects in Firebase? - Purpose & Use Cases

The Big Idea

What if your backend could instantly know who's asking and what they want without you writing extra checks?

The Scenario

Imagine you are manually handling every user request in your Firebase backend by writing separate code for each type of data and action.

You have to check who sent the request, what data they want, and what they are allowed to do -- all by yourself.

The Problem

This manual approach is slow and confusing.

You might forget to check permissions or mix up data formats.

It's easy to make mistakes that break your app or expose private data.

The Solution

Resource and request objects organize all this information neatly.

They automatically provide the data and context you need for each request.

This makes your code simpler, safer, and easier to manage.

Before vs After

✗ Before

function handleRequest(data, user) {
  if (user.isAdmin) {
    // process data
  }
}

✓ After

const functions = require('firebase-functions');

exports.myFunction = functions.firestore.document('chats/{chatId}').onCreate((snap, context) => {
  const resource = snap.data();
  const user = context.auth;
  // use resource and user safely
});

What It Enables

It enables building secure, clear, and maintainable backend functions that respond correctly to each user's request.

Real Life Example

For example, a chat app can use request objects to know who is sending a message and resource objects to know which chat room the message belongs to, ensuring only authorized users can post.

Key Takeaways

Manual request handling is error-prone and complex.

Resource and request objects provide organized access to request data and user info.

This leads to safer and cleaner backend code in Firebase.

Practice

1. What does a request object in Firebase functions mainly contain?

easy

A. Logs of previous function executions

B. Details about the data or file that triggered the function

C. Settings for Firebase project configuration

D. Information about what the user sent and how

Solution

1. Step 1: Understand the role of request objects

   The request object holds details about the user's input and request method.

2. Step 2: Differentiate from resource objects

   Resource objects describe the trigger data or file, not user input.

3. Final Answer:

   Information about what the user sent and how -> Option D

4. Quick Check:

   Request object = user input info [OK]

Hint: Request = user input details, Resource = trigger data [OK]

Common Mistakes:

• Confusing resource object with request object
• Thinking request holds trigger file info
• Assuming request contains project settings

2. Which of the following is the correct way to access the data sent by a user in a Firebase HTTPS function's request object?

easy

A. request.data.body

B. request.body.data

C. request.payload

D. request.trigger.data

Solution

1. Step 1: Recall request object structure

   In Firebase HTTPS functions, user data is inside request.body.

2. Step 2: Identify correct property for user data

   The user data is accessed as request.body.data if data is nested inside body.

3. Final Answer:

   request.body.data -> Option B

4. Quick Check:

   Access user data via request.body.data [OK]

Hint: User data is inside request.body in HTTPS functions [OK]

Common Mistakes:

• Using request.data.body which is invalid
• Trying to access request.payload which doesn't exist
• Confusing trigger data with request data

3. Given this Firebase function snippet:

exports.myFunction = functions.storage.object().onFinalize((object, context) => {
  console.log(object.name);
  console.log(context.eventId);
});

What does the object parameter represent?

medium

A. The Firebase project configuration

B. The user's HTTP request data

C. The file that triggered the function

D. The function's execution logs

Solution

1. Step 1: Identify the trigger type

   The function triggers on a storage object finalization, meaning a file event.

2. Step 2: Understand the object parameter

   The object parameter holds info about the file that triggered the function.

3. Final Answer:

   The file that triggered the function -> Option C

4. Quick Check:

   Storage trigger object = file info [OK]

Hint: Storage triggers pass file info as object parameter [OK]

Common Mistakes:

• Thinking object is user request data
• Confusing context with resource object
• Assuming object holds config or logs

4. Identify the error in this Firebase HTTPS function code:

exports.func = functions.https.onRequest((resource, request) => {
  console.log(request.body);
});

medium

A. Parameters are reversed; should be (request, response)

B. Missing return statement

C. Incorrect function name

D. No error; code is correct

Solution

1. Step 1: Check HTTPS function parameters

   HTTPS functions receive (request, response) parameters in that order.

2. Step 2: Identify parameter misuse

   The code uses (resource, request) which reverses and misnames parameters.

3. Final Answer:

   Parameters are reversed; should be (request, response) -> Option A

4. Quick Check:

   HTTPS function params = (request, response) [OK]

Hint: HTTPS functions always use (request, response) parameters [OK]

Common Mistakes:

• Swapping request and response parameters
• Using resource parameter in HTTPS function
• Ignoring parameter order importance

5. You want to write a Firebase function triggered by Firestore document changes. Which object should you use to access the changed document's data inside the function?

hard

A. resource.after.data()

B. request.body

C. context.params

D. resource.data()

Solution

1. Step 1: Understand Firestore trigger parameters

   Firestore triggers receive a change object with before and after snapshots.

2. Step 2: Access the new document data

   The updated document data is accessed via change.after.data(), which is the resource object.

3. Final Answer:

   resource.after.data() -> Option A

4. Quick Check:

   Firestore change after data = resource.after.data() [OK]

Hint: Use resource.after.data() for updated Firestore document data [OK]

Common Mistakes:

• Using request.body which is for HTTP functions
• Using context.params which holds path variables
• Using resource.data() which is old snapshot, not updated