diff --git a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/chain-middleware-to-create-a-time-server.english.md b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/chain-middleware-to-create-a-time-server.english.md
index 95c0b25ea1..bd07d5046b 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/chain-middleware-to-create-a-time-server.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/chain-middleware-to-create-a-time-server.english.md
@@ -8,14 +8,16 @@ challengeType: 2
Middleware can be mounted at a specific route using app.METHOD(path, middlewareFunction). Middleware can also be chained inside route definition.
Look at the following example:
-
-app.get('/user', function(req, res, next) {
- req.user = getTheUserSync(); // Hypothetical synchronous operation
- next();
-}, function(req, res) {
- res.send(req.user);
+
+```js
+app.get('/user', function(req, res, next) {
+ req.user = getTheUserSync(); // Hypothetical synchronous operation
+ next();
+}, function(req, res) {
+ res.send(req.user);
});
-
+```
+
This approach is useful to split the server operations into smaller units. That leads to a better app structure, and the possibility to reuse code in different places. This approach can also be used to perform some validation on the data. At each point of the middleware stack you can block the execution of the current chain and pass control to functions specifically designed to handle errors. Or you can pass control to the next matching route, to handle special cases. We will see how in the advanced Express section.
diff --git a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/implement-a-root-level-request-logger-middleware.english.md b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/implement-a-root-level-request-logger-middleware.english.md
index c4515417f6..69246aa8ae 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/implement-a-root-level-request-logger-middleware.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/implement-a-root-level-request-logger-middleware.english.md
@@ -8,12 +8,14 @@ challengeType: 2
Earlier, you were introduced to the express.static() middleware function. Now it’s time to see what middleware is, in more detail. Middleware functions are functions that take 3 arguments: the request object, the response object, and the next function in the application’s request-response cycle. These functions execute some code that can have side effects on the app, and usually add information to the request or response objects. They can also end the cycle by sending a response when some condition is met. If they don’t send the response when they are done, they start the execution of the next function in the stack. This triggers calling the 3rd argument, next().
Look at the following example:
-
-function(req, res, next) {
- console.log("I'm a middleware...");
- next();
+
+```js
+function(req, res, next) {
+ console.log("I'm a middleware...");
+ next();
}
-
+```
+
Let’s suppose you mounted this function on a route. When a request matches the route, it displays the string “I’m a middleware…”, then it executes the next function in the stack.
In this exercise, you are going to build root-level middleware. As you have seen in challenge 4, to mount a middleware function at root level, you can use the app.use(<mware-function>) method. In this case, the function will be executed for all the requests, but you can also set more specific conditions. For example, if you want a function to be executed only for POST requests, you could use app.post(<mware-function>). Analogous methods exist for all the HTTP verbs (GET, DELETE, PUT, …).
diff --git a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/serve-an-html-file.english.md b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/serve-an-html-file.english.md
index 899c21537d..cd9bcbf82a 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/serve-an-html-file.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/serve-an-html-file.english.md
@@ -7,7 +7,11 @@ challengeType: 2
## Description
You can respond to requests with a file using the res.sendFile(path) method. You can put it inside the app.get('/', ...) route handler. Behind the scenes, this method will set the appropriate headers to instruct your browser on how to handle the file you want to send, according to its type. Then it will read and send the file. This method needs an absolute file path. We recommend you to use the Node global variable __dirname to calculate the path like this:
-absolutePath = __dirname + relativePath/file.ext
+
+```js
+absolutePath = __dirname + relativePath/file.ext
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/start-a-working-express-server.english.md b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/start-a-working-express-server.english.md
index 02e2aab05e..8d25c42e9e 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/start-a-working-express-server.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/start-a-working-express-server.english.md
@@ -9,10 +9,13 @@ challengeType: 2
In the first two lines of the file myApp.js, you can see how easy it is to create an Express app object. This object has several methods, and you will learn many of them in these challenges. One fundamental method is app.listen(port). It tells your server to listen on a given port, putting it in running state. You can see it at the bottom of the file. It is inside comments because, for testing reasons, we need the app to be running in the background. All the code that you may want to add goes between these two fundamental parts. Glitch stores the port number in the environment variable process.env.PORT. Its value is 3000.
Let’s serve our first string! In Express, routes takes the following structure: app.METHOD(PATH, HANDLER). METHOD is an http method in lowercase. PATH is a relative path on the server (it can be a string, or even a regular expression). HANDLER is a function that Express calls when the route is matched.
Handlers take the form function(req, res) {...}, where req is the request object, and res is the response object. For example, the handler
-
-function(req, res) {
- res.send('Response String');
-}
+
+```js
+function(req, res) {
+ res.send('Response String');
+}
+```
+
will serve the string 'Response String'.
diff --git a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/use-body-parser-to-parse-post-requests.english.md b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/use-body-parser-to-parse-post-requests.english.md
index fb40871cef..1755844bad 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/use-body-parser-to-parse-post-requests.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/basic-node-and-express/use-body-parser-to-parse-post-requests.english.md
@@ -8,7 +8,16 @@ challengeType: 2
Besides GET, there is another common HTTP verb, it is POST. POST is the default method used to send client data with HTML forms. In REST convention, POST is used to send data to create new items in the database (a new user, or a new blog post). You don’t have a database in this project, but you are going to learn how to handle POST requests anyway.
In these kind of requests, the data doesn’t appear in the URL, it is hidden in the request body. This is a part of the HTML request, also called payload. Since HTML is text-based, even if you don’t see the data, it doesn’t mean that it is secret. The raw content of an HTTP POST request is shown below:
-POST /path/subpath HTTP/1.0
From: john@example.com
User-Agent: someBrowser/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 20
name=John+Doe&age=25
+
+```http
+POST /path/subpath HTTP/1.0
+From: john@example.com
+User-Agent: someBrowser/1.0
+Content-Type: application/x-www-form-urlencoded
+Content-Length: 20
+name=John+Doe&age=25
+```
+
As you can see, the body is encoded like the query string. This is the default format used by HTML forms. With Ajax, you can also use JSON to handle data having a more complex structure. There is also another type of encoding: multipart/form-data. This one is used to upload binary files.
In this exercise, you will use a urlencoded body. To parse the data coming from POST requests, you have to install the body-parser package. This package allows you to use a series of middleware, which can decode data in different formats.
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-description-to-your-package.json.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-description-to-your-package.json.english.md
index 6b107d878d..e65cf482ef 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-description-to-your-package.json.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-description-to-your-package.json.english.md
@@ -9,7 +9,11 @@ challengeType: 2
The next part of a good package.json file is the description field; where a short, but informative description about your project belongs.
If you some day plan to publish a package to npm, this is the string that should sell your idea to the user when they decide whether to install your package or not. However, that’s not the only use case for the description, it’s a great way to summarize what a project does. It’s just as important in any Node.js project to help other developers, future maintainers or even your future self understand the project quickly.
Regardless of what you plan for your project, a description is definitely recommended. Here's an example:
-"description": "A project that does something awesome",
+
+```json
+"description": "A project that does something awesome",
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-license-to-your-package.json.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-license-to-your-package.json.english.md
index cae4dae792..3bb9e6efcc 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-license-to-your-package.json.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-license-to-your-package.json.english.md
@@ -8,7 +8,11 @@ challengeType: 2
The license field is where you inform users of what they are allowed to do with your project.
Some common licenses for open source projects include MIT and BSD. License information is not required, and copyright laws in most countries will give you ownership of what you create by default. However, it’s always a good practice to explicitly state what users can and can’t do. Here's an example of the license field:
-"license": "MIT",
+
+```json
+"license": "MIT",
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-version-to-your-package.json.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-version-to-your-package.json.english.md
index 687edf07fb..03b32c6f87 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-version-to-your-package.json.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-a-version-to-your-package.json.english.md
@@ -7,7 +7,11 @@ challengeType: 2
## Description
A version is one of the required fields of your package.json file. This field describes the current version of your project. Here's an example:
-"version": "1.2",
+
+```json
+"version": "1.2",
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-keywords-to-your-package.json.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-keywords-to-your-package.json.english.md
index b0748cf0a8..52ccb6e45a 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-keywords-to-your-package.json.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/add-keywords-to-your-package.json.english.md
@@ -7,7 +7,11 @@ challengeType: 2
## Description
The keywords field is where you can describe your project using related keywords. Here's an example:
-"keywords": [ "descriptive", "related", "words" ],
+
+```json
+"keywords": [ "descriptive", "related", "words" ],
+```
+
As you can see, this field is structured as an array of double-quoted strings.
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/expand-your-project-with-external-packages-from-npm.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/expand-your-project-with-external-packages-from-npm.english.md
index 4894a8706d..059506af9b 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/expand-your-project-with-external-packages-from-npm.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/expand-your-project-with-external-packages-from-npm.english.md
@@ -8,12 +8,15 @@ challengeType: 2
One of the biggest reasons to use a package manager, is their powerful dependency management. Instead of manually having to make sure that you get all dependencies whenever you set up a project on a new computer, npm automatically installs everything for you. But how can npm know exactly what your project needs? Meet the dependencies section of your package.json file.
In this section, packages your project requires are stored using the following format:
-
-"dependencies": {
- "package-name": "version",
- "express": "4.14.0"
-}
-
+
+```json
+"dependencies": {
+ "package-name": "version",
+ "express": "4.14.0"
+}
+
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/how-to-use-package.json-the-core-of-any-node.js-project-or-npm-package.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/how-to-use-package.json-the-core-of-any-node.js-project-or-npm-package.english.md
index 6138814f29..23659b01e9 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/how-to-use-package.json-the-core-of-any-node.js-project-or-npm-package.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/how-to-use-package.json-the-core-of-any-node.js-project-or-npm-package.english.md
@@ -9,7 +9,11 @@ challengeType: 2
The package.json file is the center of any Node.js project or npm package. It stores information about your project, similar to how the <head> section of an HTML document describes the content of a webpage. It consists of a single JSON object where information is stored in key-value pairs. There are only two required fields; "name" and "version", but it’s good practice to provide additional information about your project that could be useful to future users or maintainers.
If you look at the file tree of your project, you will find the package.json file on the top level of the tree. This is the file that you will be improving in the next couple of challenges.
One of the most common pieces of information in this file is the author field. It specifies who created the project, and can consist of a string or an object with contact or other details. An object is recommended for bigger projects, but a simple string like the following example will do for this project.
-"author": "Jane Doe",
+
+```json
+"author": "Jane Doe",
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/manage-npm-dependencies-by-understanding-semantic-versioning.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/manage-npm-dependencies-by-understanding-semantic-versioning.english.md
index d80be0879d..19f8a9d05c 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/manage-npm-dependencies-by-understanding-semantic-versioning.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/manage-npm-dependencies-by-understanding-semantic-versioning.english.md
@@ -8,7 +8,11 @@ challengeType: 2
Versions of the npm packages in the dependencies section of your package.json file follow what’s called Semantic Versioning (SemVer), an industry standard for software versioning aiming to make it easier to manage dependencies. Libraries, frameworks or other tools published on npm should use SemVer in order to clearly communicate what kind of changes projects can expect if they update.
Knowing SemVer can be useful when you develop software that uses external dependencies (which you almost always do). One day, your understanding of these numbers will save you from accidentally introducing breaking changes to your project without understanding why things that worked yesterday suddenly don’t work today. This is how Semantic Versioning works according to the official website:
-"package": "MAJOR.MINOR.PATCH"
+
+```json
+"package": "MAJOR.MINOR.PATCH"
+```
+
The MAJOR version should increment when you make incompatible API changes.
The MINOR version should increment when you add functionality in a backwards-compatible manner.
The PATCH version should increment when you make backwards-compatible bug fixes.
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-caret-character-to-use-the-latest-minor-version-of-a-dependency.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-caret-character-to-use-the-latest-minor-version-of-a-dependency.english.md
index 4457a53f58..d5a918bdb9 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-caret-character-to-use-the-latest-minor-version-of-a-dependency.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-caret-character-to-use-the-latest-minor-version-of-a-dependency.english.md
@@ -8,7 +8,11 @@ challengeType: 2
Similar to how the tilde we learned about in the last challenge allows npm to install the latest PATCH for a dependency, the caret (^) allows npm to install future updates as well. The difference is that the caret will allow both MINOR updates and PATCHes.
Your current version of moment should be "~2.10.2" which allows npm to install to the latest 2.10.x version. If you were to use the caret (^) as a version prefix instead, npm would be allowed to update to any 2.x.x version.
-"package": "^1.3.8"
+
+```json
+"package": "^1.3.8"
+```
+
This would allow updates to any 1.x.x version of the package.
diff --git a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-tilde-character-to-always-use-the-latest-patch-version-of-a-dependency.english.md b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-tilde-character-to-always-use-the-latest-patch-version-of-a-dependency.english.md
index e9c059be8c..f5fa6fd7f7 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-tilde-character-to-always-use-the-latest-patch-version-of-a-dependency.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/managing-packages-with-npm/use-the-tilde-character-to-always-use-the-latest-patch-version-of-a-dependency.english.md
@@ -8,7 +8,11 @@ challengeType: 2
In the last challenge, you told npm to only include a specific version of a package. That’s a useful way to freeze your dependencies if you need to make sure that different parts of your project stay compatible with each other. But in most use cases, you don’t want to miss bug fixes since they often include important security patches and (hopefully) don’t break things in doing so.
To allow an npm dependency to update to the latest PATCH version, you can prefix the dependency’s version with the tilde (~) character. Here's an example of how to allow updates to any 1.3.x version.
-"package": "~1.3.8"
+
+```json
+"package": "~1.3.8"
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-a-model.english.md b/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-a-model.english.md
index 2f1ae255f7..1e15dc83a3 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-a-model.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-a-model.english.md
@@ -14,14 +14,17 @@ A model allows you to create instances of your objects, called documents.
Glitch is a real server, and in real servers the interactions with the db happen in handler functions. These function are executed when some event happens (e.g. someone hits an endpoint on your API). We’ll follow the same approach in these exercises. The done() function is a callback that tells us that we can proceed after completing an asynchronous operation such as inserting, searching, updating or deleting. It’s following the Node convention and should be called as done(null, data) on success, or done(err) on error.
Warning - When interacting with remote services, errors may occur!
-
-/* Example */
-var someFunc = function(done) {
- //... do something (risky) ...
- if(error) return done(error);
- done(null, result);
+
+```js
+/* Example */
+
+var someFunc = function(done) {
+ //... do something (risky) ...
+ if(error) return done(error);
+ done(null, result);
};
-
+```
+
## Instructions
diff --git a/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-and-save-a-record-of-a-model.english.md b/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-and-save-a-record-of-a-model.english.md
index fd9fb7145d..88c680da18 100644
--- a/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-and-save-a-record-of-a-model.english.md
+++ b/curriculum/challenges/english/05-apis-and-microservices/mongodb-and-mongoose/create-and-save-a-record-of-a-model.english.md
@@ -12,13 +12,16 @@ In this challenge you will have to create and save a record of a model.
## Instructions
Create a document instance using the Person constructor you built before. Pass to the constructor an object having the fields name, age, and favoriteFoods. Their types must conform to the ones in the Person Schema. Then call the method document.save() on the returned document instance. Pass to it a callback using the Node convention. This is a common pattern, all the following CRUD methods take a callback function like this as the last argument.
-
-/* Example */
-// ...
-person.save(function(err, data) {
- // ...do your stuff here...
+
+```js
+/* Example */
+
+// ...
+person.save(function(err, data) {
+ // ...do your stuff here...
});
-
+```
+
## Tests