Giter Club home page Giter Club logo

ysm-backend's Introduction

Your Story Matters (YSM)

Your Story Matters (YSM) is a digital companion for survivors of sexual assault launched in 2019. Formerly called YANA (You Are Not Alone) and funded by Nesta and the UK Department of Digital, Culture, Media and Sport through the Tech to Connect Challenge, YSM has curated content including recovery, moving through trauma, accessing justice through the law, stories of resilience, and allows survivors the option to create an account and save their journey.

Get Involved

If you would like to help Chayn and receive special access to our organization and volunteer opportunities, please visit our Getting Involved guide. We'll get back to you to schedule an onboarding call. Other ways to get involved and support us are donating, starring this repo and making an open-source contribution here on GitHub, and supporting us on social media!

Our social medias:

Website - Chayn

Twitter - @ChaynHQ

Instagram - @chaynhq

Youtube - Chayn Team

LinkedIn - @chayn

YSM Backend

GitHub Actions CI workflow badge

A NestJS API server with Jest testing.

This repo serves just the YSM backend, find YSM's frontend code here: https://github.com/chaynHQ/ysm

Currently in active development.

How to Contribute:

Before making a contribution, please follow our Contributing Guidelines in CONTRIBUTING.md.

Happy coding! ⭐

Development

RECOMMENDED: You may skip ahead to the Running as a Docker Container Locally section below if you just want to run the backend service locally and not do any development work on it.

Prerequisites

  • NodeJS v14+
  • Yarn v1.21+

Technologies Used:

  • NestJS - Node.js web framework
  • Jest - JavaScript testing
  • Firebase - user authentication and analytics
  • Rollbar - error reporting
  • StoryBlok - headless CMS for pages and courses content
  • Heroku - build, deploy and operate staging and production apps
  • GitHub Actions - CI pipeline

Set up local env config

For local development, create a new .env.development file and add the following environment variables:

If you're an official Chayn volunteer, please get in touch with the team for access to the environment variables.

# The API token from Storyblok (must have 'draft' access)
STORYBLOK_TOKEN=

# The service account JSON object serialised into a string and then base64 encoded
FIREBASE_SERVICE_ACCOUNT={value}

# OPTIONAL: comma separated list of email addresses for users allowed to access preview mode (for viewing draft content from Storyblok)
CONTENT_EDITOR_EMAILS=

# OPTIONAL: when running in `dev` mode. Either set this to the Rollbar server token, or to `false` to disable.
ROLLBAR_TOKEN={value}

# OPTIONAL: required in `production` mode or if `ROLLBAR_TOKEN` is set.
ROLLBAR_ENV=local-dev

# OPTIONAL: The window of time (in milliseconds) for the rate limiting to apply.
RATE_LIMIT_WINDOW_MS={value}

# OPTIONAL: The max number of requests (per IP address) within the window of time (above).
RATE_LIMIT_MAX=(value)

If creating new environment variables:

  • Check if the new environment variable must be added the ci.yml file.
  • Note that new environment variables must be added to Heroku before release to production. Please tag staff in your issue if creating new environment variables.

Install dependencies

yarn

Set up local env config for tests

Tests will use a separate .env.test file which should already be present.

You'll also need to create a .env.test.local file (see below for more details).

All access to external services in unit tests should be mocked out, so when adding new config to the app make sure to add a dummy 'noop' value in the .env.test file and commit to the repo.

It's also advisable to mock out access to external services in the e2e tests (e.g. like with Storyblok), but sometimes it makes sense to actually call the external service (like for Firebase Auth tokens). In the latter case, make sure all "live" config is set in a .env.test.local file (which must NOT be committed to the repo), with the following:

FIREBASE_SERVICE_ACCOUNT={value}  # Same as in .env.development - the service account JSON object serialised into a string and then base64 encoded

FIREBASE_WEB_API_KEY={value}  # Special API key just for use in e2e tests - found in the settings page for the Firebase project

Run locally

# development
$ yarn start

# watch mode
$ yarn start:dev

# production mode
$ yarn start:prod

Run tests

# unit tests
$ yarn test

# e2e tests
$ yarn test:e2e

# test coverage
$ yarn test:cov

Formatting and linting

yarn lint

To lint and fix:

yarn lint:fix

Formatting and linting is provided by ESLint and Prettier (see the relevant configs for details).

Workspace settings for VSCode are included in this folder.

Build the app for production

yarn build

Generating new modules, controllers, services, etc

NestJS provides the nest generate command to help generate relevant files.

Debug logs for all axios requests (e.g. for Storyblok requests)

To see debug logs for all axios requests made – e.g. by the Storyblok client – start the dev server with:

DEBUG=axios yarn start:dev

Note: the axios-debug-log library used to provide this logging has only been added as a dev dependency, so this will not work in production environments.

Running as a Docker Container Locally

You may want to run the backend service in a Docker container if:

  1. You don't intend to do any development work on it and just need a running service for the frontend to access.
  2. You want to test that the Docker image works as expected, e.g. if you've made any changes to the Dockerfile.

Steps to run the docker container locally:

  1. Ensure you have the Docker service installed and running on your machine. More info on how to do this: https://docs.docker.com/get-docker/.
  2. Follow the directions above on setting up your local env config. Note that you don't need to follow any other instructions from the previous sections (like having the prerequisites, installing dependencies, etc.) as the Docker build process will do all this for you.

Then, build the image:

docker build -t ysm-backend .

Then, run the backend service in a container:

docker run --rm -it -p 3000:3000 --env-file=.env.development -e PORT=3000 --init ysm-backend

You can now test that the service is running, either using curl:

curl -v http://localhost:3000/api/resources

… or opening the URL http://localhost:3000/api/resources in your browser. It should show the JSON output of the /resources API.

License

This project uses the MIT License.

YSM and all of Chayn's projects are open-source.

While the core tech stack included here is open-source, some external integrations used in this project may require subscriptions.

ysm-backend's People

Contributors

chaynteam avatar dependabot[bot] avatar jits avatar kyleecodes avatar sophieheb avatar swetha-charles avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar

Forkers

kyleecodes

ysm-backend's Issues

Upgrade node to node 16+

Background
Github actions will no longer support node 12 soon. We are trying to upgrade all our applications to node 16 or higher.

Task

upgrade node 16 to a higher a version as possible without affecting other packages. This might not be possible. There might be some packages that aren't compatible with node 16+ so you will need to upgrade them too.
check all the happy paths work

Upgrade node to node 16+

Overview

We need to upgrade our node version to 16+ because GitHub actions will no longer support lower versions.

Action Items

  • Upgrade node to 16+ or highest version as possible without affecting other packages in package.json
  • Upgrade node to 16+ or highest version as possible without affecting other packages in the Dockerfile
  • Ensure all other dependencies are compatible with node 16+, upgrade them if necessary.
  • Test by checking if happy paths work.
  • Ensure the node version in any GitHub workflows is updated.

Note: This upgrade may require more steps than listed here. We will update this issue accordingly.

Resources

Audit tests

Overview

We need to audit our software tests as we upgrade dependencies to identify and fix potential new bugs, ensure compatibility with newer dependencies, and note of any improvements we can make for contributors (such as documentation). This is not a comprehensive "audit" on testing performance. Additionally, if specific environment variables for testing are required, we need to determine which can/should be public or private for Chayn volunteers only.

Action Items

  • Gather environment variables for testing.
  • Set up and run local testing.
  • Identify warnings & errors, save for future reference.
  • Upgrade outdated dependencies if they haven't been already.
  • Run the tests. Note of any issues, warnings, errors, or needed improvements as these will be made into issues later.

Resources

Create public access Storyblok token

Overview

Currently, contributors on YSM cannot obtain a Storyblok token without reaching out to maintainers. We can bypass this by creating a non-production public access token for Storyblok, which can be revoked at any time. This is the only required environment variable that isn't accessible for contributors to create on their own because Storyblok contains the content needed for an accurate view of the front-end.

Note: We have already done this for Bloom: chaynHQ/bloom-frontend#611 (comment)

Action Items

  • Gather non-production public access token (with 'draft access') from Chayn dev who has access to Storyblok's dashboard.
  • Share this token in the Tech Volunteer Guide in Notion, because this token is subject to change and it's easier to change in docs than on GitHub.
  • Link to Tech Volunteer Guide in the README.md

Resources

Remove required Snyk workflow from pull requests

Overview

We need to remove the security/snyk (chaynteam) workflow that is required in YSM's pull requests because we switched to Dependabot and Snyk no longer has access to Chayn's GitHub. This will involve some research as I am not sure where the workflow is coming from -- strangely I cannot find it in our workflow code or in the GitHub Actions settings. Snyk has been disabled as an authorized GitHub app in both organizational and repo GitHub settings, and pull requests made after have still required the workflow run.

Action Items

Here are some starting points for disabling this workflow...

  • Check if GitHub Action cache needs refreshed.
  • Check settings in the internal Snyk dashboard which initiated this workflow.

Solution: It's just a branch protection rule, easily removed in settings.

Resources

GitHub Docs: Managing Caches

Resolve old dependency PRs

Overview

We need to clean up this repo's pull requests, specifically the PRs opened by Dependabot & Snyk, because many are outdated and contain high severity dependency alerts.

Action Items

  • Manually resolve PRs opened by Snyk. Snyk no longer has access to Chayn's repos because we use Dependabot now, since Snyk won't be able to interact with these PRs any further, we will need to make these changes manually.
  • Resolve dependabot alerts. Approve their workflow runs and resolve any merge conflicts. Locally test these changes. If they pass all tests, merge these PRs. If the tests don't pass, keep the PR open for future reference. If there are repeat PRs for the same dependency, try to merge the highest version possible and close the rest.
  • Open new issues and triage with staff software engineers for dependency upgrades that result in test failures.
  • Resolve dependabot alerts.

Note: there is a workflow from Snyk called security/snyk (chaynteam) that is required for merging, please bypass this requirement as Snyk has been removed from this repo and can no longer access it.

Resources

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.