Blip

Blip is a web app for type 1 diabetes (T1D) built on top of the Tidepool platform. It allows patients and their "care team" (family, doctors) to visualize their diabetes device data (from insulin pumps, BGMs, and/or CGMs) and message each other.

This README is focused on just the details of getting blip running locally. For more detailed information aimed at those working on the development of blip, please see the developer guide.

---

Table of contents

• Before you start
• Install
• Build and deployment
• Configuration
• Run a production server locally
• Debugging
• Linting
• Running the tests
• Independent server for production or docker
• Documentation for developers
• Copyright management

Before you start

If this is the first time you're looking at Yoorloops (blip) locally, start with the mdblp/dblp repository to setup the backend before continuing here.

Install

Requirements:

• NVM for managing your nodejs
• Node.js version 16.x or higher
• npm version 8.x or higher

Clone this repo from GitHub, then install the dependencies:

After cloning this repository to your local machine, first make sure that you have node >= 16.x and npm >= 8.x installed. If you have a different major version of node installed, consider using nvm to manage and switch between multiple node (& npm) installations. You can install the latest npm version with: npm install -g npm@latest.

Once your environment is setup with node and npm, install the dependencies:

$ npm install

Build and deployment

Configuration

To configure blip to the desired environment source one config in the config directory. Example for a dev build:

$ source config/.env.sh

Simple dev build

The app is built as a static site in the dist/ directory.

• Will load the env var for a dev environment (docker)
• Do a development build of the application

$ npm run build-dev

Watch dev build

This will build the application and launch a dev server, with "watch" option. Everytime a file is changed in the source, the application will be re-build automatically, and the changes will be available in the browser

$ npm run start-dev

The application will be available at: http://localhost:3001/ Hit CTRL+C to stop the server.

Production build

$ bash build.sh

Run a production server locally

After that, the app is ready to be served using the static web server included in this repo:

$ npm run server

You can specify the HTTP port using the PORT env var:

$ PORT=3001 npm run server

Debugging

The app uses the bows library to log debugging messages to the browser's console. It is disabled by default (which makes it production-friendly). To see the messages type localStorage.debug = true in the browser console and refresh the page. Create a logger for a particular app module by giving it a name, such as:

app.foo = {
  log: bows('Foo'),
  bar: function() {
    this.log('Walked into a bar');
  }
};

Linting

The app is ruled by eslint to keep code style consistent. It has an editorconfig file which defines some common rules to correctly configure IDE formatting. How to enable it :

• VS code : download and install the EditorConfig plugin
• Webstorm : enable the EditorConfig support into Settings / Code style

Running the tests

This section does not apply to test defined in package "yourloops". More information about "yourloops" tests can be found at /packages/yourloops/README.md. We use Mocha with Chai for our test framework inside Karma as our test runner, as well as Sinon.JS and Sinon-Chai for spies and stubs. Our tests currently run on Google Chrome or Firefox (if not using WSL).

To run the unit tests, use:

// run all test
$ npm run test
// run a specific package, either sundiaal, viz, tideline, blip or yourloops
$ npm run test-<the targeted package>

To debug unit test, use:

$ npm run test-yourloops-debug

Once webpack has built, go to http://localhost:9876 to run the test. Click on the debug button, open devtools, go to "Sources" and open the file to debug. Breakpoints can be used (in devtools).

To run specific test(s), use :

describe.only('test name')
//or
it.only('test name')

Independent server for production or docker

For a production ready archive, or an independent docker image, the server directory is used. To do it automatically, see the artifact.sh usage.

To do it manually, fist be sure to set the environment variables needed (see the Configuration part).

# Build the application
:blip$ npm run build
# Move the created app (static web files) to the server directory:
:blip$ mv -v dist server/dist
# Update blip the version in the package.json on the server side:
:blip$ bash server/update-version.sh
# Go to the server directory
:blip$ cd server
# Install the node dependencies
:blip/server$ npm install
# Run the server
:blip/server$ bash start.sh
# Or build the docker image:
:blip/server$ docker build -t blip:latest .
# Start the docker server:
:blip/server$ docker run -p 3000:3000 blip:dev

Integration with CloudFront

Blip is designed to be published on AWS Cloudfront. The "static" js and html content (result of webpack) is published on an s3 bucket and the configuration and security stuff is handled by a lambda edge function.

Local testing

To test blip locally as if it was running on CloudFront with a lambda@edge middleware you can execute the following command (from root dir):

• launch a docker container docker lambci/lambda:nodejs10.x in "watch mode": docker run --rm -e DOCKER_LAMBDA_WATCH=1 -e DOCKER_LAMBDA_STAY_OPEN=1 -p 9001:9001 -v $PWD/dist/lambda:/var/task:ro,delegated -d --name blip-middleware lambci/lambda:nodejs10.x cloudfront-test-blip-request-viewer.handler assuming you compile the lambda script with $TARGET_ENVIRONMENT=test.
• the docker container will pickup any changes you apply to the lambda script
• source the relevant env file: . ./config/.env.sh
• then start blip server to serve static js files: npm run server

Deploy and test on a k8s cluster

To run blip on k8s (or even on a simple docker compose) you can re-use the deployment image. Create a deployment with 2 pods:

• lambci/lambda:nodejs10.x to execute the lambda
• node:10-alpine to execute the server Attach these 2 pods to a volume and use an init container to copy the app files (lambda script + static dist) on the volume. docker run -v blip:/www --env-file .docker.env blip-deployment "-c" "cd server && npm run gen-lambda && cp -R /dist/static /www && cp -R /dist/lambda /static"

Deploy to aws cloud front

To publish blip to CloudFront the simplest solution is to build the docker image provided under ./cloudfront-dist and use it.

1. From the root folder execute: docker build -t blip-deploy .
2. Prepare an environment file that contains the configuration for the environment you want to deploy to. You can use the template provided in ./cloudfront-dist/docker.template.env.
3. Execute the docker image built just above: docker run --env-file ./cloudfront-dist/deployment/cf-blip.env blip-deploy Et voila, the deployment starts. Of course you need credentials for the aws account you target ;)

Documentation for developers

how to test the GitHub workflow

⚠️ this part below contains deprecated contents, inhereted from tidepool

• Blip developer guide
  • overview of features
  • app & directory structure
  • architecture
  • code style
• usage of dependencies
  • React
  • React Router
  • Redux
    • Glossary of state tree terms
  • webpack
• misc
  • "fake child accounts"

Copyright management

The copyright profile "Diabeloop" can be found in Preferences | Editor | Copyright.

Enable copyright update on save

To enable the automatic copyright update on file save

• Go to Preferences | Tools | Actions on save
• Check the box "Update copyright notice"

Copyright text

To update the text of the copyright, go to Preferences | Editor | Copyright | Copyright profiles.

As the copyright text is shared at project-level, do not forget to commit the changes to the file .idea/Diabeloop.xml.

Version management

A NPM script allows to automatically update the version of all packages:

$ VERSION=<VERSION_NUMBER> npm run bump-version

This script will update the package version of:

• all packages in the NPM workspace
• the server package
• the cloudfront-dist/deployment package

Other

For more copyright management options, check the IntelliJ documentation.