Architecture & Code review

  • Typical Length
1-6 Days
  • Locations

USA, Europe, Israel, Remote

  • Standards

ITIL, Standard software architectures (Domain driven design, Hexagonal architecture, etc), 12 factor

  • Deliveries
  • 200+ items checklist report
  • Executive summary dashboard
  • Covers architecture, code standards, devops, security
  • Analysed using advanced automated tools like static code analysis

More Info & Practices

Already have a Node app which you want to benchmark and improve? Want to get an external opinion about the app and plan your improvements roadmap? I’m offering solution review services in which we collaboratively go through the code and identify strategic issues that might greatly affect the maintainability or the production stability. Besides an in-depth open discussion I also check specific 200+ items which turn into a detailed report

Best Practices

  • Structure your solution by components
The worst large applications pitfall is maintaining a huge code base with hundreds of dependencies – such a monolith slows down developers as they try to incorporate new features. Instead, partition your code into components, each gets its own folder or a dedicated codebase, and ensure that each unit is kept small and simple. Visit ‘Read More’ below to see examples of correct project structure
  • Layer your components, keep Express within its boundaries
Each component should contain ‘layers’ – a dedicated object for the web, logic and data access code. This not only draws a clean separation of concerns but also significantly eases mocking and testing the system. Though this is a very common pattern, API developers tend to mix layers by passing the web layer objects (Express req, res) to business logic and data layers – this makes your application dependant on and accessible by Express only
  • Wrap common utilities as NPM packages
In a large app that constitutes a large code base, cross-cutting-concern utilities like logger, encryption and alike, should be wrapped by your own code and exposed as private NPM packages. This allows sharing them among multiple code bases and projects
  • Separate Express 'app' and 'server'

Avoid the nasty habit of defining the entire Express app in a single huge file – separate your ‘Express’ definition to at least two files: the API declaration (app.js) and the networking concerns (WWW). For even better structure, locate your API declaration within components

  • Use environment aware, secure and hierarchical config

A perfect and flawless configuration setup should ensure (a) keys can be read from file AND from environment variable (b) secrets are kept outside committed code (c) config is hierarchical for easier findability. There are a few packages that can help tick most of those boxes like rc, nconf and config