Integrating Real-Time Traffic Updates with the HERE SDK Navigate
Sachin Jonda — 12 December 2024
6 min read
03 June 2022
Migrating to the Basic or Limited HERE platform plans requires replacing the API key issued from the developer.here.com with a key generated by HERE platform. We’ve covered how to create a new API on platform previously, and this article demonstrates how to securely deploy an application using Gitlab CI/CD.
It’s essential to protect your keys when deploying your application. Let’s look at a common mistake and how to prevent it.
A common mistake is embedding your keys or credentials in the code when building an application for convenience. The key is visible in the source when viewed in the browser.
For example:
var platform = new H.service.Platform({apikey: “my.api.key”});
A better way to manage credentials in your HERE application is to use a JavaScript framework that compiles the keys or credentials at build time. We’ll use Next.js, a production-ready React framework, as an example. Next.js loads environment variables, such as API keys, from `.env.local`, e.g.:
// .env.localBASE_PATH=/my-map-appAPI_KEY=ABCD1EFGH2SHARE_URL=https:/my.website.com/my-map-app
An advantage of using a .env.local file is that it can be excluded from a Git repository with a .gitignore file which prevents leakage of credentials. Because you can set environment variables for development, `.env.development`, or production, `.env.production`, it is best practice to use a wild card to prevent adding these files to the repository.
// .gitignore.env.*.local
Keys, credentials, and other environment variables are read at runtime. In this example, we’re using `next.config.js which is a Node.js module that reads the `.env.local` file with process.env which is a Node.js global variable.
// next.config.jsconst withPlugins = require("next-compose-plugins")const optimizedImages = require("next-optimized-images")
module.exports = withPlugins([ [optimizedImages, { optimizeImagesInDev: true }],])
module.exports = { basePath: process.env.BASE_PATH || "", publicRuntimeConfig: { basePath: process.env.BASE_PATH === "/" ? "" : process.env.BASE_PATH, apiKey: process.env.API_KEY, shareUrl: process.env.SHARE_URL, },}
Next.js can make a production build as a deployable static web application. In the `package.json` file of the application, we can add an export script.
// package.json"scripts": { … "build": "next build", "export": "npm run build && next export",}
To build the application, run:
$ npm run export
Next.js compiles and packages the source code and writes it to a directory called /out. The application is ready for securely deploying on your cloud provider.
Updating and deploying applications manually can be tedious and error-prone. A common solution is to use a Continuous Integration/Continuous Delivery tool, such as Gitlab, to automate the process.
This example demonstrates how to deploy a static web application in an AWS S3 bucket capable of hosting static websites. The first step is to add the following group variables (assuming that applications are deployed in a group). Gitlab provides detailed instructions for adding variables.
Group variables to set in Gitlab:
AWS_ACCES_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION
S3_BUCKET_NAME_PROD
S3_BUCKET_NAME_REVIEW
CDN_DISTRIBUTION_ID
The next step is to configure the .gitlab-ci.yml file, which defines the scripts you want to run. It sets the configuration files and templates to include any required dependencies and caches. The .gitlab-ci.yml file sets the sequence of commands to run, the location to deploy applications, and if scripts are triggered automatically by an action such as a push or if actions are triggered manually. Gitlab provides thorough documentation on this configuration file.
The example below had three stages: a build stage, a review stage, and a deploy stage. The build stage creates the app to be deployed. This example deploys an app built on next.js and uses yarn to build the app. The next stage is the review stage which creates an ephemeral deployment used to evaluate the app before deployment. You can use s3 bucket policies to control access during the review stage. The deploy stage deploys the application to a publicly available s3 bucket configured as a static website.
stages: - build - review - deploy
variables: # Common AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY AWS_REGION: $AWS_REGION S3_BUCKET_NAME: $S3_BUCKET_NAME CDN_DISTRIBUTION_ID: $CDN_DISTRIBUTION_ID
cache: key: $CI_COMMIT_REF_SLUG paths: - node_modules/
Build: stage: build image: node:11 script: - yarn install - yarn build - yarn export artifacts: paths: - build/ expire_in: 1 day
Review: stage: deploy when: manual before_script: - apk add --no-cache curl jq python py-pip - pip install awscli - eval $(aws ecr get-login --no-include-email --region $AWS_REGION | sed 's|https://||')script: - aws s3 cp build/ s3://$S3_BUCKET_NAME_REVIEW/ --recursive --include "*" - aws cloudfront create-invalidation --distribution-id $CDN_DISTRIBUTION_ID --paths "/*"
Deploy: stage: deploy when: manual before_script: - apk add --no-cache curl jq python py-pip - pip install awscli - eval $(aws ecr get-login --no-include-email --region $AWS_REGION | sed 's|https://||') script: - aws s3 cp build/ s3://$S3_BUCKET_NAME_PROD/ --recursive --include "*" - aws cloudfront create-invalidation --distribution-id $CDN_DISTRIBUTION_ID --paths "/*"
Migrating to HERE platform is an excellent time to upgrade your deployment process. Make sure you deploy your API keys securely and automate the process for building and deploying applications.
Sophia Parafina
Share article
Sachin Jonda — 12 December 2024
Sachin Jonda — 25 November 2024
Aaron Falk — 21 October 2024
Why sign up:
Latest offers and discounts
Tailored content delivered weekly
Exclusive events
One click to unsubscribe