This is my second article about the way I would design LinkedIn’s web app architecture using Angular. My first article focused on decomposition and routing, whereas this article focuses on how the components interact and retrieve their data: it’s about services and modules.
In my previous article (‘Angular App Architecture’), I described the components of the LinkedIn app as I would design it. One of these components was the navigation bar that enables the user to select a specific route, resulting in the component being rendered for that route.
Another one is the component for showing the profile summary, but that component lacked data. Now it’s time to determine how our components interact, how data is retrieved and how it is provided to all components that render the data.
A short reminder of what I mentioned in my previous article (‘Angular App Architecture’): my colleague Martijn Kloosterman wrote “How to talk to your children and listen to what they have to say” part 1 and part 2 where he explains parent-child communication and peer-to-peer communication between components. In this article, I assume knowledge of the techniques he described. If you are not sure, read Martijn’s blog posts first.
Providing data to our app
When designing the LinkedIn app, I ended with some components like the NavBarComponent, the HomePageComponent and the ProfileSummaryComponent. (This is not the full set of components required for the complete LinkedIn app, but enough to describe the design process.) The structure of our app is shown below.