Social Care Finance System API

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).

Table of contents

• 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

Getting started

Prerequisites

• Docker
• .NET Core 3.1

Dockerised dependencies

• PostgreSQL 12

Installation

1. Clone this repository

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

Usage

Running the application

There are two ways of running the application: using dotnet or using docker.

Using dotnet run

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.

Using docker

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.

Running the tests

There are two ways of running the tests: using the terminal and using an IDE.

Using the terminal

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.

Using an IDE

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.

Documentation

Architecture

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.

API design

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

Databases

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

PostgreSQL (RDS PostgreSQL in AWS)

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.

Deployment

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.

Infrastructure

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.

Related repositories

Name	Purpose
LBH Social Care Finance Frontend	Provides the UI/UX of the Social Care Finance System.
Residents Social Care Platform API	Provides platform API capabilities by providing historic social care data from Mosaic to 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.

Active contributors

• 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)

License

MIT License