Approach: 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 whether to 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.

Pointed out that as Trainee UI will be a new service, there would not be any 'swapping out'. Rather the creation of a new microservice. Therefore this is seen as an opportunity to do a greenfield React microservice. React is better able to enable the creation of smaller and reusable components. Our Angular components in Admin UI are anywhere up to 1,000 lines of code!

Key elements determining the route to take should be a combination of priority feedback from Trainee UI workshops, and a feasibility assessment. So other than presenting a subset of static data from reference tables, Form R is the only MVP feature. But what elements of other things to come would inform our decision regarding whether it makes most sense to develop a React, React & Angular, or something else type microservice?

JohnO and Yafang offered to do a tech sharing session on React (please go ahead and book it in with Phil, guys!).

Simon suggested this would be a good piece of work to determine coding standards and ensure conformity - or risk having people creating React components where they could have reused existing ones.

• what is lurking in the backlog that might inform which approach is most appropriate?
• can we experiment by creating more than one FE to begin with to help inform which route to take for the whole MVP and beyond?

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.

Can also consider a 3rd option of a progressive Web app (using service workers).

Is there a need for trainees to be able to work off-line? Assumption is yes.

Is there a need for trainees to get notifications - and is the expectation that those notifications are delivered natively, rather than passed on through a separate medium (e.g. Outlook, SMS)?

TBC - Favouring Web app at the moment.

Simon highlighted the opportunity for mobile app development training for those working on this, if needed?

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 - Strongly favouring progressive enhancement at the moment, and adopting the gov service design approach.

Incremental, yes.

Providing real value to users, who from their feedback could help the process of development, yes.

The result may be that developing Login first is not appropriate (no value to user in and of itself), but rather to work backwards - provide Form R first, then personal details, then auto populate personal details within Form R, then add login/security?

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

1. Whether to separate out the Admins UI and Trainee UI D/Bs
2. How much K8s would handle that separation, if at all, and would it be enough
3. 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).
4. Can we use views to reduce security risk? Or is separating the data repositories / domain entirely the better approach?
5. 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.

Similar to the session last week, this was the element that provoked most discussion!

Views (4. above) was discounted as requiring data to be located in the same instance, and therefore would make it impossible(?) for Trainee UI to be separated out from Admins UI in the case of a DDOS attack. Messaging and a queuing system seen as much better.

John again persuaded the group of the validity of separation from a security perspective.

We explored whether the D/B (being part of a new microservice) needed to be MySQL, or whether it could be noSQL, or some combination depending on the storage of Form R data vs the storage of the personal information.

We should offer different URLs for the two services.

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. And looking at a dual MySQL / noSQL D/B solution, perhaps, or experiments using one or the other.

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.

Many decisions should not be ones for TIS to decide - our role would be to populate NDW and HEE would then need to work out how NDW was disseminated to NI.

Group felt it easier to keep data in one D/B, but weren't sure of our precise legal position regarding the commercial elements of our relationship with NI, and how separate we therefore would legally need to make things.

What benefits (other than legal clarity - if needed) would there be to separating NI from English data for Trainee UI?

Can we develop Trainee UI in isolation of Admins UI where NI is concerned? Do we need to sort out Admins UI for NI before sorting out Trainee UI, or vice versa, or are they totally independent?

Is there a need or significant benefit for holding NI data in NI, and English data in England?

Discussed whether Trainee UI specifically needed separating out, over Admins UI being separate and Trainee UI being shared.

Felt that understanding the 'unhappy path' - what it things go wrong - might be the easiest way to help us determine level of separation? E.g.:

• what happens if a trainee in Kent is able to see the details of a trainee in NI or vice versa? Does that officially constitute a data breach?
• what happens if a DDOS attack on Trainee UI in England takes place - do we have a responsibility to try to ensure trainees in NI are able to continue to use the system? Is this a would like to have - why shouldn't every LO benefit from such isolation of service and if we're not offering that isolation in England, should we in NI (or would NI then lead on helping us develop that isolation in England!)?

TBC - Unclear whether complete separation at D/B level is necessary for Trainee UI

Need clarification of the legal position of providing both Admins UI and Trainee UI to NI and whether that affects any decisions we make in terms of architectural solution.