Skip to content

NodeJS starter setup.#2

Open
RobusGauli wants to merge 24 commits intodevfrom
setup
Open

NodeJS starter setup.#2
RobusGauli wants to merge 24 commits intodevfrom
setup

Conversation

@RobusGauli
Copy link
Collaborator

Completed

  • Async store integration for request sensitive context propagation.
  • RequestID and namespace integration for logs.
  • Better transaction management for creating new resource via knex.
  • Pagination capability.
  • Removed error codes from Custom errors.
  • Return requestID for during response error.
  • Refactor on promise based statments block.

Need to be done:

  • Docker compose for mysql instead of postgresql.
  • Common utils (for object manipulation).

"api"
],
"private": true,
"author": "Saugat Acharya <mesaugat@gmail.com>",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can keep this. Instead, add your name too in a separate contributors list.

Comment on lines +20 to +28
if (tokenType !== 'Bearer' || !token) {
return {
ok: false,
};
}

return {
token,
};

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why different results in between cases? I think it could only be - token or null OR token or error.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, user of the API when we tend to return null, undefined, "" or throws have the tendency to check for the error like so:

if (!token){}

OR

 if (token === ""){}

OR

try{ // statements }catch(err){}

all of which are optional if user choose not to handle the error properly.

Agreed that return signature and method is a bit verbose here, however i think it forces dev to handle error explicitly. Allows dev to treat error as just another value.

Any thoughts? This is not the typical JS standard way of error handling however languages like go, rust follows the Tuple/Enum pattern.


if (tokenType !== 'Bearer' || !token) {
return {
ok: false,
Copy link
Member

@mesaugat mesaugat Apr 12, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some go-langish stuff here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make it straight. Either return null to signify empty value or throw an error to state the failure -- nothing in between.

const LOG_DIR = process.env.LOG_DIR || 'logs';
const LOG_LEVEL = process.env.LOG_LEVEL || 'info';

const isFileLogEnabled = process.env.ENABLE_FILE_LOG === 'TRUE';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make it consistent with other LOG_ env variables.

process.env.LOG_ENABLE_FILE_TRANSPORT

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mesaugat, its acts as a flag, may be maintain consistency over semantics? I think ENABLE_FILE_LOG_TRANSPORT is easier to reason?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd choose consistency because in the long run these variables will grow and it will be a mess.

It's for you to decide.


import swaggerSpec from './utils/swagger';
import userRoutes from './routes/userRoutes';
import userRoutes from './routes/user';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A bharyang would look nice.

import userRoutes from './route/user';
import authenticateUser from './auth';
import swaggerSpec from './utils/swagger';

Comment on lines +55 to +57
const { ok, token } = extractTokenFromHeaders(req.headers);

if (!ok) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't be more simple than this.

Suggested change
const { ok, token } = extractTokenFromHeaders(req.headers);
if (!ok) {
const token = extractTokenFromHeaders(req.headers);
if (!token) {

@RobusGauli RobusGauli requested a review from kabirbaidhya April 14, 2020 03:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants