Trainee UI - initial Dev team discussion on what's required

Some suggestion of the team deciding whether to use React, or Angular for this app:

• Angular viewed as a robust framework requiring coding discipline, but reliable because it is a complete framework.
• React viewed as a very good set of libraries available to enable flexible ways of handling specific challenges.

Fear of throwing the Angular baby out with the bathwater. Question over maintain Angular, and using React to introduce flexible solutions to problems Angular would struggle to deal with.

Risk, however, that React isn't as robust as Angular and does not require the coding discipline - therefore would need better documentation to be maintainable in the longer term.

Feeling was that a strong argument would need to be made to fully swap out Angular for React, but adding React to Angular should be something we can just do.

Discussion revolved around:

• Need for native app functions - it was unclear whether there is anything in the MVP or any of the MMFs that require native app capability (e.g. notifications could be handled via email / text messages if we require trainees submit an email address / mobile phone number as part of their registration process, rather than in-app notifications)
• Sustainability / expertise - do we have the expertise to create native apps / framework for creating an app that could be delivered natively / 
• Need for an inclusive approach (cater for anyone on any version of any OS using any browser version, rather than tell then to use the latest version of Chrome, for example)

Also heard that from a testing perspective AWS offer an in-built testing solution using real devices, getting round the issues of testing for mobile using online emulators only.

TBC

(Favouring webapp at the moment)

The team discussed the merits of graceful degradation vs progressive enhancement. And erred on the side of progressive enhancement (i.e. choose a lowest common denominator, and then progressively add functions and features from there, rather than develop for current tech, and add code to try to make it work on older tech).

Discussed the usefulness of the government service design standards. It was felt that these whilst somewhat simplistic, would be a good thing in terms of consistency with other government offerings, and would stop us doing anything too funky that might require prohibitively comprehensive testing, or that might take us away from a general governmental direction of travel.

TBC

(Favouring progressive enhancement at the moment, and adopting the gov service design approach)

Then we got into the nitty gritty of infrastructural decisions needed:

• Whether to separate out the Admins UI and Trainee UI D/Bs
• How much K8s would handle that separation, if at all, and would it be enough
• Need to factor in the significantly increased 'attack surface' faced when launching Trainee UI (expected concurrent users rising from 35-50 to potentially thousands at peak periods).
• Can we use views to reduce security risk? Or is separating the data repositories / domain entirely the better approach?
• Have we estimated / can we estimate expected load? If we have an entirely separate K8s instance, which could then scale separately, would this negate any concerns over expected loads?

John persuaded the group of the sense that separation makes when considering this challenge. So creating a queuing system (similar to the bi-directional ESR solution - RabbitMQ or AWS native), with triggers, real-time. However, current endpoints being exposed by TCS aren't fit for wider exposure - so extra work would be needed to re-purpose these, tweak them, or create new ones.

TBC

(Favouring complete separation at D/B level, allied with a queuing service, with triggers, synchronising real-time across Admins UI and Trainee UI. This has the added advantage of separating out the threat of a DDOS attack on one app taking down both apps)

There is a likelihood that once we develop Trainee UI, we will roll out to NI in the same way we are planning to roll out Admins UI. This has some implications:

• GDPR
• Commercial concerns
• Segmenting data - separate D/B again, or using some sort of filtering of reference data?
• Scalability of NI app in comparison to scaling of English app.

From a business perspective, NI are being treated as another local office. However, as a separate country with a separate sister body to HEE (NIMDTA - Northern Ireland Medical and Dental Training Agency), there are legal implications to consider that mean they cannot technically be treated as another local office.

Feeling was that separation for NI was also the sensible approach. So in the end there'd be a D/B for Admins UI (England), one for Trainee UI (England) and another for Admins UI (NI) and another for Trainee UI (NI). Rather than approaching separation via specific roles set up (as this was felt far less secure and risked human error in making English data available to NI administrators / trainees (and vice versa).

Prime concern was to only surface NI data to NI administrators / trainees, and English data to English administrators / trainees.

Need to consider also the likelihood that some trainees will move between England and NI (and vice versa).

Consider hosting the NI data in a data centre closer to NI.

And use a different domain (entirely) for NI.

Finally, also need to consider how to absorb existing NI data into the app, and segregate it from English administrators / trainees.

TBC

(Favouring complete separation at D/B level, allied with a queuing service, with triggers, synchronising real-time across Admins UI and Trainee UI)