The recent COVID pandemic pushed the last contenders and the late majority towards digital transformation. For many, it’s the only chance to save their businesses. IT companies are booming, and so is the HR market. Will every company be a software company at some point? I think we see this happening already.
The Own vs. Buy paradigm seeks balance. In the end, this usually means you will end up building something that makes your business more effective. It could also increase conversion rates by marketing a unique user experience.
The problem is not that you have to build the software. The problem is with the scarcity of developers that are going to help you build it. This problem is clearly more visible this year since the COVID dust has settled. It appears that companies must have decided to go with eCommerce and to make investments in software. This has created a huge market push to hire more engineers than ever.
At some scale companies, often decide to build team competencies from the ground up. In other words, training the developers rather than looking for rockstars, with the latter option very often ending up with a low level of staff loyalty. Picking up a single stack makes the whole thing way easier.
Of course, one could start the discussion about where one language, like Golang, is more suitable because of performance, libraries, or frameworks. You can still adopt the Polyglot Programming pattern. However, you still need to be careful not to introduce too many different stacks.
I feel like, for front-end development, the JS stack has solidified the set of industry-standard libraries, like React, Vue, and Angular. Picking the right back-end framework for JS is, maybe, a less opinionated space. Quite a lot of the back-end services are built to be customized 100% from the ground up using just a low overhead HTTP framework, like Express or Fastify. It might be the right approach for quite a lot of cases, but at some point and at some scale, it might be really hard to maintain your app build that way.
The other option is to make use of one of the popular JAM Stack supporting frameworks, like Next.js or Gatsby. They’re great because they support quite a few deployment options. They include static websites and serverless, especially Next.js, butNext and Gatbsy do not support TypeScript by default. I was a strong TypeScript believer when I started working with the Spartacus team. However, at this scale, the only option to maintain the code base is to use the typed language and a lot, I mean a lot,of unit tests :)
First of all, it’s all TypeScript based and supports a whole range of well-known enterprise design patterns, including the IoC. This is one of the features that was fascinating to me because the headless fan was the native support for GraphQL, both for schema and code-first scenarios.
Documentation is one of the best parts of NestJS, making it super easy to get into. That’s true even if you haven’t had much experience with JS back-end frameworks before.
NestJS supports all the technologies required by the modern microservices-based architectures, including gRPC, Kafka, Rabbit, and custom transports. The cool part about the microservices is that NestJS is providing you with the scaffolding for orchestrating and routing the services as a single, coherent application environment.
In a very similar manner, the developer can build a standalone application (CLI). This clearly makes NestJS a great option for multi-platform apps with a high degree of code reusability.
What are your thoughts? What’s the next big thing for back-end development?
Published April 20, 2021