The story

Back in 2017 I was involved in the development of CapstoneED, as part of my undergrad dissertation. Since it has been a while since I’ve done any web development I decided to re-write the front-end (at least for now) following modern practices and putting the experience I have had since then to use.

My high level goals for the application are as follows:

• Keep the backend as is: I would like the old and new frontend to work on the exact same data while providing different experiences. Some bug fixes will inadvertently have to happen, but I am trying to keep them to a minimum.
• Simplify the application structure: The original project had to have 3 different repositories; for the student, the lecturer and the shared. And even then the boundaries were less than clear, as changes would still have to be propagated between student and lecturer occasionally.
• Simplify deployment: I would like to be able to run a couple of commands at most and be able to demo the project at least.

As far as the UI/UX is concerned I would like to:

• Make it mobile first instead of mobile friendly. At least for the student, as the lecturer view is more “Admin Dashboard” like.
• Add modern QoL that has become much more common (and expected) nowadays. For example, dark/light themes.

The plan

I will stick with Angular as I do enjoy the framework, and its focus towards stable APIs. In order to tackle the above requirements, I have came up with the following plan:

Setup a monorepo

I am going to use Nx to setup a monorepo. Nx has good Angular support and will allow me to incorporate other technologies if I need it. I suspect an Angular workspace with multiple projects would also be enough for my immediate needs. But since the backend is in Rails I might end up having to do some integration and that seems to be easier with Nx.

In addition to that, a monorepo should allow the two (or more) applications to share reusable code and logic properly, with little propagation between the two. Yes, if I change the API of a shared component both will have to be updated, but if I change the Angular version, I will not have to sync between 3 repos.

I have decided on having two separate apps to allow for differentiating decisions at compile time instead of runtime. For example, a student-only project component never has to validate that the currently logged in user is a student. This reduces the mental context I need to have for that component, but also its actual dependencies (i.e. way easier to test).

The structure I am following for now can be seen below. libraries will contain shared code. For example for the projects feature libraries/projects/data-access will contain all the data store logic, while libraries/projects/feature the shared components, directives, etc. On the other hand, apps/student-frontend/features/projects will contain all the project components that are unique to the student view.

capstoneed/
├── apps/
│   ├── student-frontend/
│   │   └── features/
│   │       └── projects
│   └── lecturer-frontend/
│       └── features/
│           └── projects
└── libraries/
    ├── user/
    │   ├── data-access
    │   └── feature
    └── projects/
        ├── data-access
        └── feature

Currently planned structure

Use Angular Material

In the original implementation we wanted to do as much of the work as possible ourselves, as it was a dissertation after all. While that was fun and educational, it came to the detriment of polish (i.e. making sure all ARIA attributes are in order). Additionally, with the Material Design 3 spec, and its transition to CSS variables, it is much easier to implement features such as dark and light themes. In fact, here it is already in action:

Containers, containers, containers

I would like to have a setup where I can quickly clone and demo the API, or either of the frontends without having to deal with dependencies on my host machine. Yes, Docker is not something new, but it is a fact that the original version had none of that.