Adopting New Technology (Part 2)
29 July 2020 by Jeff Woodhams
Recap
In my last post I said I would follow up with more detail on some aspects of my experience with investigating the latest technologies. I’ve been using my chosen combination of Angular, LoopBack, Mongo and Node.js for several weeks now and it’s a good time to reflect on the experience.
When I look back I have four main observations:
- It was a very steep learning curve, involving understanding several new concepts and adopting different ways of working. In fact I’m very conscious of the fact that I have really only ‘scratched the surface’
- But it has been well worthwhile. When I stop and think about it my time spent coding is significantly reduced because I only ever have to write code which directly delivers whatever change or enhancement I want to make. All of the ‘behind the scenes’ stuff is done for me.
- It really is amazing how a number of different frameworks work really seamlessly together.
- Although my current application is relatively simple it is much simpler to maintain than previous methods we used. The method encourages you to develop three very distinct layers; Model, View and Controller. Specifically I now no longer need to write any code on the server side. All of my data manipulation is achieved using Angular/TypeScript on the client side. The LoopBack API allows me to deliver data asynchronously using services.
The Application
It might be appropriate at this stage to tell you a little about my application. It’s not actually a business application, it’s more of a hobby one. Over the years I’ve collected a lot of data and mementos relating to my family; photos, maps, wills, birth, marriage and death certificates. There are several good off-the-shelf packages for storing this type of data and providing you with reports. But I was interested more in understanding the social history of my ancestors; how couples met, why people moved from one area to another when they had been in that area for generations. To achieve that I wanted to be able to display the information in as graphical a form as possible and enable people to drill down into the detail as easily and effectively as possible. Specifically I wanted the display to have one axis based on time so that it would be relatively easy to compare what different family members were doing at the same time.
The application needed to be web-based so that I was able to share the information with anybody that wanted to see it. My basic concept was to display a complete family of three generations on a single screen with a timeline running from top (oldest) to bottom. This means that at the top you have the four grandparents with their birth, marriage and death details. Below them you have the selected couple and below that you have all the children. Each person then has a series of Events defining their life. These events are displayed in time sequence down the screen. Against each event you can then store any number of ‘images’. An image can be anything from a photo to a copy of a marriage certificate. On the screen each image is represented by an icon. Clicking on the icon will then pop up a modal display of that image.
Data Access Management
One of the main advantages I’ve found with this combination of frameworks is in the management and accessing of data. I know from experience that the structure of your data is one of the most important features of any project, which is why keeping the access and management of it as simple as possible is critical to our projects.
The advantages of Mongo are that it is relatively lightweight in terms of resources and it is very flexible. One big difference between SQL Server, which is historically our go to database tool, and Mongo is that Mongo is not a relational database. However, this has not proved to be a problem for my relatively simple data structure because you can define relationships between data types and that works well for this application.
Having developed several years’ experience with .NET Framework and SQL Server I had grown used to every data item being of a specific type. One of the biggest differences with the frameworks I have been using in this application is recognising that they do not need everything to be type specific and learning to make the most effective use of this feature was one of the main challenges.
Once I had firmed up the requirements for the application I recognised that I needed three different types of data; people, events and images. I initially planned to define the images as a separate data type but that would have meant having a relationship between Events and Images which could potentially give rise to problems with accessibility. However, by applying the principle of keeping it simple I managed to reduce this to just two data types; Person and Event. I removed the need for an Image data type and the additional relationship by making images an array of objects as a property of the Event data type.
To manage the data and access it in the application I am using LoopBack, which is a framework based on Node.js and Typescript which can generate APIs for incorporation in an Angular project. Loopback has the ability to support multiple data sources linked to the majority of database types including MongoDB. Once the data source is established and verified it is literally a single command to generate an API that can be used in the main Angular project to access and manage the data. This is a huge advantage over having to manually generate the code, which is what we needed to do in previous projects.
Data Provider
As I mentioned in the previous blog the application is a Singular Page Application (SPA) using Angular. One of the key features of Angular is a sophisticated routing module which enables the user to switch the content of the single page as if they are routing between different pages. More about this in another blog.
Another important feature of Angular is the Resolver module which contains an interface that classes can implement to act as a data provider. The interface contains a method that is invoked when the navigation starts. The router then waits for the data to be resolved before the route is finally activated. This means that the data required to populate the page is available when the new page contents are displayed.
This feature was particularly useful when I came to release the application on the web. As a company standard we use GitHub for version control. I was aware that it’s possible to launch a repository on the web using Git Pages. That seemed a particularly good idea as it’s free! However, I soon realised that it only allows static data which means that my development setup with the Mongo database would not work. Initially I thought, “Oh well that’s it, I’ll have to think again.” But after applying some thought to the problem I realised that actually the data I wanted to use on the website was static, I didn’t plan to allow users to access or change the data.
So, using the LoopBack API Explorer I was able to generate the data as a JSON file. It was then relatively simple to change the main display component from obtaining data from the resolver to reading it in from the JSON file. Problem solved! The application is now available to family members to browse at their leisure.
We would love to hear your experience of SPA and the Angular development tools so do get in touch!
Back to Blog listings