Modular Design in Software Development
FAC’s Chris Czopp shares the second in his series of articles about software development.
Big, monolithic applications had their time in the past. If you’re a software developer at some point you might have experienced what it means to work on a huge code-base. Adding a new feature introducing bugs in other, big pieces of functionality which can’t be reused, and unnecessary repetition causing project maintenance nightmares. Luckily we are in a better position nowadays. There are technologies which provide ways to build software from modules i.e. small independent blocks. As a Node.js developer I’d like to share with you few ideas around modular design.
- Build your apps from multiple services
Don’t build large monolithic applications where one server provides API and UI. Split your application at least into: RESTful API, one or more UIs and link it all together with a single HTTP proxy.
- Use NPM modules
Don’t keep your modules in your projects as it breaks the idea of modularity. Modules should be reusable and accessible in other applications/services. Either publish your modules to private NPM repository or keep them on Git and use Git tags for versioning.
- Start in your project then “detach”
You might think – great, my modules should be accessible by NPM but how do I start developing? You can’t republish the module you’re working on every time you make a single change. The solution is to start the module in your project, bearing in mind that it needs to be reusable somewhere else and then ‘detach’ it to a separate NPM module.
- Make your modules stateless
The fact that you use NPM to package some functionality doesn’t mean it’s a valid module. When building a module keep it as simple as possible. Make it single-purpose. Avoid keeping its internal state in the module; rather allow it to reference external state so the application can keep track of its changes.