fix(curriculum): Convert blockquote elements to triple backtick syntax for Apis And Microservices (#35996)
* fix: converted blockquotes * fix: revert to blockquote * fix: changed js to http Co-Authored-By: Oliver Eyton-Williams <ojeytonwilliams@gmail.com> * fix: reverted back to blockquote * fix: reverted back to blockquote * fix: reverted back to blockquote
This commit is contained in:
Randell Dawson
Tom
@ -8,14 +8,16 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
Middleware can be mounted at a specific route using <code>app.METHOD(path, middlewareFunction)</code>. Middleware can also be chained inside route definition.
|
||||
Look at the following example:
|
||||
<blockquote>
|
||||
app.get('/user', function(req, res, next) {<br>
|
||||
req.user = getTheUserSync(); // Hypothetical synchronous operation<br>
|
||||
next();<br>
|
||||
}, function(req, res) {<br>
|
||||
res.send(req.user);<br>
|
||||
|
||||
```js
|
||||
app.get('/user', function(req, res, next) {
|
||||
req.user = getTheUserSync(); // Hypothetical synchronous operation
|
||||
next();
|
||||
}, function(req, res) {
|
||||
res.send(req.user);
|
||||
});
|
||||
</blockquote>
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
</section>
|
||||
|
||||
@ -8,12 +8,14 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
Earlier, you were introduced to the <code>express.static()</code> 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, <code>next()</code>.
|
||||
Look at the following example:
|
||||
<blockquote>
|
||||
function(req, res, next) {<br>
|
||||
console.log("I'm a middleware...");<br>
|
||||
next();<br>
|
||||
|
||||
```js
|
||||
function(req, res, next) {
|
||||
console.log("I'm a middleware...");
|
||||
next();
|
||||
}
|
||||
</blockquote>
|
||||
```
|
||||
|
||||
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 <code>app.use(<mware-function>)</code> 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 <code>app.post(<mware-function>)</code>. Analogous methods exist for all the HTTP verbs (GET, DELETE, PUT, …).
|
||||
</section>
|
||||
|
||||
@ -7,7 +7,11 @@ challengeType: 2
|
||||
## Description
|
||||
<section id='description'>
|
||||
You can respond to requests with a file using the <code>res.sendFile(path)</code> method. You can put it inside the <code>app.get('/', ...)</code> 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 <code>__dirname</code> to calculate the path like this:
|
||||
<blockquote>absolutePath = __dirname + relativePath/file.ext</blockquote>
|
||||
|
||||
```js
|
||||
absolutePath = __dirname + relativePath/file.ext
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -9,10 +9,13 @@ challengeType: 2
|
||||
In the first two lines of the file <code>myApp.js</code>, 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 <code>app.listen(port)</code>. 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 <code>process.env.PORT</code>. Its value is <code>3000</code>.
|
||||
Let’s serve our first string! In Express, routes takes the following structure: <code>app.METHOD(PATH, HANDLER)</code>. 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 <code>function(req, res) {...}</code>, where req is the request object, and res is the response object. For example, the handler
|
||||
<blockquote>
|
||||
function(req, res) {<br>
|
||||
res.send('Response String');<br>
|
||||
}</blockquote>
|
||||
|
||||
```js
|
||||
function(req, res) {
|
||||
res.send('Response String');
|
||||
}
|
||||
```
|
||||
|
||||
will serve the string 'Response String'.
|
||||
</section>
|
||||
|
||||
|
||||
@ -8,7 +8,16 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
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:
|
||||
<blockquote>POST /path/subpath HTTP/1.0<br>From: john@example.com<br>User-Agent: someBrowser/1.0<br>Content-Type: application/x-www-form-urlencoded<br>Content-Length: 20<br>name=John+Doe&age=25</blockquote>
|
||||
|
||||
```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 <code>body-parser</code> package. This package allows you to use a series of middleware, which can decode data in different formats.
|
||||
</section>
|
||||
|
||||
@ -9,7 +9,11 @@ challengeType: 2
|
||||
The next part of a good package.json file is the <code>description</code> 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:
|
||||
<blockquote>"description": "A project that does something awesome",</blockquote>
|
||||
|
||||
```json
|
||||
"description": "A project that does something awesome",
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -8,7 +8,11 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
The <code>license</code> 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:
|
||||
<blockquote>"license": "MIT",</blockquote>
|
||||
|
||||
```json
|
||||
"license": "MIT",
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -7,7 +7,11 @@ challengeType: 2
|
||||
## Description
|
||||
<section id='description'>
|
||||
A <code>version</code> is one of the required fields of your package.json file. This field describes the current version of your project. Here's an example:
|
||||
<blockquote>"version": "1.2",</blockquote>
|
||||
|
||||
```json
|
||||
"version": "1.2",
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -7,7 +7,11 @@ challengeType: 2
|
||||
## Description
|
||||
<section id='description'>
|
||||
The <code>keywords</code> field is where you can describe your project using related keywords. Here's an example:
|
||||
<blockquote>"keywords": [ "descriptive", "related", "words" ],</blockquote>
|
||||
|
||||
```json
|
||||
"keywords": [ "descriptive", "related", "words" ],
|
||||
```
|
||||
|
||||
As you can see, this field is structured as an array of double-quoted strings.
|
||||
</section>
|
||||
|
||||
|
||||
@ -8,12 +8,15 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
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 <code>dependencies</code> section of your package.json file.
|
||||
In this section, packages your project requires are stored using the following format:
|
||||
<blockquote>
|
||||
"dependencies": {<br>
|
||||
"package-name": "version",</br>
|
||||
"express": "4.14.0"</br>
|
||||
}<br>
|
||||
</blockquote>
|
||||
|
||||
```json
|
||||
"dependencies": {
|
||||
"package-name": "version",
|
||||
"express": "4.14.0"
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -9,7 +9,11 @@ challengeType: 2
|
||||
The <code>package.json</code> 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 <code>author</code> 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.
|
||||
<blockquote>"author": "Jane Doe",</blockquote>
|
||||
|
||||
```json
|
||||
"author": "Jane Doe",
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -8,7 +8,11 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
<code>Versions</code> 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:
|
||||
<blockquote>"package": "MAJOR.MINOR.PATCH"</blockquote>
|
||||
|
||||
```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.
|
||||
|
||||
@ -8,7 +8,11 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
Similar to how the tilde we learned about in the last challenge allows npm to install the latest PATCH for a dependency, the caret (<code>^</code>) 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.
|
||||
<blockquote>"package": "^1.3.8"</blockquote>
|
||||
|
||||
```json
|
||||
"package": "^1.3.8"
|
||||
```
|
||||
|
||||
This would allow updates to any 1.x.x version of the package.
|
||||
</section>
|
||||
|
||||
|
||||
@ -8,7 +8,11 @@ challengeType: 2
|
||||
<section id='description'>
|
||||
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 (<code>~</code>) character. Here's an example of how to allow updates to any 1.3.x version.
|
||||
<blockquote>"package": "~1.3.8"</blockquote>
|
||||
|
||||
```json
|
||||
"package": "~1.3.8"
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -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 <code>done()</code> 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 <code>done(null, data)</code> on success, or <code>done(err)</code> on error.
|
||||
Warning - When interacting with remote services, errors may occur!
|
||||
<blockquote>
|
||||
/* Example */<br><br>
|
||||
var someFunc = function(done) {<br>
|
||||
//... do something (risky) ...<br>
|
||||
if(error) return done(error);<br>
|
||||
done(null, result);<br>
|
||||
|
||||
```js
|
||||
/* Example */
|
||||
|
||||
var someFunc = function(done) {
|
||||
//... do something (risky) ...
|
||||
if(error) return done(error);
|
||||
done(null, result);
|
||||
};
|
||||
</blockquote>
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Instructions
|
||||
|
||||
@ -12,13 +12,16 @@ In this challenge you will have to create and save a record of a model.
|
||||
## Instructions
|
||||
<section id='instructions'>
|
||||
Create a document instance using the <code>Person</code> constructor you built before. Pass to the constructor an object having the fields <code>name</code>, <code>age</code>, and <code>favoriteFoods</code>. Their types must conform to the ones in the Person Schema. Then call the method <code>document.save()</code> 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.
|
||||
<blockquote>
|
||||
/* Example */<br><br>
|
||||
// ...<br>
|
||||
person.save(function(err, data) {<br>
|
||||
// ...do your stuff here...<br>
|
||||
|
||||
```js
|
||||
/* Example */
|
||||
|
||||
// ...
|
||||
person.save(function(err, data) {
|
||||
// ...do your stuff here...
|
||||
});
|
||||
</blockquote>
|
||||
```
|
||||
|
||||
</section>
|
||||
|
||||
## Tests
|
||||
|
||||
Reference in New Issue
Block a user