Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ref(logger): refactor logger impl to be separate from interface #784

Merged
merged 18 commits into from
Jun 5, 2023

Conversation

seaerchin
Copy link
Contributor

@seaerchin seaerchin commented May 29, 2023

Problem

Previously, our loggers were a thin wrapper over CloudWatchLogger and adding an external logging source was difficult. This was because our loggers depended on a concrete implementation rather than an interface.

Closes IS-209

Solution

  1. separate the logging interface from the logger
    • this can be further extended when we refactor our errors, so that instead of taking string, the method takes string | InternalError
  2. add a main logger that exposes the Logger interface + allows us to inject loggers into it
    • this also exposes a useFormatter method to allow people to customise their log formats (idk if this should be on main or sub loggers ._. feel free to discuss)
    • this handles calling our sub loggers
  3. adds a new consoleLogger in that is a simple object. prefixes w/ the level + has colours so it's obv.

Tests

  1. hit an endpoint on our backend
  2. there should be logs recorded, with colours

notes

  1. init function on cloudWatchLogger was copied over as-is and this wasn't called previously but is now.
  2. formatter was chosen to be placed on the main logger - we can change this if needed?
  3. const defaultImport = require("module") had to be changed to const defaultImport = require("module").default due to how default imports work in es6 vs node (see here) for details.

@seaerchin seaerchin requested a review from a team May 29, 2023 10:05
Copy link
Contributor

@kishore03109 kishore03109 left a comment

Choose a reason for hiding this comment

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

[Tests]: as a quick sanity check to confirm that this is working could we push to to staging now then check tomorrow just see if visually looks ok?

src/logger/cloudwatch.logger.ts Outdated Show resolved Hide resolved

// Constants
// TODO: Check this env var as it is not in example
const LOG_GROUP_NAME = `${process.env.AWS_BACKEND_EB_ENV_NAME}/nodejs.log`
Copy link
Contributor

Choose a reason for hiding this comment

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

Hey I dont understand this comment :(
this is in reference so some example in the documentation ah?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i actually dk too - i tried asking @alexanderleegs but he didn't know too HAHAHAHA

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for context, this was in the old logger.js and i copied this over because it seemed important

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh this comment is because me and Alex tried to find where this log exists, but we could never find it.

Might need to look again and if we conclude this is not being used anywhere, can remove

cc @alexanderleegs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this wasn't actually used until this PR - this was used in init, which was never called till now. i decided to call it because it seemed to be setting transport defaults and cloudwatch log settings ._.

src/logger/cloudwatch.logger.ts Show resolved Hide resolved
src/logger/console.logger.ts Outdated Show resolved Hide resolved
src/utils/media-utils.ts Show resolved Hide resolved
@seaerchin seaerchin requested review from kishore03109 and a team May 31, 2023 04:22
Copy link
Contributor

@kishore03109 kishore03109 left a comment

Choose a reason for hiding this comment

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

npm run build fails :(

src/logger/cloudwatch.logger.ts Outdated Show resolved Hide resolved
src/logger/logger.ts Outdated Show resolved Hide resolved
@seaerchin
Copy link
Contributor Author

npm run build fails :(

hmm - we actually lack a build step in ci; will be adding this.

package.json Show resolved Hide resolved

// Constants
// TODO: Check this env var as it is not in example
const LOG_GROUP_NAME = `${process.env.AWS_BACKEND_EB_ENV_NAME}/nodejs.log`
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh this comment is because me and Alex tried to find where this log exists, but we could never find it.

Might need to look again and if we conclude this is not being used anywhere, can remove

cc @alexanderleegs

export type Formatter = (message: string) => string

export interface Logger {
info: LogMethod
Copy link
Contributor

Choose a reason for hiding this comment

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

can we add debug & fatal as well?

Copy link
Contributor Author

@seaerchin seaerchin May 31, 2023

Choose a reason for hiding this comment

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

sure, but i do have a few questions:

  1. should any of those be optional? we might wish to make debug optional cos prod/staging loggers might not require those (but take note, also, that winston-cloudwatch has debug but not fatal)
  2. what colour should we use on console logger? thinking blue for debug, bg red for fatal

Copy link
Contributor

Choose a reason for hiding this comment

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

should any of those be optional?
Debug & fatal can be both optional

what colour should we use on console logger? thinking blue for debug, bg red for fatal
yea that's what we usually use, sounds good!

@seaerchin seaerchin requested review from kishore03109, harishv7 and a team June 5, 2023 05:28
BLUE: "\x1b[34m%s\x1b[0m",
},
BACKGROUND: {
RED: "\x1b[41m%s\x1b[0m",
Copy link
Contributor

Choose a reason for hiding this comment

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

why is this a background.red?

Copy link
Contributor Author

@seaerchin seaerchin Jun 5, 2023

Choose a reason for hiding this comment

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

thinking blue for debug, bg red for fatal

like we agreed above, fatal should be background red, no? we already use foreground red for error and this is more severe, so this is bg red.

@seaerchin seaerchin merged commit 1d50f25 into develop Jun 5, 2023
@seaerchin seaerchin deleted the ref/IS-209-logger-ts branch June 5, 2023 08:13
@kishore03109 kishore03109 mentioned this pull request Jun 8, 2023
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.

3 participants