The Social Care Service API provides service API capabilities for the Social Care Finance Frontend which is part of the Social Care system (see Social Care System Architecture for more details).

• Getting started
  • Prerequisites
  • Dockerised dependencies
  • Installation
• Usage
  • Running the application
    • Using dotnet run
    • Using docker
  • Running the tests
    • Using the terminal
    • Using an IDE
• Documentation
  • Architecture
  • API design
  • Databases
    • PostgreSQL (RDS PostgreSQL in AWS)
  • Deployment
  • Infrastructure
  • Related repositories
• Active contributors
• License

• Docker
• .NET Core 3.1

• PostgreSQL 12

1. Clone this repository

$ git clone git@github.com:LBHackney-IT/social-care-case-viewer-api.git

There 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 SocialCareFinanceSystemApi project directory, i.e:

$ cd SocialCareCaseViewerApi && dotnet run

The application will be served at http://localhost:5000.

Run the API locally with connected local dev databases using this command:

$ make serve

The application will be served at http://localhost:3000.

N.B: This would only spin up the Application, Postgres 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 test

To run some tests i.e. single or a group, run the test databases in the background:

$ make start-test-dbs

And 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 ShouldReturnPackageSchedulingOptionsList
# E.g. for a file, use the test class name
$ dotnet test --filter CarePackagesControllerE2ETests

If your docker test postgres database is out of sync with the schema on your current branch run

$ make restart-test-pg-db

See Microsoft's documentation on running selective unit tests for more information.

Run the test databases in the background, using:

$ make start-test-dbs

This 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 one version:

• Self-hosted - for actual endpoint design which is auto-generated using comments

The service API has one database (as seen in the C4 component diagram):

This database stores:

1. Care package information. E.g: Core package weekly price, service user's packages, reclaims, etc.
2. Invoice information. E.g: Invoice and billing for packages, payrun request, export for CEDAR, etc.

We have two environments:

• Staging (Mosaic-Staging AWS account)
• Production (Mosaic-Production AWS account)

and two deployment branches:

• master which deploys to Staging and Production
• staging which deploys to Staging
• develop which deploys to Development

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.

• Tuomo Karki, Lead Developer at Hackney (tuomo.karki@hackney.gov.uk)
• Neil Kidd, Lead Software Engineer at Made Tech (neil.kidd@hackney.gov.uk)
• Burak Ozkan, Tech Lead at Nudge Digital (burak.ozkan@nudgedigitals.co.uk)
• Duncan Okeno, Software Developer at Nudge Digital (duncan.okeno@nudgedigital.co.uk)
• Furkan Kayar, Software Developer at Nudge (furkan.kayar@nudgedigital.co.uk)
• Vladimir Kapenkin, Senior Software Developer at Nudge (vladimir.kapenkin@nudgedigital.co.uk)

MIT License