Review Deploy
Important: These docs are for the outdated Jets 5 versions and below. For the latest Jets docs: docs.rubyonjets.com
Let’s review what has been deployed.
CloudFormation Console
Jets leverages CloudFormation for deployment, so check the CloudFormation console. You should see something like this:
Jets creates a main parent demo-dev
stack that, in turn, creates a few nested CloudFormation stacks. This solves the CloudFormation quotas and limits. Here’s a summary:
- There are few stacks that manage the API Gateway resources. They start with
demo-dev-Api*
- There is a stack that manages a PreheatJob, it starts with
demo-dev-JetsPreheatJob-*
- There is a stack that manages the controller, it starts with
demo-dev-JetsController-*
.
API Gateway REST API
If you look at the CloudFormation stack demo-dev-ApiGateway-*
Resources tab, you’ll see the Rest API.
Clicking on the Physical ID link takes you to the APIGW console. You can see that that points to a demo-dev-controller Lambda function.
Lambda Console
The demo-dev-controller Lambda function is defined in the demo-dev-JetsController-*
CloudFormation stack.
Clicking on the Physical ID link takes you to the Lambda console. You can see the Lambda handler code there.
The Lambda function handler is generated as part of jets deploy
. The handler is the “point of entry” for Lambda and provides the interface that Lambda expects. The code routes the request to the desired controller action.
The Jets.process
ultimately calls the PostsController
action methods. You can open app/controllers/posts_controller.rb
and see the code we created earlier.
Note: Jets v5 creates one APIGW Method and Lambda function for all controller actions. Previous versions of Jets created multiple resources. There are some pretty significant advantages with the Jets v5 approach.
Test Lambda Function
Let’s test the Lambda function manually with the Lambda Console built-in Test functionality. For the event, you need a payload that mimics what the APIGW service would send to the Lambda function. Here’s a minimal example:
{
"path": "/posts",
"httpMethod": "GET",
"headers": {
"Host": "foobar.execute-api.us-west-2.amazonaws.com"
}
}
After you click Test, you’ll see a “Executing function: succeeded” message with a link to the logs.
Clicking on the logs link takes you to the CloudWatch Logs Console. It shows all the Log Streams for the Log Group for the Lambda Function. Clicking Search Log Group and filtering by 1m or 30m is an easy way to see the logs.
Testing with the Lambda console is a bit of a pain because we need to figure out the event payload structure. See Debug Event Payloads for more example payloads. We’ll test with curl next.
Testing with Curl
It’s more traditional to test with curl. We’ll go through a few examples.
To get the APIGW endpoint, you can use the jets url
command.
❯ jets url
API Gateway Endpoint: https://2bmdurd1ra.execute-api.us-west-2.amazonaws.com/dev
Grab that value and store it in a variable
❯ export URL=https://2bmdurd1ra.execute-api.us-west-2.amazonaws.com/dev
Tip: You can also grab the url with this export URL=$(jets url --format json | jq -r '.api_gateway_endpoint')
We can now curl like so:
❯ curl -s $URL/posts | jq
[
{
"id": 1,
"title": "Post 1",
"body": "Body 1",
"published": true
},
{
"id": 2,
"title": "Post 2",
"body": "Body 2",
"published": true
}
]
Note, the timestamps have been removed from the shown output for conciseness.
Curl Commands Cheatsheet
We can use the similar commands we used earlier with Local Testing. Here’s an example data.json we can use:
data.json
{
"post": {
"title": "Post 3",
"body": "Body 3",
"published": true
}
}
Here’s a cheatsheet of curl commands.
curl $URL/posts # posts#index
curl -X POST --data @data.json $URL/posts # posts#create
curl -X PUT --data @data.json $URL/posts/3 # posts#update
curl -X DELETE $URL/posts/3 # posts#destroy
Next, we’ll make some updates and do more testing.