Ruby on Jets 5.0 Release: Improvements Galore

Jets
1

Jets 5 has been released Ruby on Jets 5.0 Release: Improvements Galore - BoltOps Blog

The release has many improvements. Details in the blog post.

2 Likes
2

Congrats on the release - The single lambda function is a huge huge update. I am upgrading from 3.x to 5.x and running into quite a few issues that are not documented as far as I can tell and I’m having to dig through the code to figure out the changes e.g.

  • Jets::Application.default_iam_policy becomes config.default_iam_policy
  • config.events.dynamodb.table_namespace = false … having to set this to false otherwise it automatically tries to namespace DynamoDB tables that were not previously namespaced

I’ll continue to add more as I find them but it is definitely a painful upgrade.

3

Also, what happened to config.session.options?

4

RE: config.default_iam_policy

Ah yes. Missed that. Thinking may add that as a warning to the jets-upgrade go script. Any PRs are also appreciated. No sweat either way. Thanks!

RE: config.events.dynamodb.table_namespace = false

Ah. Yes. That’s related to Dynomite 2.0 Dynomite 2.0 Release: DynamoDB ActiveModel ORM - BoltOps Blog

RE: config.session.options

That changed to config.session_options. Just updated the docs.

Thanks for the posts. Any jets-docs PRs are also appreciated. Again, no sweat either way. Thanks!

Yup. It’s quite difficult to catch all the scenarios. Will also try to update these docs as we go along:

5

Thanks @tung … I’ll PR anything else I come across.

1 Like
6

Also the following doesn’t seem to work any more

class List < Jets::Stack
  sqs_queue("my_tasks", message_retention_period: 3600, visibility_timeout: 120)
end

sqs_event(ref("my_tasks"), batch_size: 1)

What works is sqs_event("!Ref MyTasks", batch_size: 1)

7

For a Blue / Green deployment, is it necessary to take down the old stack with the domain before transferring the domain over to the new one? Do you have any recommendations for how best to do this?

8

RE: sqs_event(ref(“my_tasks”), batch_size: 1)

Bummer. Sounds like a bug. Will take a look once get a moment.

RE: For a Blue / Green deployment, is it necessary to take down the old stack with the domain before transferring the domain over to the new one? Do you have any recommendations for how best to do this?

It depends how the APIGW Custom Domain was set up. If you set it up so that you have something like CloudFront in front then you can deploy another stack.

JETS_EXTRA=2 jets deploy
  1. Test it all ahead of time.
  2. Once QA looks good.
  3. Switch the CloudFront origin to it.
  4. Then delete the old stack.

That’s how I do big deploys when it’s merited. Note: The jobs would run on both stacks so I would comment out jobs on the new stack until really close to ready.

I made a few videos covering this:

They’re currently unlocked with a free account. So enjoy!

9

RE:

Fixed in https://github.com/rubyonjets/jets/pull/697 Thanks for the report.

1 Like
10

Another issue with routing and correct me if I’m wrong here

Example:

resources :accounts, only: %i[index update] do
  get 'users', to: 'users#index'
end

is supposed to yield:

| accounts                       | GET    | /accounts                   |
| account                        | PUT    | /accounts/:id               |
| account                        | PATCH  | /accounts/:id               |
| accounts                       | GET    | /accounts/:account_id/users |

but instead yields:

| accounts                       | GET    | /accounts       |
| account                        | PUT    | /accounts/:id   |
| account                        | PATCH  | /accounts/:id   |
| accounts                       | GET    | /accounts/users |
11

You’re right. Bummer. That looks like a bug. Will take a look when get a chance. Generally, trying to match the Rails router. There are even specs for it https://github.com/rubyonjets/jets/tree/master/spec/lib/jets/router/dsl/rails_guide Will have to add a spec for that also.

12

Also it might be useful for the cloudfront documentation – putting Cloudfront in front of API Gateway endpoints with IAM auth does not work as the SigV4 host has to match. Basically, when you create the signature it has to match the host of the api gateway and not the cloudfront domain.

13

I see. That’s a bummer. Wondering what’s the workaround. Do you disable IAM at the APIGW level and enable it on the CloudFront level? Haven’t used IAM auth as much.

14

@tung how does one create api endpoints with authorization_type: :none in this new setup? As far as I can tell the one endpoint that does get created to handle all requests is set up with AWS_IAM authorization.

15

I suppose the question here is whether it is even possible in Jets 5.x to use a mixture of authorization_type: :none and authorization_type: :aws_iam in routes? As far as I can tell it is not possible with the single catchall route as it can only be either/or.

16

Okay, finally figured it out on digging deeper.

Setting config.cfn.build.routes = 'one_apigw_method_per_route' uses the multiple api gateway methods to single controller setup vs one method for all routes one_apigw_method_for_all_routes which is the default. Thankfully it is still just one lambda but just configures api gateway a little differently.

This definitely needs to be documented. Sorry for all the spam.

17

Note: one_apigw_method_per_route will likely be removed in the future. It also has some quirks that didn’t have time to fix. It’s a bit of effort to support both. Would like to remove it. It’s one of the reasons why I didn’t document it yet.

At least, wanted to give you a heads up. This will mean that authorization_type will be an all or nothing thing. Or you have to use a custom authorizer lambda function and handle it dynamically.

18

Thanks for the heads up @tung. You’ve put in some pretty impressive work here. I definitely get the all or nothing approach. I have a very rough draft of a custom authorizer to handle :none and :aws_iam/sigv4.