Lab 3.1 - Deliver Data from a Library API

hey @canelacho

assert.equal is deprecated, assert.strict.equal is not, notice at the top of validate.js const assert = require('assert').strict

the assert is comparing against a buffer object, the bug is that content needs to be converted to a string. Thanks for letting us know!

@chesterheng said:
hey @davidmarkclements

Referring to Lab-3.1,

validate.js call randomBytes(10).toString('base64') to get data.
my server.js call randomBytes(10).toString('base64') seperately to get data.

How can both data be the same?

Same issue here.

@chesterheng said:
Hi @tayuelo I am not sure if I can post my code for lab-3.1 here for review.

Except Lab-3.1, I managed to validate all labs. At lab 8 now.

Wow, I really want to validate this lab, but I just don't know why are those strings different. Hope @davidmarkclements helps me with this asap.

To understand how the data can be the same, see line 23, 25, and 28 of validate.js

@tayuelo can you please post the code that you're unable to validate

@chesterheng your code should pass as long as you have setup the start script in the package.json correctly.

This is mentioned in the training but it's important to emphasize that the following is unsafe in Express:

router.get('/', async function(req, res, next) {
  res.send(await data());
});

Express has no concept of async functions or promises, this route handler will return a promise. If for any reason the promise returned from the data async function was to reject, this would in turn cause the route handler function to reject - but Express does not handle promises returned from route handler functions, and therefore does not handle the rejection.

By default this will cause an unhandled promise rejection, putting your service into an unknown state. It can also leads to memory leaks.

I would advise that you don't use async functions with Express, but if you do you should wrap a try/catch around the entire function body:

router.get('/', async function(req, res, next) {
  try {
    res.send(await data());
  } catch (err) {
    next(err)
  }
});

That way any rejections are propagated via Express and the error handling middleware.

your code seems to work:

did you perhaps modify the validate.js file at all?

I have the same problem and cannot understand why.
I only created an app.js file, and did not modify the validate.js
My package.json has the "node app.js" that starts the server.

const http = require('http');
const express = require('express');
const app = express();
const data = require('./data');
const port = 3000;;

const server = http.createServer(app);

app.use((req, res, next) => {
if (req.path !== '/') {
res.status(404).send('Not found');
}
next();
})

app.get('/', async(req, res) => {
try {
let response = await data();
res.send(response);
} catch (err) {
res.status(500).send(err);
}

});

server.listen(port, () => {
console.log(Server listening on port ${port});
});

The only message I get from validate.js is that "⛔️ http://localhost:3000 must respond with result calling data lib function"

If I open the address on the browser I do see that random string as response.
for example: /0NqLJLyWmD9Dg==

Did I miss something?

@aarongoshine well pointed out, the validate script runs the server for you in this case

I ran into the same issue and played around with validate.js then realised that validate.js is actually starting a server for us. so, i stopped the server already running and then all tests passed. YAY!

dealing with zombie servers is a common part of microservice development, the pragmatic outcome here is everyone who hits this develops operational understanding around process management and node servers/services and most who won't hit this problem already have that understanding. Ultimately that's a feature, not a bug, this is a frequently occurring scenario in Node.js development. However it could be made clearer, a note is being added to chapter 3 to this effect.

fair points @jalik26 - I don't know about anyone else but I still deal with imposter syndrome (thinking my work is garbage while it's 100% good) due to a missing piece of operational knowledge. At some point you have to understand the reasons for why this would fail, which imo is good learning. However there's obviously a lot of other concerns and there's has to be a balance of tensions, and this maybe leans too far in that direction. I'll be doing a full audit and update of the material and will strongly consider your points on this as I do so. Thank you

@louiswol94 OR you try/catch every async await function in express - you can even write a handy function to wrap it, something along the lines of:

function gaurd (fn) {
  return async (req, res, next) {
    try { await fn(req, res, next) } catch (err) { next(err) }
  }
}

then router.add('/some/path', gaurd(myRouteHandler)), same for middleware etc

but it can only take you so far, Fastify being built from ground up to support this means max possible performance and you don't even have to think about it (which is the assumption, but not the truth) with Express