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 5 is:

• $5000
• $1000 MongoDB Atlas Credits
• A custom MongoDB onesie, which you’ll be able to retrieve at MongoDB World.
• A free Conference Pass to MongoDB World

Yuval! Congratulations Yuval, 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!

Jucilaine, Chris, Loan, Shrey, C, Mohamed, Agung, Tajay, Adam, Chi-Anh, Ryan, and Cameron!

Check out our blog for the solution to this challenge!

For this week's challenge, you'll take a simple website and use Stitch to connect it to a dataset, quickly building out a simple website.  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 use a new cluster) you can start by:

1. Launching a free MongoDB Atlas M0 instance.

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

3. Creating a Stitch application and linking your Atlas cluster to Stitch.

You have until Monday, June 3rd, at 5:00pm (Eastern Daylight Time) to submit your answers.

You’ll begin this challenge by getting a copy of the starter website code. Next, you’ll configure rules and authentication. Then you’ll enable the search functionality in the website by using Stitch’s QueryAnywhere. Finally, you’ll put your site online using Stitch’s Static Hosting.

The Starter Website

We have created starter code for a website that allows you to search for Airbnb properties. You’ll use this code to complete the challenge.

1. Get a copy of the code in the GitHub repo https://github.com/mongodb-developer/weekly-challenge-5 by cloning the repo or downloading it.

2. Open index.html in your browser. The page should load, but the search functionality will not work until you update data.js later in this challenge.

Rules and Authentication

The first step in this challenge is to configure access to the Airbnb data in your Atlas cluster via Stitch by defining rules. When using Stitch, your data is protected by default – applications won't be able to access any data before you create rules permitting access.

1. Since we'll be using the sample Airbnb dataset, create rules for the sample_airbnb database and listingsAndReviews collection that allow any user to read (but not write to!) the following fields:

a. address

b. bathrooms

c. bedrooms

d. name

e. price

f. property_type  

2. Enable anonymous authentication. Even when rules are enabled, Stitch requires all requests to be authenticated. Since this data is not sensitive and we want our Airbnb searching site to be publicly available, you can simply enable anonymous authentication.  

Enabling Searching with QueryAnywhere

It might not seem like much, but with Atlas and Stitch you've now created a simple backend that allows protected access to your data. Now, all that's left to do is connect your website to your data.

1. Open data.js in your favorite code editor.  

2. Update lines 7-10 to ensure your frontend is pointing to the correct application and MongoDB service.

3. Next, the searchAndBuild() function should query MongoDB for relevant data before populating the UI. Around line 50, write a query using Stitch's SDK to find documents that match all of the search parameters currently selected in the dropdowns and pass the results to the refreshTable() function. Make sure that the query you write returns properties that:

a. Are located in the country specified.

b. Have at least as many bathrooms as specified.

c. Have at least as many bedrooms as specified.

d. Do not exceed the specified price per night.

e. Match the property type specified

Performance tip: Since Stitch operates on field-level rules, you can speed up your queries by adding a projection within your query options that filters out unnecessary fields.  

4. In addition to the table, the site has text that displays:

a. How many results are being displayed

b. The total number of matching results

c. The average price for all results.  

The searchAndBuild() function is responsible for calculating the data described above.  In order to calculate these, you should write an Aggregation Pipeline using the Stitch SDK that produces the total number of matching results and the average price. Update the searchAndBuild() function to calculate the data and send the results to updateAggregateText().

Tip: You can use the Compass aggregation builder for help constructing your pipeline.

Checking Your Work

You can run the following search to verify that your search code is written correctly:

• Country: United States

• Type: Condominium

• Beds: 2

• Baths: 1

• Price: 500

This search should yield 72 results with an average price of $266 per night.  

Hosting your Website

After testing your website locally to ensure that your connection to Atlas, authentication, rules, and queries work, it's time to host your site so that anyone can use it.  

1. Use Stitch's Static Hosting to put your site online.

Once you have completed all of the challenge tasks, click the button below to submit your answers!

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?