Here are some of my thoughts on the future of backend/server-side development. Feedbacks welcome!
Now that scalability and security are mostly handled by the infrastructure and database layers themselves, the backend code is becoming more vanilla than ever. The complete decoupling of the front-end, native-like performance on the client-side platforms and modern frameworks and cloud services are allowing us to keep our backends thin. Serverless, microservices, containerization, and asynchronous data processing are a few latest big changes in server-side development. Rich infrastructures on top of these technologies are going to make traditional style backend development obsolete in the near future.
One common conception of object-oriented programming or programming, in general, is that our code should resemble the real world to make it easy to develop and manage. However, this particular philosophy leads to a deep coupling of the business logic and the code and makes it unnecessarily hard to make fast changes. The computing world is way more flexible and dynamic than the real world. So using real-world constructs in programming makes it artificially limited. The 1:1 modeling approach used to work really well when the software did not really need frequent changes. In the new world, where specs pivot every day, we should aim for dynamicity. This is already repopularizing the usage of newer dynamic languages for backend development.
Decoupling the business rules from the code is super important. Everything that’s configurable should be coming from some sort of configuration management system (CMS). The code should interpret the configurations and work like simulators. Softcoding is not an anti-pattern anymore. The CMS can handle the versioning of configurations. The same configuration can be shared amongst multiple micro-services and client applications. Product managers would get an intuitive interface to make quick product changes. Coupled with an A/B testing framework with some gradual rollout mechanism we can release simple changes pretty quickly across all applications.
Instrumenting the code as important as unit testing or any other quality assurance measures. Build a culture of build-measure-learn from the engineering perspective. Modify the platform to automatically log all important metrics like exceptions, API execution time, queue size, etc. Log all unusual situations by default, over-logging is better than under logging. The worst feedback loop is waiting for your customers to complain about what’s not working. Have real-time technical/operational insights, be proactive at discovering and fixing problems, and make your system resilient by automating your runbooks.
Now that you know my take on this, please share your opinion.