The first twenty correct submissions will receive a $10 prize and will be entered into a raffle for the main prize. The main prize for week 4 is:

• $4000
• $500 MongoDB Atlas Credits
• A custom MongoDB sweatshirt, which you’ll be able to retrieve at MongoDB World.
• A Conference Pass to MongoDB World

Jonathan! Congratulations Jonathan, we will send you an email with all the details about your prize.

And here are the names of all the others who submitted correct answers. We will notify you by email about your $10 prize!

Beatriz, Shrey, Tajay, and Yuval!

Check out our blog for the solution to this challenge!

In the week two challenge, we loaded a sample Airbnb data set into MongoDB Atlas and discovered some interesting insights using MongoDB Charts.

Our engineers are very excited to find potential accommodation for their next offsite, but we'd like to save them time by filtering out some of the less relevant fields and listings. We also need a way for engineers to submit their swag preference for the offsite.

For this week's challenge, we'd like your help to set up a basic API for the Airbnb data using MongoDB Stitch's Rules and Webhooks features.

Your API will provide three endpoints for employees to use:

• An endpoint to search Airbnb listings using Stitch Rules and Filters to focus on relevant documents and fields.

• An endpoint to capture swag preferences.

• An endpoint to return all swag preferences sorted by submission date (descending).

You have until Monday, May 27th, at 5:00pm (Eastern Daylight Time) to submit your answers. 

If you’ve completed some of the previous challenges, you can reuse your existing MongoDB Atlas cluster and Stitch application.

If this is your first challenge (or you’d like to start anew), the prerequisite steps are:

1. Launch a free MongoDB Atlas M0 instance.

2. Load the Atlas sample data sets into your cluster.

3. Create a Stitch application with a global deployment region.

To help you verify the correctness of your API, we've provided a basic test suite so you can iterate on your Stitch app before submitting. This test suite may not cover all of the requirements, so read the tasks carefully. Use of the test suite is optional, but recommended.

To run the test suite you will need to have the git version control client and Node.js runtime:

• git clone https://github.com/mongodb-developer/weekly-challenge-4

• cd weekly-challenge-4

• npm install

• npm start -- --app <APP_ID>

Replace <APP_ID> with your Stitch App ID, which can be found near the top left of your Stitch application page.

1. Rules and filters allow you to configure data visibility via the Stitch admin UI. When you create a webhook, you can choose one of three ways to configure the execution permissions. In this case, we will configure the webhook to run as a specific application user, so we will be able to apply rules and filters. See the Stitch Incoming Webhooks documentation for more information.

Create a user for the application backend using the Stitch Email/Password authentication provider.

Email: <specify your email address>

Password: <specify your own password>

Note: The Email Confirmation URL and Password Reset URL are required fields in the Stitch provider configuration, but the values will not be used in this challenge. You can use https://localhost as a placeholder for these required URLs.

2. The sample data set includes a lot of information, but we’d like to focus on the core fields.

Create a Stitch Rule for the database sample_airbnb and collection listingsAndReviews.

The default role should provide read-only access to this collection with only the following fields readable:

• _id

• listing_url

• name

• summary

• property_type

• room_type

• bedrooms

• beds

• bathrooms

• price

• cleaning_fee

• address

• number_of_reviews

• review_scores

3. We only want our engineers to see popular listings which are affordable and well rated.

Create a filter for the collection so the only listings available to incoming queries have:

• a price less than $300

• more than 50 reviews

• a review score rating greater than 95

4. It’s now time to create a webhook that will provide a search API for listings matching the Stitch rule that you created.

Create an HTTP service called offsite with a GET webhook called search-listings that requires a query parameter secret submission1. An external service should be able to call this webhook to query the listingsAndReviews collection based on exact matches for any fields specified in the query parameters. The Content-Type returned should be application/json.

For example, the external service should be able to access this webhook with a URL similar to:

https://webhooks.mongodb-stitch.com/api/client/v2.0/app/<APP_ID>/service/offsite/incoming_webhook/search-listings?secret=submission1&address.country_code=AU&address.suburb=Haymarket.

On success, the webhook should return an array of up to 5 results in MongoDB Extended JSON (EJSON) format in descending order by review_scores_rating. The HTTP status response code should be 200, and the only visible fields in the results should be those readable based on the Stitch Rule you created earlier. If you find yourself stuck, the Stitch Webhook Requests & Responses documentation may be a helpful read.

Hints:

• When editing a webhook function you can use the Settings tab to check or change details such as the webhook name, HTTP method, and query secret. There is also a handy curl command line you can copy to make test requests.

• The GET payload.query document looks very similar to find() query criteria.

• If the test suite is failing, check your Stitch activity log.

5. Every offsite attendee will be given a special limited edition swag gift. We need to capture the employee’s preferences based on the types of swag we will have available.

Create another Stitch rule for a new database, employees, and new collection, preferences. Users should have read/write access to the collection, and documents to be inserted should pass a document schema check:

• _id is a field of type objectId.

• firstname is a required field of type string.

• lastname is a required field of type string.

• swag_type should only be able to accept the following values: "jacket", "t-shirt", "hoodie", "vest".

• swag_size should only be able to accept the following values: "xs", "s", "m", "l", "xl".

6. We need to create a second webhook that will insert a new document with the employee’s swag preference.

Create a POST webhook called add-swagpref within the offsite HTTP service that requires a query parameter secret submission2. An external service should be able to call this webhook to insert a document into the employees.preferences collection. On success, the webhook should return HTTP status code 201 and the Content-Type returned should be application/json.

Hints:

• POST requests receive data in the body of the request.

• If you are testing using curl add the -i command line option to include HTTP headers in the output. The first line will indicate the HTTP status code returned.

• Are you handling exceptions correctly?

7. Test that the webhook accepts the expected preferences document.

Insert one document into employees.preferences collection with the following template:

{

"firstname": <your first name>,

"lastname": <your last name>,

"swag_type": "t-shirt",

"swag_size": "m"

}

8. The third and final webhook will return employee swag preferences sorted in descending order by submission date.

Create a GET webhook called get-swagprefs within the offsite HTTP service that requires a query parameter secret submission3. An external service should be able to call this webhook to read the document described above within the employees.preferences collection. On success, the webhook should return a EJSON array sorted in descending order by submission date. The HTTP status code should be 200 and the Content-Type returned should be application/json. 

Hint:

• The default primary key for each document is _id, which is an ObjectId value that includes a timestamp as the leading component.

Using the match expression we can limit the amount of data that the change stream needs to look at,  this match expression is similar to the match in the aggregation framework, below are some document links that are important for this challenge:

• Triggers: especially match expressions section, some example trigger code can be found in this link.

• Functions: a function will be associated with the trigger, if you allow the trigger to create the function it will populate it with sample trigger code.

• $match: this is the aggregation operator used in the trigger match expression

• $in: A useful operator to find documents where the value of a field equals any value in a specified array

• $inc: increment the number value in the field by a specified amount.

• Can we create an aggregation query on the sales data to validate our trigger?