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

(fix) [NAN-644] refactor logger and some environment detection logic out of #1913

Conversation

khaliqgant
Copy link
Member

@khaliqgant khaliqgant commented Mar 27, 2024

Describe your changes

Add internals utils package and move logger and some environment detection logic there

Issue ticket number and link

NAN-644

Checklist before requesting a review (skip if just adding/editing APIs & templates)

  • I added tests, otherwise the reason is:
  • I added observability, otherwise the reason is:
  • I added analytics, otherwise the reason is:

Copy link

linear bot commented Mar 27, 2024

export function isBasicAuthEnabled() {
return !isCloud() && process.env['NANGO_DASHBOARD_USERNAME'] && process.env['NANGO_DASHBOARD_PASSWORD'];
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Debatable if these two below should be here or not.

@@ -10,6 +10,8 @@ import type { RawDataRecordResult, DataRecord, DataRecordWithMetadata, RecordWra
import db from '../db/database.js';
import util from 'util';

const { logger } = new Logger('Encryption.Manager');

interface DataRecordJson {
encryptedValue: string;
[key: string]: any;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I am tempted to also move encryption.manager into this new package. After all it was in utils before. The question is how to we deal with types?

Copy link
Collaborator

@TBonnin TBonnin left a comment

Choose a reason for hiding this comment

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

Reiterating that I think this package would be better called utils. And personally I would create all those internal packages (I feel we are going to have a bunch) into a subdirectory of /packages (for example: /packages/libs or packages/internals to differentiate the end products (cloud services, published packages, etc...) to the stuff only used internally

Copy link
Contributor

@bodinsamuel bodinsamuel left a comment

Choose a reason for hiding this comment

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

Nice starts, very glad we are moving on this.
I have a few comments, starting from almost scratch is a good time to start with alignment too 👍🏻

I think it's also missing few things:

  • main package.json workspaces property
  • Nodemon listen to internals/dist on all related packages, so it restart when modified
  • Our many Dockerfiles are not updated and I'm actually surprised it passed the CI

packages/internals/lib/environment/detection.ts Outdated Show resolved Hide resolved
return winston.format.printf((info) => {
return `${info['timestamp']} [${info.level.toUpperCase()}]${service ? ` [${service}] ` : ''}${info.message}`;
});
};

class NangoLogger {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think I want to question our use of Class, most of the time they seems to hold no state, here it's just a function.

export function getLogger(server?: string) {
  winston.createLogger({
      levels: winston.config.syslog.levels,
      format: winston.format.combine(winston.format.timestamp(), nangoLogFormat),
      format: winston.format.combine(winston.format.timestamp(), nangoLogFormat(service)),
      transports: [new winston.transports.Console({ level: process.env['LOG_LEVEL'] || 'info' })]
  });
}
export const logger = getLogger();

packages/internals/package.json Outdated Show resolved Hide resolved
packages/internals/package.json Outdated Show resolved Hide resolved
transports: [new winston.transports.Console({ level: process.env['LOG_LEVEL'] || 'info' })]
});
}
}

export default new NangoLogger().logger;
export default NangoLogger;
Copy link
Contributor

Choose a reason for hiding this comment

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

I would also like to discuss our use of export default.
I find it a bit inconvenient to find import across the codebase, import name is not enforced making it harder to have a consistent way of naming things. Plus if we need to export more then we have a mix of default + named.
For example here, vscode can't autocomplete Logger and only find NangoLogger which would differ from what you have wrote.

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated as discussed

…ection-logic-out-of' of github.com:NangoHQ/nango into khaliq/nan-644-refactor-logger-and-some-environment-detection-logic-out-of
Copy link
Contributor

@bodinsamuel bodinsamuel left a comment

Choose a reason for hiding this comment

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

🚀 Amazing!

@@ -28,7 +28,7 @@ jobs:
run: |
# Build, install CLI and verify it can run
npm install
npm run build -w @nangohq/node -w @nangohq/shared -w nango
npm run build -w @nangohq/node -w @nangohq/utils -w @nangohq/shared -w nango
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we could just npm run ts-build

Copy link
Contributor

Choose a reason for hiding this comment

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

I think you forgot to change that, or put back a build command in utils/package.json, but I think using ts-build is safer

Copy link
Member Author

Choose a reason for hiding this comment

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

Building everything seemed like overkill rather than just building what we need exactly.

I’ll add back in the specific build command which was there originally in utils. I think it’s handy to have specific build commands in each package regardless

Copy link
Member Author

Choose a reason for hiding this comment

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

@khaliqgant khaliqgant merged commit 1f4a7e2 into master Mar 27, 2024
17 of 18 checks passed
@khaliqgant khaliqgant deleted the khaliq/nan-644-refactor-logger-and-some-environment-detection-logic-out-of branch March 27, 2024 19:59
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.

None yet

3 participants