Part 2 of my series focuses on what it took to move from โit worksโ to turning a prototype into a production app, something stable enough to depend on and run in production. Beyond new features, it explores the architectural decisions, infrastructure trade-offs, and real-world costs involved in turning a prototype into a production app. Many of those lessons donโt show up in code, but they are every bit as important for success once real users and real expectations are involved.
Software development is an ever-evolving space where languages, tools, and best practices can rapidly change based on the market. Yet there is always a race to do things faster and better than before.
Today, I will be introducing you to Turborepo, a tool that helps manage JavaScript and TypeScript monorepos by leveraging build techniques to avoid duplicate work and maximize multitasking at scale. But first, there may be a couple of questions you’re asking yourself. What is a monorepo, and why use Turborepo?
In this post, I will be introducing three strategies that can help Node developers who wish to loosen their code. First, weโll cover microservices with Moleculer. Then, weโll through Inversion of Control with InversifyJS. Finally, weโll discuss N-Tier Architecture and why itโs helpful.
This is a perfect opportunity for us to explore cloud serverless offerings as the ultimate contact-less development option. While COVID-19 continues to make face-to-face collaboration an impossibility, cloud-based applications and workloads provide a well-defined method for remote development and project deployment. Serverless offerings, like Azure Functions and Azure Logic Apps, take this to the next level while allowing us, as developers, to focus only on our application functionality and not the backing infrastructure or uptime of servers. These serverless solutions will be the focus of this blog.
I am a Spring/Java developer (primarily) and an advocate of unit testing.
There is often a debate over what constitutes a unit test, an integration test, a system test, etc. But, most of us agree that tests keep you from going โoff the railsโ once a project becomes sufficiently complex.
However, I have found very few discussions on architectural tests. What keeps us from deviating wildly unintentionally from our original, planned architecture? And, after all, how many enterprise projects even keep the same architects from the beginning of the initiative to shelving and replacement?
In this blog, I introduce ArchUnit, a Java architecture test library for specifying and asserting architecture rules in plain Java. Weโll discuss how it works to mitigate architectural risks in developing quality enterprise applications…