The Social Care Service API provides service API capabilities for the Social Care Frontend which is part of the Social Care system (see Social Care System Architecture for more details).
- PostgreSQL 12
- MongoDB
- Clone this repository
$ git clone git@github.com:LBHackney-IT/social-care-case-viewer-api.gitThere are two ways of running the application: using dotnet or using docker.
Using the dotnet command will not automatically connect the API to any local database instances.
To serve the API locally with dotnet,
run dotnet run from within the SocialCareCaseViewerApi project directory, i.e:
$ cd SocialCareCaseViewerApi && dotnet runThe application will be served at http://localhost:5000.
Run the API locally with connected local dev databases using this command:
$ make serveThe application will be served at http://localhost:3000.
N.B: This would only spin up the Application, Postgres & MongoDB locally in docker. It doesn't include setup for spinning up other APIs that this service connects to in Staging or in Production.
There are two ways of running the tests: using the terminal and using an IDE.
To run all tests, use:
$ make testTo run some tests i.e. single or a group, run the test databases in the background:
$ make start-test-dbsAnd then you can filter through tests, using the --filter argument of the
dotnet test command:
# E.g. for a specific test, use the test method name
$ dotnet test --filter GivenHttpClientReturnsValidResponseThenGatewayReturnsListCaseNotesResponse
# E.g. for a file, use the test class name
$ dotnet test --filter SocialCarePlatformAPIGatewayTestsIf your docker test postgres database is out of sync with the schema on your current branch run
$ make restart-test-pg-dbSee Microsoft's documentation on running selective unit tests for more information.
Run the test databases in the background, using:
$ make start-test-dbsThis will allow you to run the tests as normal in your IDE.
As this service API is a part of the Social Care System, higher level documentation lives in a separate repository called Social Care System Architecture.
To find out more about the process and tooling for our diagrams, see Process documentation in Social Care System Architecture.
We use SwaggerHub to document the API design, of which we have two versions:
- Hosted by SwaggerHub - for designing endpoints as a contract before we create a new feature
- Self-hosted - for actual endpoint design which is auto-generated using comments
The service API has two databases (as seen in the C4 component diagram):
MongoDB (DocumentDB in AWS)
This database stores:
- Case history. An audit log of each time an event recorded against a person.
- Google Form submission meta data. E.g: Form name, who created it, timestamp.
- Full data of forms submitted using the new system.
PostgreSQL (RDS PostgreSQL in AWS)
This database stores:
- Stores person data. E.g: Addresses, telephone number, worker allocations.
Sometimes we need to directly connect to a database for an environment to diagnose an issue or because we need to make a manual update. This is possible to do via the AWS console, see Connecting to a database documentation.
We currently don't have database migrations set up for the databases which means changes to the schema are documented in the repository and done manually via the AWS console.
If you need to make changes e.g. add a new table to the PostgreSQL database, then see Updating the database schema for how we manage this and do this via the AWS console.
From time to time, we are required to make manual data updates because it's something that's not possible through the UI of the Social Care System. However, this is something we only want to do when really necessary as it requires directly connecting to the database and running SQL statements.
To keep track of these changes, we document them in /database/manual-updates. If you need to make a manual data update, then:
- Duplicate our template file
- Rename the duplicated file by replacing the date and the title
- Fill in the sections of the file
- Commit, push and create a PR
We have two environments:
- Staging (StagingAPIs AWS account)
- Production (Mosaic-Production AWS account)
and two deployment branches:
masterwhich deploys to Staging and Productiondevelopmentwhich deploys to Staging
This means pull request merges into master and development both trigger a deployment to Staging, but only master can trigger a deployment for Production.
To deploy to Production, we first ensure that changes are verified in Staging and then we merge development into master.
We use CircleCI to handle deployment, see CircleCI config.
For deploying the Lambdas and related resources, we used the Serverless framework (see serverless.yml).
For managing the database in Staging, we use Terraform that is defined within /terraform/staging in this repository.
For managing the database and other resources in Production, we use Terraform that is defined within the Infrastructure repository.
| Name | Purpose |
|---|---|
| LBH Social Care Frontend | Provides the UI/UX of the Social Care System. |
| Infrastructure | Provides a single place for AWS infrastructure defined using Terraform as infrastructure as code as part of Hackney's new AWS account strategy. NB: Due to its recent introduction, the Social Care System has infrastructure across multiple places. |
| API Playbook | Provides guidance to the standards of APIs within Hackney. |
- Tuomo Karki, Lead Developer at Hackney (tuomo.karki@hackney.gov.uk)
- Jerome Wanliss, Intern Software Engineer at Hackney (jerome.wanliss@hackney.gov.uk)
- Renny Fadoju, Software Engineer at Made Tech (renny.fadoju@hackney.gov.uk)
- Wen Ting Wang, Software Engineer at Made Tech (wenting.wang@hackney.gov.uk)
- Marta Pederiva, Junior Developer at Hackney (marta.pederiva@hackney.gov.uk)
- Miles Alford, Junior Developer at Hackney (miles.alford@hackney.gov.uk)
- Juris Gribuska, Senior Software Engineer at Made Tech (juris.gribuska@hackney.gov.uk)