Earthdata Search
About
Earthdata Search is a web application developed by NASA EOSDIS to enable data discovery, search, comparison, visualization, and access across EOSDIS' Earth Science data holdings.
It builds upon several public-facing services provided by EOSDIS, including the Common Metadata Repository (CMR) for data discovery and access, EOSDIS Earthdata Login (EDL) authentication, the Global Imagery Browse Services (GIBS) for visualization, and a number of OPeNDAP services hosted by data providers.
License
Copyright © 2007-2024 United States Government as represented by the Administrator of the National Aeronautics and Space Administration. All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Application Installation and Usage
The Earthdata Search application uses NodeJS and Vite to generate static assets. The serverless application utilizes the following AWS services (important to note if deploying to an AWS environment):
- S3
- We highly recommend using CloudFront in front of S3.
- SQS
- Step Functions
- API Gateway
- Lambda
- Cloudwatch (Events)
- Bedrock
Prerequisites
NodeJS
We recommend using Node Version Manager (NVM) to manage your NodeJS install. Use the shell integration to automatically switch Node versions.
NVM will automatically install the correct node version defined in .nvmrc
nvm use
PostgreSQL
Earthdata Search uses PostgreSQL in production on AWS RDS. If you don't already have it installed, download and install it to your development environment.
Recommended: Use Homebrew
brew install postgresql
Start the PostgreSQL server:
# If you have never used brew services before:
brew tap homebrew/services
# Start the server:
brew services start postgresql
If you decide to install via Homebrew you'll need to create the default user.
createuser -s postgres
Docker, Optional
Docker is used to simulate SQS locally using ElasticMQ.
Valkey, Optional
To use an image cache (for scaled images and NLP search) you need to have Valkey installed locally.
Recommended: Use Homebrew
brew install valkey
brew services start valkey
Migrating from Redis:
If you previously had Redis installed, you must stop and uninstall it, and ensure port 6379 is clear before starting Valkey.
brew services stop redis
brew uninstall redis
Optionally you can run Valkey in a Docker container with:
npm run start:cache
To stop the Docker container:
npm run stop:cache
Initial Setup
Package Installation
Once npm is installed locally, you need to download the dependencies by executing the command below in the project root directory:
npm install
Configuration
Secrets
For local development Earthdata Search uses a json configuration file to store secure files, an example is provided and should be copied and completed before attempting to go any further.
cp secret.config.json.example secret.config.json
In order to operate against a local database this file will need dbUsername and dbPassword values set (you may need to update dbHost, dbName or databasePort in static.config.json if you have custom configuration locally).
If you created the postgres user after a new PostgreSQL install as described above, both dbUsername and dbPassword will be the username you use to log into your computer.
Public (Non-Secure)
Non-secure values are stored in static.config.json. In order to prevent conflicts amongst developers you copy the static config into overrideStatic.config.json and change the config values there. Do not commit changes to static.config.json.
cp static.config.json overrideStatic.config.json
We can configure some of the layouts for the EDSC presentation by updating the defaultPortal value in overrideStatic.config.json. For development purposes we should set this to edsc.
.env File
The .env file is used to set environment variables for local development. An example is provided and should be copied and completed before attempting to go any further.
cp .env.example .env
If you are going to connect to AWS Bedrock change the values set to 'CHANGE-ME' to the appropriate values.
Database Migration
Ensure that you have a database created:
createdb edsc_dev
To run the migrations locally:
npm run invoke-local migrateDatabase
Creating a new database migration
To create a new database migration use this command to ensure the migration follow the same timestamp name scheme.
npm run migrate create name-of-migration
Run the Application Locally
The local development environment for the static assets can be started by executing the command below in the project root directory:
npm start
This will start everything you need to run Earthdata Search locally.
- React application: http://localhost:8080
- Mock API Gateway: http://localhost:3001
- Watch for code changes to the
serverless directory
- ElasticMQ container for SQS Queues.
- Mock SQS service to trigger lambdas on SQS messages.
Optional Services
By default we don't run all services locally. In order to run the application with those services you need to include the follow environment variables when you start the application.
- USE_CACHE: This will use a local Valkey instance to cache images from GIBS, as well as geocoder results.
- SKIP_SQS: When set to true this will skip adding retrievals to SQS, so your retrievals will not be submitted without a manual lambdas invocation.
- USE_NLP_SEARCH: When set to true this will call AWS Bedrock to parse your query on the landing page.
- USE_GEOCODER: When set to true this will enable the geocoder lambda (running in Docker) to be called from the nlpSearch lambda to provide geocoding results.
You can set any of these environment variables to true to run the optional services locally. To run the full application with all optional services you can run the following command:
USE_CACHE=true SKIP_SQS=false USE_NLP_SEARCH=true USE_GEOCODER=true npm start
Or run
npm run start:optionals
Building the Application
The production build of the application will be output in the /static/dist/ directory:
npm run build
This production build can be run locally with any number of http-server solutions. A simple one is to use the http-server package
npx http-server static/dist
Invoking lambdas locally
To invoke lambdas locally we must create a stringified JSON file with the order information to the specific lambda we are trying to run the structure of the events will differ between the lambda. Typically this will include data from your local database instance which is used in the event information.
npm run invoke-local <name-of-lambda-function> ./path/to/event.json
Pulling down colormaps locally
Run the application with optionals on then use
npm run invoke-local generateColorMaps ./tmp/generate_colormaps.json
with a JSON object of
{
"projection":
}
Run the Automated Vitest tests
Once the project is built, you must ensure that the automated unit tests pass:
npm run test
To run in the vitest ui mode:
npm run test:ui
Test coverage will be updated in the coverage directory to see breakdown use
open coverage/lcov-report/index.html
Run the Automated Playwright tests
To run Playwright tests, you must first install Playwright:
npx playwright install
To run Playwright in ui mode:
npm run playwright:ui
To run Playwright tests in headless mode:
npm run playwright
Deployment
When the time comes to deploy the application, first ensure that you have the required ENV vars set:
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- STAGE_NAME
This application runs in a VPC for NASA security purposes, therefore the following values are expected when a deployment occurs:
- VPC_ID
- SUBNET_ID_A
- SUBNET_ID_B
- INTERNET_SERVICE_EAST_VPC
For production use, this application uses Scatter Swap to obfuscate some IDs -- the library does not require a value be provided but if you'd like to control it you can set the following ENV vars:
- OBFUSCATION_SPIN
- OBFUSCATION_SPIN_SHAPEFILES
To deploy the full application use the following:
bin/deploy_bamboo.sh
Note: In that script all the env variables are prefixed with bamboo_ to match our deployments.
