I picked up some of my legacy mobile apps that was untouched for over 6-10 years and working on revamping it and launching it back to Android Playstore. The lessons learnt in this endeavour is abstracted out as blog posts from me and this is one such artefact.
In the prototype phase of a project, a ` config.json` file feels like the perfect solution. It is clean, readable, and language-agnostic. However, the moment you decide to make it go live, and embrace engineering best-practices for speed and safety -- handling multiple environments, dynamic secrets, and intricate relationships between services—the rigid walls of "flat" data formats often become a bottleneck.
Transitioning to code-based configuration (CommonJS or TypeScript) isn't just about changing a file extension; it’s about unlocking the full power of your programming environment for your settings.
1. The Limitations of Flat Files (` .json`)
JSON is strictly data. While this simplicity is its strength, it is also its greatest weakness in a DevOps-heavy world. You cannot include comments to explain why a value is set, you cannot use logic to determine values based on the environment, and you certainly cannot reuse variables without duplicating them. See a sample below:
-- --
-- --
2. Advantage: Dynamic Logic & Environment Awareness
The programmability advantage -- unlike JSON, a ` .js` or ` .ts` file allows you to execute code. You can use ternaries, function calls, or ` process.env` lookups directly within the configuration object.
3. Advantage: Comments and Documentation
Configuration is often where the "magic numbers" of an application live. Why is the cache TTL set to 3600? Why is the retry limit 3? JSON forbids comments and makes you feel the pinch of missing it out. Moving to `config.js` allows you to document these decisions in-line, providing vital context for future maintainers.
4. The TypeScript Edge: Type Safety and Autocomplete
By migrating to ` config.ts`, you move from "strings and numbers" to "strictly typed contracts." This eliminates a whole class of runtime errors where a misspelled configuration key crashes the application.
When your config is typed, your IDE provides autocomplete suggestions. You no longer have to flip back and forth between your code and a JSON file to remember if the key was `apiKey` or `api_key` or any other variation of that string.
5. Advantage: Referencing and Composition
In a large JSON file, you often find yourself repeating the same base URL or domain. In a JS/TS config, you can define a constant once and reference it throughout the object. You can even import snippets from other files, enabling a "Modular Configuration" architecture.
A reference example of `config.ts`
-- --
Conclusion
Today ` .json` is best for simple project prototypes and the moment you decided to take it to production, you engineering process should mandate you to adopt dynamic application configuration. If you are leveraging Javascript you would embrace CommonJS standards and if you are like me wanting to adopt latest of best practices for profit, you would choose TypeScript that provides environment flexibility, documentation through comments, and type-safe reliability.