```
Now that we have our packaged application, the last step is to deploy it:
```
sam deploy --guided
```
This presents me with options for the deployment defaults. The most important
one is `Allow SAM CLI IAM role creation`. By affirming this, AWS will create the
`QueryPocketFunctionIamRole` and generate an ARN for it.
This takes a few minutes but the CLI will keep you up to date with the
deployment process. Then, if successful, it will confirm the resources it has
created:
If I go to CloudFormation in the AWS I will see that the `pocket-api-lambda`
stack now exists:
And a new function is added to AWS Lambda with the API Gateway endpoint as the
trigger:
And in API Gateway the API has also been set up:
## Frontend
My frontend is built with the GatsbyJS library and so is React-based.
### Environment variables
Early I took to trouble to run both development and production versions of the
API. When I am working locally on my site I want to be querying the local
endpoint rather than the production version since this will accrue fees and also
requires me to deploy after every change.
I will use an environment variable to distinguish the local and production
endpoints. I do this using the [dotenv](https://www.npmjs.com/package/dotenv)
Node package and create the following two files:
```sh
# .env.production
GATSBY_POCKET_AWS_LAMBDA_ENDPOINT=https://[HASH].execute-api.eu-west-2.amazonaws.com/Prod/query-pocket/get-articles-by-tag
```
```sh
# .env.development
GATSBY_POCKET_AWS_LAMBDA_ENDPOINT=http://127.0.0.1:3000/query-pocket/get-articles-by-tag
```
By prepending the variable name with `GATSBY`, Gatsby will know to inject these
values at runtime. This way, and by adding my `.env` files to the `.gitignore`,
I can avoid hardcoding my endpoints and can use a single reference in my React
component.
When working locally I can run `NODE_ENV=development npm run start` to source
the local endpoint variable and `NODE_ENV=production npm run start` to source
the production endpoint variable. In the deployed production context however,
`.env.production` will not be available because it is an ignored file. Thus to
source the variables when `npm run build` is run remotely, it is necessary to
store them as secrets that can be accessed in my CI/CD pipeline. I use a
[GitHub Action](https://systemsobscure.blog/how-I-deploy-this-site/) to build my
site and deploy it to AWS when I push changes, so I add the following line to my
`main.file` build script:
```yml
steps:
- name: Set environment variables
run: |
echo "GATSBY_POCKET_AWS_LAMBDA_ENDPOINT=${{ secrets.GATSBY_POCKET_AWS_LAMBDA_ENDPOINT }}" >> $GITHUB_ENV
echo "GATSBY_METRICS_AWS_LAMBDA_ENDPOINT=${{ secrets.GATSBY_METRICS_AWS_LAMBDA_ENDPOINT }}" >> $GITHUB_ENV
```
### React component
Below is the React component:
```jsx
const ENDPOINT = process.env.GATSBY_POCKET_AWS_LAMBDA_ENDPOINT
const ArticleListing = ({ article }) => {
return (
|
{article?.resolved_title}
|
{formatUnixTimestamp(article?.time_added)} |
)
}
export default function RecommendedArticlesPage() {
const [loading, setLoading] = useState(false)
const [data, setData] = useState({})
useEffect(() => {
const fetchData = async () => {
try {
setLoading(true)
const response = await axios.get(`${ENDPOINT}?tag=website`)
setData(response?.data?.data?.list)
} catch (error) {
console.error(error)
} finally {
setLoading(false)
}
}
fetchData()
}, [])
const articles = Object.keys(data).map((key) => data[key])
return (
Articles written by others that I have learned from or which present
interesting viewpoints.
| Title |
Date added |
{articles?.map((article) => (
))}
)
}
```
Here I source my environment variable from the Node runtime context and use it
to query the API via the React `useEffect` hook that runs once on load. Then I
loop through the data to populate the rows of an HTML table.
## Addendum: authentication
I have set up a basic AWS Gateway API with two execution contexts (local and
production) that trigger a Lambda function. In closing I want to note that a
considerable oversight is the lack of authentication for the remote endpoint. In
its current state anyone with access to the production URL can call the API.
In this context it's not that big of a deal since the information is not
sensitive or particularly interesting however if I was following best practice I
would need to provide a way for AWS to authenticate requests. I did attempt this
using an IAM role and an AWS Cognito user pool however I was unable to get this
working despite my best efforts. This is something I will return to in a future
post.