Q&A

What technologies have/should be used when creating mocks - do we want to make more generic and similar architecture and simple api for each BB, or maybe a proof of concept in several technologies, e.g. django/fastapi/node.js for different repos?
A: mockoon, prism, and this Custom server app.
How advanced should the API mocks be - only handling and validation of requests, or maybe additionally a database for more advanced test cases requiring several queries to test the entire 'journey'?
A: Mocks should serve mostly as tool to nail down CI test approach and implement
Cucumber's features and steps. Ideal solution would be to find real life solutions that could be attached to these api definitions.
Automated tests to check compliance of external systems with blocks - so far we have talked about integration with CircleCI. Are there any examples (e.g. for existing mocks) of calling these tests for existing systems or will we be doing this from scratch? What is the scope of that? We assume external systems will be different enough to make one general solution difficult, should we plan to create boilerplates for CI/CD calls? If so, do we limit ourselves to CircleCI or do we also take into account e.g. github workflows?
A: UNCTAD eRegistries has an example where they call an externally hosted and configured system. We can ask Ingmar for more details.
Can we get access to CI/CD services?
A: Request can be done under https://app.circleci.com/projects/project-dashboard/github/GovStackWorkingGroup/ Access to particular repositories have to be granted by WG leads. If access to repository is not granted PRs still can be done from forked repos.
Are there any applications that are currently on the other side of BB (they don't use the API, but have services mapped to endpoints that are described by our schemas)? Does it matter to us in the context of tests how the implementations are connected to check the compatibility or should we base on what's already there and working well?
A: Yes, examples: bb-workflow/examples at main · GovStackWorkingGroup/bb-workflow Caddy file is used to map endpoints.
Who is the main person approving the quality of the solution? What does the acceptance process look like? Are there any standards for architecture and code? It seems that there is no workflow used in branches. Can we give some advice here? Also are there any style guidelines? We propose to add tools such as eslint to maintain the quality of code better.
A: To be answered
How are test cases created in gherkin? Who is responsible for writing them, will there be only technical support on our side, or should we also write test cases? (example in this file test/features/detail-instance.feature)
A: BBs are responsible writing feature files and shared-JS/Python resources implementing those features as tests
Assuming that many BB teams will want our support, how should we prioritize all the work?
A: To be answered
Can we choose the technology for the application? What we propose as the best approach is to use Python on backend and React with Typescript and Next.js on frontend.
A: We should keep application simple. Development will be focused on frontend. We might not need any complex backend part for the time being, at it'll be mostly about parsing standarized JSON from db.
Would this app be a separate and independent one beside the GovStack website?
A: To be answered

Reporting App

How heavily can we rely on AWS architecture?
1. Even if an application will be deployed on AWS, the entire solution ( DynamoDB, PostgreSQL, Django App, React App) can be fully deployed in the local environment.
What will be the approach for user authentication?
1. Standard user authentication provided by Django
2. Third-party authentication (Google/Github)?
What should be the approach for data export?
1. XLSX/CSV export of data?
2. Report built using a custom template?
3. Export of HTML of React components?
What are the current outlooks for the future development of this UI Tool?