Attendees
Meelis Zujev (Deactivated) Taylor Downs Aleksander Reitsakas Paweł Gesek Wes Brown David Karunda Steve ConradIngmar Vali PSRAMKUMAR Ain Aaviksoo (Deactivated) Damian Borowiecki (Deactivated) David Higgins Dominika Bieńkowska (Deactivated) Jukka Aaltonen (Deactivated) Kibuuka, Arnold Nyoman Ribeka Satyajit Suri Valeria Tafoya
Agenda | Presenter | Duration | Discussion | ||||||||||||||||||||||||||
| 10 minutes https://www.youtube.com/watch?v=4ASKMcdCc3g
|
| |||||||||||||||||||||||||||
Concept of adaptor | https://www.youtube.com/watch?v=kxGWsHYITAw | Is this model correct/sufficient? What technology/tooling do we use? Are there multiple options? We need to focus some time on the adaptors and how do we bring existing DPGs into compliance with the specs that we're developing. The the key idea is that the adapters are used to provide URL and payload mapping between an existing API and Gov Stack API definitions. In contrast, the workflow building block is used to manage more complex transactions, or where you need you to know to the control the rollback or commit flow of a transaction. So if we or If one transaction requires calling multiple building blocks, that's where you would use something like the workflow building black and then block. Then finally the information mediator is used to transfer information securely between building blocks when you're goinggoing over the wire across the internet. what's the tooling or technology that we would use to implement an adaptor? A simple scenario, ; if you have a one building block calling another one, the first building block makes a call that goes through its adaptor, which maps the URL and payload into the GovStack format; the . The adaptor then sends it over the wire to the first adaptor and the second adapter maps that GS format URL and payload into the second DPG format. The second DPG format processes the information and then, the process happens again in reverse. Each building blocks is linked to an adapter that does the mapping from its native format to GS format and then GS back to native. A couple of considerations to note; we are not looking at the idea of service discovery and how one service knows where another service is located. It is really important that adaptors are easy to reuse and reconfigure so that we are not rewriting from scratch for every different use case or sector. Could we allow but not mandate an adaptor on the 'calling' application or BB? Taylor - DPG requesting data from another BB should be out of scope. In Gov Stack, we are obsessed with services and rest API; rest API does not make requests and we should never be in the business of helping application make a request to another service. Adaptor is entirely around receiving a request and adapting it. Steve - We have not talked to much yet about the UXUI building block or what is app consuming the services. Is that part of GS or not? Wes - Adaptors consume/convert to the defined BB APIs without having to use other standards. If the BB API aligns to a standard then that standard would be used by default but it's driven by the BB API. Some software may (eventually) directly support BB APIs as well, in which case an adaptor would not be required. That's not likely in the short-term. The term "adaptor" doesn't really map to the sending. It's more of an application-specific translation service. In either case, there is some custom dev required; seems much easier to just update the software to talk to the other BB. Pawel - Will this be an interceptor and intercepts the request? Or will this be module or GovStack SDK that anyone can use to build GS clients applications? Building adaptor on the sending side might be challenging because DPGs can be written in different languages, frameworks, and might want to retrieve GS data in different ways. It might be easier on the receiver side Ramkumar - Adoptors could be borrowed, and in case where there are non, we can build ab adaptor. Taylor - in the specs folder, non of the BBs have a medical record standard for patient data as part of their open API specification. Adaptor helps the DPGs meet the open API specs in this 12 repos. We need to be thinking around medical record standards | |||||||||||||||||||||||||||
Status update | BB Leads Valeria Tafoya Meelis Zujev (Deactivated) Dominika Bieńkowska (Deactivated) Steve Conrad | https://www.youtube.com/watch?v=U1vz__vR8hQ | Scrum standup-style (what we did this week; plans for next week; blockers/pain points and open/unresolved questions?
Wes - The work that we're doing here is not trying to go through and change the content or change the intent of the content. We are just trying to make sure everything is getting aligned to the template that we agreed that we would use. That will mean we might need to make some changes in the short term that we need to revisit in the future. The goal is for consistency across each one of the building blocks so that they all read the same and that we have a cohesive set of specifications that seem to flow well together. No changes should be made in 0.9.
| ||||||||||||||||||||||||||
Building Blocks versioning | https://www.youtube.com/watch?v=u_BcMXgws6Y | Proposed technical solution to the versioning of BBs Test Suite Versioning Damian - It’s been decided to rely on the functionality that is already provided by GitHub and other version control systems. Ramkumar - Who will control the version numbering and auditing it? The test suit will evolve over time because we do not know all the tests presently. Wes - Assuming there is also going to be a non versioned one as well. If we will have specific point in time versions, which we need to be able to show compliance or compatibility for software to specific versions of building blocks, we also need to have the development version, master main etc, but something other than a specific version that is being worked on that is yet to be released. Damian - Besides those releases, the latest test suite will be executed, which would be made in branch in our case. Taylor - This is supporting releases rather than deciding how building block spec owners do their versioning Staya - The concept of living documentation should be looked into. Cucumber on its one defines the model of how code and gherkin files are minted and synced. Pickles is an open source which helps to generate living documentation as cucumber needs - so we do not need to keep creating new gherkin files repeatedly as APIs changes. https://www.picklesdoc.com/ Document describing approach: Test Suite Versioning | |||||||||||||||||||||||||||
BB spec target reader- Persona | https://www.youtube.com/watch?v=_W0bSen8Qjg | I have received feedback to make BB specification well readable for architects by removing the example screenshots. Taylor - the users that were discussed in the past are:
Ingmar - It is complicated to narrow on just three groups. But if we want to focus on everybody, some screenshots will be nice for the IT Leads or government officials for decision making. It is important to write documentation that the decision makers must read. Ramkumar - the decision makers do not have to get deep into the BBs specs. The reference UCs, wireframes and high level demos in the Sandbox are there for them to see while they can delegate their technical team to review the specs. Wes - The current 1.0 publication is more technical and it is intended to focus on the technical audience. The decision makers can have sandbox as one potential entry point but there should be others, and documents to help guide them as well. This gap will be filled in subsequent releases. |
Meeting recording
Action items
...
Images/screenshots can augment feature descriptions and, to a limited amount, requirements. They should not be used as part of the definition itself. |
Meeting recording
...