After walking through common design patterns, we have now the basis of code designing. However, software engineering is more about writing beautiful code. While we are trying to keep the code healthy and robust, we still have a lot to do to keep the project and the team healthy, robust, and ready to scale. In this chapter, we'll talk about popular elements in the workflow of web applications, and how to design a workflow that fits your team.
The first part would be setting up the build steps of our demo project. We'll quickly walk through how to build frontend projects with webpack, one of the most popular packaging tools these days. And we'll configure tests, code linter, and then set up continuous integration.
There are plenty of nice choices when it comes to workflow integration. Personally, I prefer Team Foundation Server for private projects or a combination of GitHub and Travis-CI for open-source projects. While Team Foundation Server (or Visual Studio Team Services as its cloud-based version) provides a one-stop solution for the entire application life cycle, the combination of GitHub and Travis-CI is more popular in the JavaScript community. In this chapter, we are going use the services provided by GitHub and Travis-CI for our workflow.
Here are what we are going to walk through:
- Packaging frontend assets with webpack.
- Setting up tests and linter.
- Getting our hands on a Git flow branching model and other Git-related workflow.
- Connecting a GitHub repository with Travis-CI.
- A peek into automated deployment.
We've talked about creating TypeScript applications for both frontend and backend projects in the Chapter 1, Tools and Frameworks. And now we are going to create an application that contains two TypeScript projects at the same time.
Applications for different purposes result in different choices. SPA (single page application) usually delivers a better user experience after being loaded, but it can also lead to trade-offs on SEO and may rely on more complex MV* frameworks like Angular.
One solution to build SEO-friendly SPA is to build a universal (or isomorphic) application that runs the same code on both frontend and backend, but that could introduce even more complexity. Or a reverse proxy could be configured to render automatically generated pages with the help of tools like Phantom.
In this demo project, we'll choose a more traditional web application with multiple pages to build. And here's the file structure of the client project:
Before we actually start creating a real-world application, we need to come up with a reasonable application structure. A proper application structure is more than something under which the code compiles and runs. It should be a result, taking how your team members work together into consideration.
For example, a naming convention is involved in this demo client structure shown earlier: page assets are named after page names instead of their types (for example, style.scss) or names like index.ts. And the consideration behind this convention is making it more friendly for file navigation by the keyboard.
Of course, this consideration is valid only if a significant number of developers in your team are cool with keyboard navigation. Other than operation preferences, the experiences and backgrounds of a team should be seriously considered as well:
- Should the "full-stack" mode be enabled for your team?
- Should the "full-stack" mode be enabled for every engineer in your team?
- How should you divide work between frontend and backend?
Usually, it's not necessary and not efficient to limit the access of a frontend engineer to client-side development. If it's possible, frontend engineers could take over the controller layer of the backend and leave hardcore business models and logic to engineers that focus more on the backend.
We are having the client and server-side projects in the same repository for an easier integration during development. But it does not mean everything in the frontend or backend code base should be in this single repository. Instead, multiple modules could be extracted and maintained by different developers in practice. For example, you can have database models and business logic models separated from the controllers on the backend.