🏁
Best Practices
  • Introduction
  • The Big Picture
    • Principles
      • Software engineers solve business problems
      • Programming is a social activity
      • Attention is the most precious resource in a project
      • Simplicity is the best ally in the long run
      • The only problem to solve is the one we have today
    • Architecture
      • Domain
      • Services
      • Persistence
      • HTTP
      • UI
    • Naming
  • Constraints
    • TypeScript
    • Monorepo
    • Monolith
    • Versioning
  • Source code
    • Declarative programming
    • The README
    • Modules
    • Folder structure
    • Code formatting
    • Code comments
  • The Outside World
    • Runtime configuration
    • Logging
  • Testing
    • The purpose of testing
      • End-to-end tests
      • Integration tests
      • Unit tests
  • Tools
    • Git
  • Resources
    • Resources
Powered by GitBook
On this page

Was this helpful?

  1. The Outside World

Logging

PreviousRuntime configurationNextThe purpose of testing

Last updated 5 years ago

Was this helpful?

Log into JSON: it's rich, structured and you can parse messages even if the structure changes somewhat. and let the execution environment pick it up.

It is generally discouraged to import the same 3rd party library in many different locations. A good practice to hide the dependency behind a local proxy, so you can change the implementation as you see fit.

The same is valid for logging. Pick a library - if you even need a library at all - and set it up behind your facade, so your modules keep importing @you/logger.

Try to use : debug and info. Debug is for developers only, do not enable it in production. Info is for analytics and auditing.

Log to the standard output
two log levels