feat: add 'back/front end' in curriculum (#42596)

* chore: rename APIs and Microservices to include "Backend" (#42515)

* fix typo

* fix typo

* undo change

* Corrected grammar mistake

Corrected a grammar mistake by removing a comma.

* change APIs and Microservices cert title

* update title

* Change APIs and Microservices certi title

* Update translations.json

* update title

* feat(curriculum): rename apis and microservices cert

* rename folder structure

* rename certificate

* rename learn Markdown

* apis-and-microservices -> back-end-development-and-apis

* update backend meta

* update i18n langs and cypress test

Co-authored-by: Shaun Hamilton <shauhami020@gmail.com>

* fix: add development to front-end libraries (#42512)

* fix: added-the-word-Development-to-front-end-libraries

* fix/added-the-word-Development-to-front-end-libraries

* fix/added-word-development-to-front-end-libraries-in-other-related-files

* fix/added-the-word-Development-to-front-end-and-all-related-files

* fix/removed-typos-from-last-commit-in-index.md

* fix/reverted-changes-that-i-made-to-dependecies

* fix/removed xvfg

* fix/reverted changes that i made to package.json

* remove unwanted changes

* front-end-development-libraries changes

* rename backend certSlug and README

* update i18n folder names and keys

* test: add legacy path redirect tests

This uses serve.json from the client-config repo, since we currently use
that in production

* fix: create public dir before moving serve.json

* fix: add missing script

* refactor: collect redirect tests

* test: convert to cy.location for stricter tests

* rename certificate folder to 00-certificates

* change crowdin config to recognise new certificates location

* allow translations to be used

Co-authored-by: Nicholas Carrigan (he/him) <nhcarrigan@gmail.com>

* add forwards slashes to path redirects

* fix cypress path tests again

* plese cypress

* fix: test different challenge

Okay so I literally have no idea why this one particular challenge
fails in Cypress Firefox ONLY. Tom and I paired and spun a full build
instance and confirmed in Firefox the page loads and redirects as
expected. Changing to another bootstrap challenge passes Cypress firefox
locally. Absolutely boggled by this.

AAAAAAAAAAAAAAA

* fix: separate the test

Okay apparently the test does not work unless we separate it into
a different `it` statement.

>:( >:( >:( >:(

Co-authored-by: Sujal Gupta <55016909+heysujal@users.noreply.github.com>
Co-authored-by: Noor Fakhry <65724923+NoorFakhry@users.noreply.github.com>
Co-authored-by: Oliver Eyton-Williams <ojeytonwilliams@gmail.com>
Co-authored-by: Nicholas Carrigan (he/him) <nhcarrigan@gmail.com>
This commit is contained in:
Shaun Hamilton
2021-08-14 03:57:13 +01:00
committed by GitHub
parent 4df2a0c542
commit c2a11ad00d
1215 changed files with 790 additions and 449 deletions

View File

@ -0,0 +1,79 @@
---
id: 587d7fb1367417b2b2512bf4
title: Concatenare il middleware per creare un Time Server
challengeType: 2
forumTopicId: 301510
dashedName: chain-middleware-to-create-a-time-server
---
# --description--
Il middleware può essere montato su un percorso specifico utilizzando `app.METHOD(path, middlewareFunction)`. Il middleware può anche essere concatenato all'interno della definizione del percorso.
Guarda l'esempio seguente:
```js
app.get('/user', function(req, res, next) {
req.user = getTheUserSync(); // Hypothetical synchronous operation
next();
}, function(req, res) {
res.send(req.user);
});
```
Questo approccio è utile per dividere le operazioni server in unità più piccole. Questo porta a una migliore struttura delle app, e alla possibilità di riutilizzare il codice in luoghi diversi. Questo approccio può essere utilizzato anche per eseguire una qualche convalida sui dati. In ogni punto dello stack middleware è possibile bloccare l'esecuzione della catena corrente e passare il controllo a funzioni specificamente progettate per gestire gli errori. Oppure è possibile passare il controllo alla prossima rotta corrispondente, per gestire casi speciali. Vedremo come nella sezione Express avanzata.
# --instructions--
Nel percorso `app.get('/now', ...)` concatena una funzione middleware e il gestore finale. Nella funzione middleware dovresti aggiungere l'ora corrente all'oggetto della richiesta nella chiave `req.time`. Puoi utilizzare `new Date().toString()`. Nel gestore, rispondi con un oggetto JSON, utilizzando la struttura `{time: req.time}`.
**Nota:** Il test non sarà superato se non concatenerai il middleware. Se monti la funzione altrove, il test fallirà, anche se il risultato dell'uscita sarà corretto.
# --hints--
L'endpoint /now dovrebbe avere il middleware montato
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/chain-middleware-time').then(
(data) => {
assert.equal(
data.stackLength,
2,
'"/now" route has no mounted middleware'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
L'endpoint /now dovrebbe restituire un tempo che è di +/- 20 secondi da ora
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/chain-middleware-time').then(
(data) => {
var now = new Date();
assert.isAtMost(
Math.abs(new Date(data.time) - now),
20000,
'the returned time is not between +- 20 secs from now'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,78 @@
---
id: 587d7fb2367417b2b2512bf8
title: Ottenere dati dalle richieste POST
challengeType: 2
forumTopicId: 301511
dashedName: get-data-from-post-requests
---
# --description--
Monta un gestore POST sul percorso `/name`. È lo stesso percorso di prima. Abbiamo preparato un modulo nella pagina html principale. Invierà gli stessi dati dell'esercizio 10 (stringa di ricerca). Se il body parser è configurato correttamente, dovresti trovare i parametri nell'oggetto `req.body`. Dai un'occhiata al solito esempio della biblioteca:
<blockquote>route: POST '/library'<br>urlencoded_body: userId=546&#x26;bookId=6754 <br>req.body: {userId: '546', bookId: '6754'}</blockquote>
Rispondi con lo stesso oggetto JSON di prima: `{name: 'firstname lastname'}`. Verifica se il tuo endpoint funziona utilizzando il modulo html che abbiamo fornito nella pagina principale dell'app.
Suggerimento: ci sono diversi altri metodi http diversi da GET e POST. E per convenzione c'è una corrispondenza tra il verbo http, e l'operazione che si sta per eseguire sul server. La mappatura convenzionale è:
POST (talvolta PUT) - Crea una nuova risorsa utilizzando le informazioni inviate con la richiesta,
GET - Leggi una risorsa esistente senza modificarla,
PUT o PATCH (a volte POST) - Aggiorna una risorsa utilizzando i dati inviati,
DELETE => Elimina una risorsa.
Ci sono anche un paio di altri metodi che vengono utilizzati per negoziare una connessione con il server. Tranne che da GET, tutti gli altri metodi sopra elencati possono avere un carico utile (cioè i dati nel corpo della richiesta). Il middleware body-parser funziona anche con questi metodi.
# --hints--
Test 1: Il tuo endpoint API dovrebbe rispondere con il nome corretto
```js
(getUserInput) =>
$.post(getUserInput('url') + '/name', { first: 'Mick', last: 'Jagger' }).then(
(data) => {
assert.equal(
data.name,
'Mick Jagger',
'Test 1: "POST /name" route does not behave as expected'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
Test 2: Il tuo endpoint API dovrebbe rispondere con il nome corretto
```js
(getUserInput) =>
$.post(getUserInput('url') + '/name', {
first: 'Keith',
last: 'Richards'
}).then(
(data) => {
assert.equal(
data.name,
'Keith Richards',
'Test 2: "POST /name" route does not behave as expected'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,67 @@
---
id: 587d7fb2367417b2b2512bf6
title: Ottenere l'input del parametro query dal client
challengeType: 2
forumTopicId: 301512
dashedName: get-query-parameter-input-from-the-client
---
# --description--
Un altro modo comune per ottenere input dal client è codificare i dati dopo il percorso della rotta, utilizzando una stringa di interrogazione (query). La stringa di query è delimitata da un punto interrogativo (?), e include le coppie campo=valore. Ogni coppia è separata da un simbolo &. Express può analizzare i dati dalla stringa di query e popolare l'oggetto `req.query`. Alcuni caratteri, come la percentuale (%), non possono essere presenti negli URL e devono essere codificati in un formato diverso prima di poterli inviare. Se accedi all'API da JavaScript, puoi usare metodi specifici per codificare/decodificare questi caratteri.
<blockquote>route_path: '/library'<br>actual_request_URL: '/library?userId=546&#x26;bookId=6754' <br>req.query: {userId: '546', bookId: '6754'}</blockquote>
# --instructions--
Costruisci un endpoint API, montato su `GET /name`. Rispondi con un documento JSON, usando la struttura `{ name: 'firstname lastname'}`. I parametri del nome e del cognome devono essere codificati in una stringa di query, ad esempio `?first=firstname&last=lastname`.
**Nota:** Nel seguente esercizio riceverai i dati da una richiesta POST, allo stesso percorso `/name`. Se vuoi, puoi usare il metodo `app.route(path).get(handler).post(handler)`. Questa sintassi consente di concatenare diversi gestori di verbi sullo stesso percorso. Puoi risparmiare un po' di digitazione, e avere un codice più pulito.
# --hints--
Test 1: Il tuo endpoint API dovrebbe rispondere con il nome corretto
```js
(getUserInput) =>
$.get(getUserInput('url') + '/name?first=Mick&last=Jagger').then(
(data) => {
assert.equal(
data.name,
'Mick Jagger',
'Test 1: "GET /name" route does not behave as expected'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
Test 2: Il tuo endpoint API dovrebbe rispondere con il nome corretto
```js
(getUserInput) =>
$.get(getUserInput('url') + '/name?last=Richards&first=Keith').then(
(data) => {
assert.equal(
data.name,
'Keith Richards',
'Test 2: "GET /name" route does not behave as expected'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,65 @@
---
id: 587d7fb2367417b2b2512bf5
title: Ottenere l'input del parametro della rotta dal client
challengeType: 2
forumTopicId: 301513
dashedName: get-route-parameter-input-from-the-client
---
# --description--
Quando costruiamo un'API, dobbiamo consentire agli utenti di comunicarci cosa vogliono ottenere dal nostro servizio. Ad esempio, se il client richiede informazioni su un utente memorizzato nel database, hanno bisogno di un modo per farci sapere a quale utente sono interessati. Un modo possibile per raggiungere questo risultato è utilizzare i parametri della rotta. I parametri della rotta sono denominati segmenti dell'URL, e sono delimitati da slash (/). Ogni segmento cattura il valore della parte dell'URL che corrisponde alla sua posizione. I valori acquisiti possono essere trovati nell'oggetto `req.params`.
<blockquote>route_path: '/user/:userId/book/:bookId'<br>actual_request_URL: '/user/546/book/6754' <br>req.params: {userId: '546', bookId: '6754'}</blockquote>
# --instructions--
Costruisci un server echo, montato sul percorso `GET /:word/echo`. Rispondi con un oggetto JSON, usando la struttura `{echo: word}`. Puoi trovare la parola da ripetere in `req.params.word`. Puoi testare il percorso dalla barra degli indirizzi del tuo browser, visitando alcuni percorsi corrispondenti, ad esempio `your-app-rootpath/freecodecamp/echo`.
# --hints--
Test 1: il tuo server echo dovrebbe ripetere correttamente le parole
```js
(getUserInput) =>
$.get(getUserInput('url') + '/eChOtEsT/echo').then(
(data) => {
assert.equal(
data.echo,
'eChOtEsT',
'Test 1: the echo server is not working as expected'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
Test 2: il tuo server echo dovrebbe ripetere correttamente le parole
```js
(getUserInput) =>
$.get(getUserInput('url') + '/ech0-t3st/echo').then(
(data) => {
assert.equal(
data.echo,
'ech0-t3st',
'Test 2: the echo server is not working as expected'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,57 @@
---
id: 587d7fb1367417b2b2512bf3
title: Implementare un middleware logger di richiesta a livello radice
challengeType: 2
forumTopicId: 301514
dashedName: implement-a-root-level-request-logger-middleware
---
# --description--
In precedenza, sei stato introdotto alla funzione middleware `express.static()`. Ora è il momento di vedere cosa è un middleware in modo più dettagliato. Le funzioni middleware sono funzioni che richiedono 3 argomenti: l'oggetto richiesta (request), l'oggetto risposta (response) e la funzione successiva (next) nel ciclo richiesta-risposta dell'applicazione. Queste funzioni eseguono del codice che può avere effetti collaterali sull'app, e di solito aggiungono informazioni alla richiesta o agli oggetti di risposta. Possono anche terminare il ciclo inviando una risposta quando è soddisfatta una certa condizione. Se non inviano la risposta quando hanno finito, iniziano l'esecuzione della funzione successiva nello stack. Questo innesca la chiamata del terzo argomento, `next()`.
Considera l'esempio seguente:
```js
function(req, res, next) {
console.log("I'm a middleware...");
next();
}
```
Supponiamo che tu abbia montato questa funzione su una rotta. Quando una richiesta corrisponde alla rotta, mostrerà la stringa “Im a middleware…”, dopodiché eseguirà la funzione successiva nello stack. In questo esercizio, costruirai un middleware a livello di radice. Come hai visto nella sfida 4, per montare una funzione middleware a livello di radice, puoi usare il metodo `app.use(<mware-function>)`. In questo caso, la funzione verrà eseguita per tutte le richieste, ma è anche possibile impostare condizioni più specifiche. Ad esempio, se desideri che una funzione venga eseguita solo per le richieste POST, puoi utilizzare `app.post(<mware-function>)`. Esistono metodi analoghi per tutti i verbi HTTP (GET, DELETE, PUT, …).
# --instructions--
Costruisci un semplice logger. Per ogni richiesta, esso dovrebbe scrivere nella console una stringa con il seguente formato: `method path - ip`. L'output dovrebbe assomigliare a questo: `GET /json - ::ffff:127.0.0.1`. Nota che c'è uno spazio tra `method` e `path` e che il trattino che separa `path` e `ip` è circondato da uno spazio su entrambi i lati. Puoi ottenere il metodo di richiesta (il verbo http), il percorso relativo e l'ip del chiamante dall'oggetto request utilizzando `req.method`, `req.path` e `req.ip`. Ricordati di chiamare `next()` quando hai finito, o il tuo server rimarrà bloccato per sempre. Assicurati di avere il 'Logs' aperto, e guarda cosa succede quando arriva qualche richiesta.
**Nota:** Express valuta le funzioni nell'ordine in cui appaiono nel codice. Questo vale anche per i middleware. Se vuoi che funzioni per tutte le rotte, dovresti montarlo prima di loro.
# --hints--
Il middleware del logger di livello radice dovrebbe essere attivo
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/root-middleware-logger').then(
(data) => {
assert.isTrue(
data.passed,
'root-level logger is not working as expected'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,53 @@
---
id: 587d7fb0367417b2b2512bed
title: Introduzione alla console di Node
challengeType: 2
forumTopicId: 301515
dashedName: meet-the-node-console
---
# --description--
Lavorare su queste sfide ti porterà a scrivere il tuo codice utilizzando uno dei seguenti metodi:
- Clonare [questo repository GitHub](https://github.com/freeCodeCamp/boilerplate-express/) e completare queste sfide localmente.
- Usare [la nostra bozza di progetto su Replit](https://replit.com/github/freeCodeCamp/boilerplate-express) per completare queste sfide.
- Usa un costruttore di siti di tua scelta per completare il progetto. Assicurati di incorporare tutti i file della nostra repository GitHub.
Quando hai finito, assicurati che una demo funzionante del tuo progetto sia ospitata da qualche parte di pubblico. Quindi invia l'URL nel campo `Solution Link`.
Durante il processo di sviluppo, è importante essere in grado di controllare cosa sta succedendo nel tuo codice.
Node è solo un ambiente JavaScript. Come per il JavaScript lato client, puoi usare la console per visualizzare utili informazioni di debug. Sulla tua macchina locale, vedrai l'output della console in un terminale. Su Replit, un terminale è aperto nel riquadro destro per impostazione predefinita.
Ti consigliamo di mantenere il terminale aperto mentre lavori a a queste sfide. Leggendo l'output nel terminale, potrai vedere eventuali errori.
# --instructions--
Modifica il file `myApp.js` per scrivere "Hello World" nella console.
# --hints--
`"Hello World"` dovrebbe essere visualizzato nella console
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/hello-console').then(
(data) => {
assert.isTrue(data.passed, '"Hello World" is not in the server console');
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,51 @@
---
id: 587d7fb0367417b2b2512bef
title: Servire un file HTML
challengeType: 2
forumTopicId: 301516
dashedName: serve-an-html-file
---
# --description--
È possibile rispondere alle richieste con un file utilizzando il metodo `res.sendFile(path)`. Puoi inserirlo all'interno del gestore della rotta `app.get('/', ...)`. Dietro le quinte, questo metodo imposterà le intestazioni appropriate per istruire il browser su come gestire il file che si desidera inviare, in base al suo tipo. Quindi leggerà e invierà il file. Questo metodo necessita di un percorso di file assoluto. Ti consigliamo di utilizzare la variabile globale Node `__dirname` per calcolare il percorso in questo modo:
```js
absolutePath = __dirname + relativePath/file.ext
```
# --instructions--
Invia il file `/views/index.html` come risposta alle richieste GET al percorso `/`. Guardando la tua app live, dovresti vedere una grossa intestazione HTML (e un modulo, che useremo successivamente...) senza alcuno stile applicato.
**Nota:** Puoi modificare la soluzione della sfida precedente o crearne una nuova. Se crei una nuova soluzione, tieni presente che Express valuta i percorsi dall'alto verso il basso ed esegue il gestore alla prima corrispondenza. Dovrai commentare la soluzione precedente, o il server continuerà a rispondere con una stringa.
# --hints--
La tua app dovrebbe servire il file views/index.html
```js
(getUserInput) =>
$.get(getUserInput('url')).then(
(data) => {
assert.match(
data,
/<h1>.*<\/h1>/,
'Your app does not serve the expected HTML'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,47 @@
---
id: 587d7fb1367417b2b2512bf1
title: Servire un JSON su una rotta specifica
challengeType: 2
forumTopicId: 301517
dashedName: serve-json-on-a-specific-route
---
# --description--
Mentre un server HTML serve HTML, un'API serve dati. Un'API <dfn>REST</dfn> (REpresentational State Transfer) consente lo scambio di dati in modo semplice, senza la necessità per i client di conoscere alcun dettaglio sul server. Il client deve solo sapere dove è la risorsa (l'URL), e l'azione che vuole eseguire su di essa (il verbo). Il verbo GET viene utilizzato quando stai recuperando alcune informazioni, senza modificare nulla. Al giorno d'oggi, il formato dati preferito per trasferire informazioni sul Web è JSON. In poche parole, JSON è un modo conveniente per rappresentare un oggetto JavaScript come una stringa, in modo che possa essere facilmente trasmesso.
Creiamo una semplice API creando una rotta (route) che risponda con JSON al percorso `/json`. Puoi farlo come al solito, con il metodo `app.get()`. All'interno del gestore della rotta, usa il metodo `res.json()`, passandogli un oggetto come argomento. Questo metodo chiude il ciclo richiesta-risposta, restituendo i dati. Dietro le quinte, converte un oggetto JavaScript valido in una stringa, poi imposta le intestazioni appropriate per dire al tuo browser che stai servendo JSON, e restituisce i dati. Un oggetto valido ha la solita struttura `{key: data}`. `data` può essere un numero, una stringa, un oggetto annidato o un array. `data` può anche essere una variabile o il risultato di una chiamata di funzione, nel qual caso sarà valutato prima di essere convertito in una stringa.
# --instructions--
Servi l'oggetto `{"message": "Hello json"}` come risposta, in formato JSON, alle richieste GET per il percorso `/json`. Quindi punta il tuo browser a `your-app-url/json`, dovresti vedere il messaggio sullo schermo.
# --hints--
L'endpoint `/json` dovrebbe servire l'oggetto json `{"message": "Hello json"}`
```js
(getUserInput) =>
$.get(getUserInput('url') + '/json').then(
(data) => {
assert.equal(
data.message,
'Hello json',
"The '/json' endpoint does not serve the right data"
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,51 @@
---
id: 587d7fb0367417b2b2512bf0
title: Servire Risorse Statiche
challengeType: 2
forumTopicId: 301518
dashedName: serve-static-assets
---
# --description--
Un server HTML di solito ha una o più directory che sono accessibili all'utente. È possibile posizionare lì le risorse statiche necessarie per l'applicazione (fogli di stile, script, immagini).
In Express, puoi mettere in atto questa funzionalità usando il middleware `express.static(path)`, dove il parametro `path` è il percorso assoluto della cartella contenente le risorse.
Se non sai cosa è un middleware... non ti preoccupare, ne discuteremo in dettaglio più tardi. Fondamentalmente, i middleware sono funzioni che intercettano i gestori delle rotte, aggiungendo un certo tipo di informazioni. Un middleware deve essere montato usando il metodo `app.use(path, middlewareFunction)`. Il primo argomento `path` è facoltativo. Se non viene passato, il middleware verrà eseguito per tutte le richieste.
# --instructions--
Monta il middleware `express.static()` sul percorso `/public` con `app.use()`. Il percorso assoluto della cartella asset è `__dirname + /public`.
Ora la tua app dovrebbe essere in grado di servire un foglio di stile CSS. Nota che il file `/public/style.css` è referenziato nel `/views/index.html` nel codice standard. Adesso la tua pagina principale dovrebbe avere un aspetto un po' migliore!
# --hints--
La tua app dovrebbe servire i file di risorsa dalla directory `/public` al percorso `/public`
```js
(getUserInput) =>
$.get(getUserInput('url') + '/public/style.css').then(
(data) => {
assert.match(
data,
/body\s*\{[^\}]*\}/,
'Your app does not serve static assets'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,57 @@
---
id: 587d7fb0367417b2b2512bee
title: Avviare un server Express funzionante
challengeType: 2
forumTopicId: 301519
dashedName: start-a-working-express-server
---
# --description--
Nelle prime due righe del file `myApp.js` puoi vedere quanto sia facile creare un oggetto app Express. Questo oggetto ha diversi metodi, che conoscerai in queste sfide. Un metodo fondamentale è `app.listen(port)`. Dice al tuo server di mettersi in ascolto su una data porta, mettendola in uno stato attivo. Per motivi di test, abbiamo bisogno che l'app sia in esecuzione in background per cui abbiamo aggiunto questo metodo nel file `server.js` per te.
Serviamo la nostra prima stringa! In Express, le rotte hanno la seguente struttura: `app.METHOD(PATH, HANDLER)`. METHOD è un metodo http in minuscolo. PATH è un percorso relativo sul server (può essere una stringa, o anche un'espressione regolare). HANDLER è una funzione che Express chiama quando la rotta corrisponde. I gestori assumono la forma `function(req, res) {...}`, dove req è l'oggetto request (richiesta), e res è l'oggetto response (risposta). Ad esempio, il gestore
```js
function(req, res) {
res.send('Response String');
}
```
servirà la stringa 'Response String'.
# --instructions--
Utilizza il metodo `app.get()` per servire la stringa "Hello Express" alle richieste GET corrispondenti al percorso `/` (root). Assicurati che il codice funzioni guardando i log, quindi guarda i risultati nell'anteprima se utilizzi Replit.
**Nota:** Tutto il codice per queste lezioni dovrebbe essere aggiunto tra le poche righe di codice di partenza.
# --hints--
La tua app dovrebbe servire la stringa 'Hello Express'
```js
(getUserInput) =>
$.get(getUserInput('url')).then(
(data) => {
assert.equal(
data,
'Hello Express',
'Your app does not serve the text "Hello Express"'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,63 @@
---
id: 587d7fb2367417b2b2512bf7
title: Usare il body parser per analizzare le richieste POST
challengeType: 2
forumTopicId: 301520
dashedName: use-body-parser-to-parse-post-requests
---
# --description--
Oltre a GET, c'è un altro verbo HTTP di uso comune, che è POST. POST è il metodo predefinito utilizzato per inviare dati dal client attraverso i moduli HTML. Nella convenzione REST, POST viene utilizzato per inviare dati che creeranno nuovi elementi nel database (un nuovo utente, o un nuovo post del blog). Non hai un database in questo progetto, ma imparerai comunque a gestire le richieste POST.
In questo tipo di richieste, i dati non appaiono nell'URL, sono nascosti nel corpo della richiesta. Il corpo fa parte della richiesta HTTP, chiamata anche payload (carico utile). Anche se i dati non sono visibili nell'URL, ciò non significa che siano privati. Per vedere perché, guarda il contenuto grezzo di una richiesta HTTP POST:
```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
```
Come puoi vedere, il corpo è codificato come la query string. Questo è il formato predefinito usato dai moduli HTML. Con Ajax, è anche possibile utilizzare JSON per gestire dati che hanno una struttura più complessa. C'è anche un altro tipo di codifica: multipart/form-data. Questo viene utilizzato per caricare file binari. In questo esercizio, utilizzerai un corpo urlencoded. Per analizzare i dati provenienti dalle richieste POST, dovrai installare il pacchetto `body-parser`. Questo pacchetto consente di utilizzare una serie di middleware, che possono decodificare i dati in diversi formati.
# --instructions--
Installa il modulo `body-parser` nel tuo `package.json`. Poi, richiedilo con `require` all'inizio del file. Memorizzalo in una variabile chiamata `bodyParser`. Il middleware per gestire i dati urlencoded viene restituito da `bodyParser.urlencoded({extended: false})`. Passa ad `app.use()` la funzione restituita dal metodo invocato prima. Come al solito, il middleware deve essere montato prima di tutte le rotte che dipendono da esso.
**Nota:** `extended` è un'opzione di configurazione che dice al `body-parser` quale analisi deve essere utilizzata. Quando `extended=false` viene utilizzata la libreria di codifica classica `querystring`. Quando `extended=true` viene usata per il parsing la libreria `qs`.
Quando si utilizza `extended=false`, i valori possono essere solo stringhe o array. L'oggetto restituito quando si utilizza `querystring` non eredita prototipalmente da `Object`, predefinito in JavaScript, quindi funzioni come `hasOwnProperty` e `toString` non saranno disponibili. La versione estesa consente una maggiore flessibilità dei dati, ma è superata da JSON.
# --hints--
Il middleware 'body-parser' dovrebbe essere montato
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/add-body-parser').then(
(data) => {
assert.isAbove(
data.mountedAt,
0,
'"body-parser" is not mounted correctly'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,52 @@
---
id: 587d7fb1367417b2b2512bf2
title: Usare il file .env
challengeType: 2
forumTopicId: 301521
dashedName: use-the--env-file
---
# --description--
Il file `.env` è un file nascosto che viene utilizzato per passare le variabili d'ambiente alla tua applicazione. Questo file è segreto, nessuno tranne te può accedervi, e può essere utilizzato per memorizzare i dati che desideri mantenere privati o nascosti. Ad esempio, puoi memorizzare le chiavi API di servizi esterni o l'URI del database. Puoi anche usarlo per memorizzare le opzioni di configurazione. Impostando le opzioni di configurazione, puoi modificare il comportamento della tua applicazione, senza la necessità di riscrivere una parte di codice.
Le variabili di ambiente sono accessibili dall'app come `process.env.VAR_NAME`. L'oggetto `process.env` è un oggetto Node globale e le variabili sono passate come stringhe. Per convenzione, i nomi delle variabili sono tutti in maiuscolo, con parole separate da un trattino basso. `.env` è un file di shell, quindi non è necessario racchiudere i nomi o i valori tra virgolette. È anche importante notare che non ci possono essere degli spazi intorno al segno uguale quando si assegnano valori alle variabili, ad esempio `VAR_NAME=value`. Normalmente metterai ogni definizione di variabile in una riga separata.
# --instructions--
Aggiungiamo una variabile d'ambiente come opzione di configurazione.
Crea un file `.env` nella directory principale del tuo progetto e memorizza la variabile `MESSAGE_STYLE=uppercase` in esso.
Poi, nel gestore della rotta GET `/json` che hai creato nell'ultima sfida, trasforma il messaggio dell'oggetto di risposta in maiuscolo se `process.env.MESSAGE_STYLE` è uguale a `uppercase`. L'oggetto della risposta dovrebbe essere `{"message": "Hello json"}` o `{"message": "HELLO JSON"}`, a seconda del valore di `MESSAGE_STYLE`.
**Nota:** Se stai usando Replit, non puoi creare un file `.env`. Utilizza invece la scheda <dfn>SECRETS</dfn> integrata per aggiungere la variabile.
# --hints--
La risposta dell'endpoint `/json` dovrebbe cambiare in base alla variabile d'ambiente `MESSAGE_STYLE`
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/use-env-vars').then(
(data) => {
assert.isTrue(
data.passed,
'The response of "/json" does not change according to MESSAGE_STYLE'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```