libya v1.0.0

DCAF Libya

All code for DCAF Libya website.

Requirements

• Amplifi CLI: 4.11.0 or higher.
• xplain2sql: 5.5 or higher: npm install -g node_xplain2sql
• cfn-lint
• cfn-flip

Installation

Install packages:

npm install
git submodule init
git submodule update

Install react-admin packages:

cd admin
npm install

(there's an open issue to fix this extra step.)

Amplify is needed to publish builds: Initialise amplify:

amplify pull

This will ask you for your AWS profile, which you should have set up in ~/.aws/config and ~/.aws/credentials. Select the "libya" app for the backend to pull.

Your answers should look like the following:

? Do you want to use an AWS profile? Yes
? Please choose the profile you want to use angrycactus-ireland
? Which app are you working on? libya (d2zu5hb9cejsm)
Backend environment 'berend' found. Initializing...
? Choose your default editor: Emacs (via Terminal, Mac OS only)
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using none
? Source Directory Path:  src
? Distribution Directory Path: build
? Build Command:  npm run-script build
? Start Command: np run-script start

? Do you plan on modifying this backend? Yes

Successfully pulled backend environment berend from the cloud.
Run 'amplify pull' to sync upstream changes.

Note that the profile name itself is not important. It can be "angrycactus-ireland" or anything else.

The environment can also be different.

You will also need to run amplify pull every time another developer has made a change in the backend.

Backend

Listing available environment

There may be multiple environments to work in. List them with:

amplify env list

Creating your own environment

If multiple people are doing development, it's best if each has their own development. Especially working on the GraphQL layer has the problem that it is disruptive for other people.

1. Set up your own environment with:

   amplify env add

Say no to use an existing environent. Then pick any name you like.

2. Then switch to your new environment. In case you created "staging":

   amplify env checkout staging

3. Create your environment, i.e. set up all AWS resources:

   amplify push -y

4. Create a new database:

   cd amplify/backend/api/libya/xplain
   make create-database

In order to insert data via migration the drupal-to-aurora environment will also need to be available in the new environment, and the drush 60ferry:export should also send data to the new environment.

5. If you want to run react-admin, you will need to add users to your new Cognito pool.

6. Algolia indexing: your environment also should have an Algolia index. Create one in Algolia if needed.

   In team-provider-info.json copy the settings for the LawToAlgolia function to your own version of it. You could create a separate api key, but that is not needed.

Creating a production build

Once you have setup your own environment, you can publish a build:

amplify publish

Api keys

We are currently using apikeys. However, they expire. You may see an odd error message during a push: The specified key does not exist. * In that case you will need to update the key following the guide.

Working with Amplify

upsertLaw Lambda function

This Lambda function is the resolver for the GraphQL createLaw and updateLaw mutations.

Note that this function uses a custom stack in amplify/backend/function/UpsertLaw/yaml-stacks. Run make in this directory to create the actual stack amplify/backend/function/UpsertLaw/upsertLaw-cloudformation-template.json.

Working with Xplain

Most AppSync GraphQL is generated. See the Xplain documentation for more detail.

Frontend

app

Start hot reloading:

npm start

react-admin

Start hot reloading:

cd admin
npm run start

Update staging

Here the steps to update the staging environment.

1. Merge latest from master:

git checkout staging
git pull origin master

2. Update the amplify staging environment:

amplify env checkout staging
amplify push -y
amplify publisy

3. If you want to copy an existing database, first update the staging root user password in AWS Secrets Manager with the password from the database (environment) you are copying.

   If you have done this in the past, you don't need to repeat this step, as the password would not have changed.

4. Take a snapshot of the RDS database you want to copy.

5. Take note of the staging database cluster ID.

   It is amplify-libya-staging-172324-aur-serverlessaurora-4m23dw1hea8h at the time of writing this manual.

   amplify-libya-staging-172324-auroralibya-amdgz0kcy6by-dbsubnetgroup-1q8h1ylhxa3id

6. Then delete the staging database and wait till it has been deleted.

7. Restore the snapshot to a new serverless database. This currently cannot be done via the console (bug, you cannot pass in the right database instance identifier anymore).

   Once this works: when restoring from a snapshot, give the new database the DB Instance Identifier of the deleted staging database.

   Make sure the VPC matches the VPC of the staging database. Put the database in the aurora-staging VPC security group. Enable the Data API.

   The command-line still works:

aws rds restore-db-cluster-from-snapshot --db-cluster-identifier amplify-libya-staging-172324-aur-serverlessaurora-4m23dw1hea8h --snapshot-identifier to-staging --vpc-security-group-ids sg-022ebe4d070f8991f --engine aurora-postgresql --db-subnet-group-name amplify-libya-staging-172324-auroralibya-amdgz0kcy6by-dbsubnetgroup-1q8h1ylhxa3id --scaling-configuration MinCapacity=2,MaxCapacity=4,AutoPause=true,SecondsUntilAutoPause=3600,TimeoutAction=RollbackCapacityChange --copy-tags-to-snapshot true

Manual steps when using console: enable Data API (Http endpoint):

aws rds modify-db-cluster \
    --db-cluster-identifier sample-cluster \
    --enable-http-endpoint

8. Copy the Algolia database: select the index you want to duplicate, then select "Duplicate" and specify as target "staging_Laws".