Not all developers work in the same environment or use the same workflow. It's important to understand typical development workflows when building tools and processes or sharing your experience so that you can consider how developers using different workflows may be able or unable to apply your tool, processes, or techniques, given their situation.
This installment of the ongoing Node.js reference architecture series covers the typical developer workflows that the team has encountered and that we often factor into our discussions on the architecture, including:
- Fully local development
- Fully local development, container based
- Local development of team's component, remote services in a common development environment
- Fully remote development, container based
- Zero-install development environment
Read the series:
- Part 1: Overview of the Node.js reference architecture
- Part 2: Logging in Node.js
- Part 3: Code consistency in Node.js
- Part 4: GraphQL in Node.js
- Part 5: Building good containers
- Part 6: Choosing web frameworks
- Part 7: Code coverage
- Part 8: Typescript
- Part 9: Securing Node.js applications
- Part 10: Accessibility
- Part 11: Typical development workflows
- Part 12: npm development
- Part 13: Problem determination
- Part 14: Testing
- Part 15: Transaction handling
- Part 16: Load balancing, threading, and scaling
- Part 17: CI/CD best practices in Node.js
- Part 18: Wrapping up
Assumptions about workflows
Before we dive into the workflows, the first thing the Node.js reference architecture team captured were some assumptions that apply to many of the workflows:
- The end target/deployment artifact is most often a container.
- For some platforms, deployment remains a server or virtual machine
- Applications are made of multiple components, some of which may be developed by other teams.
The second assumption acknowledges that while container-based deployment is common, in some platforms and environments, it may not be possible or desirable, so we can't yet forget more deployment in bare metal or virtual machines.
5 typical workflows
In the team's discussion of the workflows, we ended up with four base workflows and one meta-variation that can be applied to the base workflows.
Meta-variation zero install
The meta-variation is a "zero install" environment where developers use a virtualized remote environment and use their local laptop only as a thin client. This can range from simply remoting into virtual machines with ssh to using a cloud-based IDE, which restricts the functionality available to the developer.
The key consideration when addressing developers in a "zero install" variation is that they may have much less control over their environment and may need to involve other teams in order to install/leverage any of the tools or processes that you recommend.
4 base workflows
The base workflows that the team most commonly encounters include:
- Fully local development
- Fully local development, container based
- Local development of team's component, remote services in a common development environment
- Fully remote development, container based.
The Typical Development Workflows section of the reference architecture goes into specific advantages and disadvantages for each workflow, as well as a more detailed description of each variation. We won't repeat the advantages and disadvantages of each here, as you can read in the reference architecture itself. Instead, we'll highlight some of the interesting things that came from the discussion behind that section.
Some of the interesting things that came out of the team's discussion included the following:
- An advantage of one workflow is often a disadvantage of the next.
- A common variation between flows was which elements were local on the developer's laptop versus which elements were in a remote shared environment.
- There is likely to be a fair amount of grey where organizations are partway between 2 of the common workflows.
Common advantages and disadvantages
The common aspects that were either an advantage or disadvantage in the discussion for each workflow included:
- Local Resource requirements
- Total Resource requirements
- Risk of bugs due to a mismatch between development and deployment environments
- Management/complexity for developers
- Dependence on network connectivity
- Ability to debug
- Ease of testing out changes in other components
- Ease of keeping development/deployment environments in sync
- Iteration time
- Need for centralized management/support
One aspect is often a tradeoff against one of the others. For example, as you reduce the local resource requirements, you increase the remote resource requirements and possibly the total requirements. As you increase the use of more remote resources, you increase the need for centralized management of that resource.
Local and remote workflows
The workflows move from fully local to fully remote. What we saw in our discussions is that on the fully local end, the developer has more control and flexibility but also more work to handle the complexity of managing all of the environments needed to test with external components.
As the workflow moves towards fully remote, setup and management are simplified for the developer, and requirements for local resources (i.e., size of laptop) are reduced. However, there is a tradeoff as using a shared environment requires more external coordination, can make debugging and experimentation more difficult, and require significant investment in managing the shared environment.
The dependence on the network as you move from local to remote also is a key consideration in terms of what developers will/will not be able to do when off-line.
What's next?
We think it's important to have defined the most common variations that the team has run into in order to help our discussion/thinking process and to consider how Node.js developers at different customers may be constrained. At the same time, we agreed in our discussions that many customers may be in an in-between state either because that is what fits them best or because they are still on their journey to the variation that they want to get to.
I'm interested to hear if there are other common variations that we've not covered. I'll be asking/looking for that in our discussions with customers going forward, and if you think we've missed one, please let us know.
We cover new topics regularly as part of the Node.js reference architecture series. Next, read about our recommendations for installing and publishing modules to the npm registry.
We invite you to visit the Node.js reference architecture repository on GitHub, where you can view our work. To learn more about what Red Hat is up to on the Node.js front, check out our Node.js page.
Last updated: January 9, 2024