Lab 3.1 - Deliver Data from a Library API

canelacho

First, the assert equal is deprecated.

When I processed the data.js file, I got a string, but the assert test compare against an object.

I did check the type of the values and they were different so, I checked the values and they were the same in “content” and “data”. To get the assert ok y convert to an object or test other assertions and it worked.

Adding this to compare:
${HOST} must respond with result calling data lib function - ${content} && ${data} ${content == data} /=/ ${typeof(content)}, ${typeof(data)}

results:
⛔️ http://localhost:3000 must respond with result calling data lib function - kbo7Nfn1ii12kQ== && kbo7Nfn1ii12kQ== true
➜ Lab-3.1 node validate.js
⛔️ http://localhost:3000 must respond with result calling data lib function - EJcq50G8foy5og== && EJcq50G8foy5og== true
➜ Lab-3.1 node validate.js
⛔️ http://localhost:3000 must respond with result calling data lib function - IN/yrkDdzbKZjw== && IN/yrkDdzbKZjw== true
➜ Lab-3.1 node validate.js
☑️ GET http://localhost:3000/ responded with data output
☑️ GET http://localhost:3000/example responded with 404 Not Found status

davidmarkclements

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

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?

tayuelo

@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

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.

tayuelo

@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.

chesterheng

I wanted too but skip for now to continue.
Should review each other answers?
If posting answer here is not allow, I can message you.

davidmarkclements

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

Hi @davidmarkclements,

My code as below. Please help me to review. Thank you.

index.js
const express = require('express');
const router = express.Router();
const data = require('../data');

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

module.exports = router;

app.js
'use strict'
const express = require('express');
const createError = require('http-errors');
const indexRouter = require('./routes/index');

const port = process.env.PORT || 3000;

const app = express();

app.use('/', indexRouter);

// catch 404 and forward to error handler
app.use(function(req, res, next) {
next(createError(404));
});

app.use((err, req, res, next) => {
res.status(err.status || 500);
res.send(err.message);
});

app.listen(port);

davidmarkclements

@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.

chesterheng

Hi @davidmarkclements,

Thank you for review my code.

I still cannot validate lab3-1.
⛔️ http://localhost:3000 must respond with result calling data lib function

davidmarkclements

your code seems to work:

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

gsiqueira

@davidmarkclements you can post the code from the validate.js file?

ewertonazevedo

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

Hello everyone ... I think the common mistake is.. you have to make sure the server is not already running..

as you can see on line 28 the validate script is starting the server and intercepting the crypto import with a fake

davidmarkclements

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

coolercoder

To summarize issue "⛔️ http://localhost:3000 must respond with result calling data lib function"

1. add blow script to you package.json (app.js is your service entry point)
   "scripts": {
   "start": "node app.js"
   },

2. when you run "node validate.js" , there is a magic inside call "npm start" and DO NOT call "npm start" separately by your self.

dilipagheda

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!

jalik26

@dilipagheda Exactly, we may all had this issue for this particular reason:
We followed the courses, thus there is a lot of chance that we still have a running instance of the previous server or we have created another server based on previous courses (copy-paste-edit to save time).

Having the validation in its own folder and the server in another folder, the random bytes injection is not doing what the author of the course wanted to.

Please fix this or improve documentation as this is very frustrating, the injection hack is breaking the validation while the code is 100% valid.

xdxmxc

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.

jalik26

@xdxmxc dear author of the course, the problem is not zombie servers, the problem is that the validation code is relying on a hack that makes the validation fail leaving the student thinking his code is garbage while it's 100% good.

For example, if I write the required code and launch it using my own run command and then start the validation in parallel, it fails because the random value is not shared between the app and the validation script.

A better solution would be that the validation script write to a file that is then read and returned by the app, thus passing (or not) the validation if the content is the same.

Thanks for your understanding, I had exactly this problem, I knew my code was good, but I dug and found the why, now I can just go on, but I felt it would be useful to let others know why it could not work as expected, and maybe make you change that.

xdxmxc

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

Tips from someone just starting the course. For your validation to run successfully, make sure your package.json start script points to the correct file (whatever file contains your main logic). validate.js will run it's own npm start. So make sure your server is killed to avoid port conflicts.

Next I was surprised to learn that Express does not support async/await as I see a lot of that type of code around. AFAIU a better approach is a traditional callback style:

app.get( '/', ( req, res ) => {
    data()
        .then( ( result ) => {
            res.send( result )
        } )
        .catch( ( err ) => {
            res.status( 500 ).send( 'Internal Server Error' );
        } )
} )

xdxmxc

@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