Project structure

  • Typical Length
2-14 Days
  • Locations
USA, Europe, Israel
  • Standards
Microservices patterns, Domain driven design, Hexagonal architecture, Clean architecture
  • Deliveries
  • Thoughtful code skeleton that apply more than 50+ best practices
  • Inspired by the leading-edge architectures: Microservices, DDD, Hexagonal and more
  • Using only highly reputable and popular packages
  • Designed for scale without sacrificing developer friendliness

More Info & Practices

Having a well-designed project structure is the key to a robust and maintainable solution. This includes layouting the code structure according to the most popular architectures (e.g. Domain driven design, microservices, clean architecture and more), setting the developer toolbox for maximum productivity along with a continuous quality inspection and integration (CI). All together we pack here more than 60+ best practices into your solution

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