Hosting Views

MyDataHelps views are web pages/applications that must be hosted on an external web server. This article describes some hosting options and best practices.

Tip
This article does not apply to views created using the MyDataHelps View Builder, which are hosted on CareEvolution’s servers.

Contents

Starter Kit
Best Practices
CI/CD Using Amplify and GitHub

Starter Kit

The MyDataHelpsStarterKit is a React web application template that you can clone/fork to accelerate your custom view development. It supports best practices using the architecture described in CI/CD Using GitHub and Amplify.

The starter kit includes:

NPM References to the MyDataHelps SDK and MyDataHelpsUI React component library.
Sample views to get you started.
A sample AWS Amplify configuration to help with hosting.
A sample custom HTTP headers configuration to aid in meeting the security requirements.

To use the starter kit, just copy, clone, or fork the repository in GitHub and follow the instructions.

Best Practices

MyDataHelps views can be hosted on any web server. Whatever platform you use, we strongly suggest that you follow these best practices in order to maintain project stability.

For an example of a complete architecture leveraging these suggestions, see CI/CD Using GitHub and Amplify.

Source Control

Your view’s source code and web pages should be managed in a version control system such as GitHub. This gives you a revision history, the ability to revert changes, easier collaboration, and many other benefits.

Within your version control system, you will generally want to maintain separate branches for testing and production. This allows you to update and test your code (on the test branch) without affecting your real users in your live project.

Continuous Integration and Delivery

Manually deploying your view’s code/pages to your server can be tedious and error-prone. A Continuous Integration and Delivery (CI/CD) pipeline can automate this process. Changes made in your source control repository will be automatically built and deployed to your server.

For added stability, you can use two separate CI/CD pipelines–one for testing and one for production. Each is tied to their respective branches in your source control system, and has their own website and URL.

Project Implementation

Just as you should have two separate branches in your source control system for testing and production, we recommend utilizing two separate MyDataHelps projects within your organization to support healthy development:

A test project (e.g., “Sleep Study Dry Run”), containing only fake/test participants, utilizing the test URL from your CI/CD pipeline.
A production project (e.g., “Sleep Study Live”) containing the real participants, utilizing the production URL from your CI/CD pipeline.

Typically you would begin with the test version of the project for initial development and testing. When ready to go live, you can:

Copy the test project to create the production project. (See Copying Projects. for details.)
Promote the code in GitHub from the test branch to the production branch.
Update the production project to utilize the production URL for the custom view.

This architecture will also help you test surveys, schedules, and segments. After launch, you can make changes to the test project, test them internally, and then promote those changes to the Production project. This avoids unnecessary risk and instability for participant experience.

CI/CD Using Amplify and GitHub

This section describes the architecture recommended by CareEvolution for managing your views. It implements the best practices described above through a CI/CD pipeline using GitHub for source control and AWS Amplify for hosting.

Tip
While this is certainly not the only possible solution for managing your views, many MyDataHelps projects have been successful using this architecture. Whatever solution you choose, we strongly advise following the suggested best practices.

Should you have any questions about this architecture, or difficulty setting it up for your views, please contact us.

GitHub

A GitHub repository stores the web pages and source code for the view. Within the repository, there are two branches:

main (for testing)
prod (for production)

Initial development is done on the main branch. When testing is complete, code can be promoted (merged) to the prod branch.

Should you need to modify the code later (to fix something or add a new feature), you would do that on the main branch. This leaves the production project untouched and stable. Only after internal testing would you once again promote the code to prod.

Amplify

AWS Amplify is a cloud hosting service. In this architecture, there are Amplify sites–one for testing and one for production. During the Amplify setup process, you can use its GitHub integration to connect the test site to the main branch and the production site to the prod branch.

Whenever you make a commit in GitHub, Amplify will automatically build and deploy that code to the appropriate Amplify site. This process takes just a few minutes.

The test site and production site will have their own individual URLs. By default, Amplify sites are given an auto-generated URL like https://prod-ab12345.amplifyapp.com. You can optionally configure Amplify to use your own custom domain.

Project Implementation

As mentioned in the best practices, we suggest having two separate MyDataHelps projects–one for testing and one for production. The test project will utilize the URL from the Amplify test site in its view configuration, while the production project uses the production URL.