Person service: decide MVP scope

[mietcls]

Decision

It will be hard to get this completely in production without creating the entire infrastructure. There are two scenarios:

1. We create each service in test and after it has been tested we use all of those services at the same time in production and let it point to production.
2. We replace each service step by step but have to meddle in the Purl code

There is a huge risk; the flowable set-up that has been created in isolation with PHP.

Define what we will deliver as MVP

• Flows of data that go to Biblio
• Deprecate MongoDB

Define what is out of scope

• Long term roadmap GISMO and Biblio
• Flowable and PHP applications

How to handle SOAP endpoints

• We do not have any documentation
• SAP message bus

Data

• Verse lei, alles van GISMO er in steken, zien welke IDs ontbreken en dan zien hoe we dat oplossen
• Preferrednames, ORCID IDs, ... migreren
• Niet gewoon de persoonsrecords verhuizen van onze lijst
• Situatie die gaat ontstaan
  • Informatie van GISMO binnentrekken, opnieuw afgespeeld
  • Ontbrekende IDs die wij ooit zelf hebben toegevoegd -> Keuze maken dat we ofwel zelf de ontbrekende IDs toevoegen, of die naar GISMO sturen

Lange termijn willen we eigenlijk enkel naar hen luisteren, niet zelf dingen toevoegen.

Context

https://github.com/ugent-library/people/issues/6 -> why and how

Steps

• [ ] Technical scaffolding experiment & analysis
• [ ] #1
• [ ] #2
• [ ] #3
• [x] #9

[mietcls]

Start of epic

End-Goal: Biblio becomes consumer of people service, and we use GISMO as single source of truth

Milestones

Throughout

• [ ] Problem strategy trouble shooting with GISMO

Step one to see if it works – test version

Milestone 1: Person service stands by itself on the Nomad cluster

• [ ] Deploy
• [ ] Dockerised
• [ ] GRPC API
• [ ] Datamodel mindset needs to take shape
  • [ ] Storage
  • [ ] Outer world
  • [ ] NATS
• [ ] Person Service + NATS
  • [ ] Person service listens to NATS
  • [ ] Person service understands NATS protocol
  • [ ] Person service knows how to save those messages
• [ ] Security
  • [ ] GRPC (mtls, data at rest encryption, passwords at rest, ORCID token)
  • [ ] NATS

Summer holiday finish. Aim for a solid application that is future-proof and flexible. We do not need to solve every question, we can take an incremental approach.

Milestone 2: To be refined

• [ ] Manually send artificial messages to NATS in JSON to the person service, mimicking the SOAP bridge

Milestone 3: To be refined

• [ ] People service has API that can be used by the back-office (GRPC: get person, search people)

Step two to make it visible and finish the circle

To be refined

• [ ] Tinker on existing SOAP bridge that it would send the data to the MongoDB and to NATS (web sockets)
• [ ] Create sanity checks between databases
• [ ] Decide which cases we will solve and which ones we will not (Goal: conflict free high way – waiting VS fixing)

-> two worlds come to life where we still use the MongoDB, and where we can actually start filling up the people service and see the quality of the data

Step three – adapt back-office

To be refined

• [ ] Make sure back-office uses new service instead of MongoDb
• [ ] Keep MongoDB as a failsafe that we can go back if needed

? Front-office

To be refined

• [ ] Make sure front-office becomes more agnostic

Risks

• We cannot see how bad or how good the new or old situation will or was be
• We will have to be very flexible in our approach to make sure the data quality is acceptable – as we will have to fix problems from the past as well. We will have to pick our battles.

Approach of co-existing two worlds

• Phasing out after a couple of months
• Matter of weeks that will take longer, not months or years

Use GISMO as resource instead of LDAP --> too big Front-office does not handle person service in an intertwined way any longer No MongoDB for persons Back-office queries person service as a separate service

More stability doet hetzelfde als de vorige minder shit en conflicten met personen

EOY we aim to finish it all.