Eliot's Weekly MongoDB World Challenge Week 5


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.