Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat!: Use / as the default path for the first app #748

Merged
merged 1 commit into from Mar 17, 2020

Conversation

kohidave
Copy link
Contributor

@kohidave kohidave commented Mar 17, 2020

Currently, each Load Balanced Web App is created and is asigned
a path of /{app name} on the ALB. This makes sense, but there
are some gotchas.

First, your app has to be prepared to handle paths of /{app name}.
This is probably a little unlikely unless your lucky. Most apps
expect to be run as if they are receiving requests on the root
path / (see every tutorial ever) 😂

What this change does is it defaults your first app to being hosted
on / but at the last evaluated rule. This is probably a more
intuitive default (and we've gotten some customer feedback on this).

Subsequent apps still have to use the path based route.

So:

ecs init --app front-end # produces a URL of http://my-lb.us-west-2.amazon.com/
ecs init --app api       # produces a URL of http://my-lb.us-west-2.amazon.com/api/

This change adjusts the priority generator so that "/" is evaluated last.

Customers are still free to change the path in their manifest. They can use
the special "/" path to signify that they want this to be their default route.

Why didn't you just use the default action ?

One kind of odd thing we did here is give the "/" path a really high rule
priority, rather than just setting it as the default route. There are a few
reasons we did that.

  1. It's a bit messy as the default route action is managed in the environment stack
    and there's really not a great way to update it.
  2. If a customer changes their app to use a named path, rather than the default "/"
    path - it will only require a dpeloyment of the app, rather than then the app
    AND the env (which is a different stack).

This change also has some other E2E bug fixes in it (like setting the healthcheck
path by default).

Fixes #663

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@kohidave kohidave added area/manifest Issues about infrastructure-as-code templates. area/svc Issues about services. labels Mar 17, 2020
@kohidave kohidave added this to In review in Sprint 🏃‍♀️ via automation Mar 17, 2020
@kohidave kohidave changed the title feat!: Use / as the default path for new apps feat!: Use / as the default path for the first app Mar 17, 2020
Copy link
Contributor

@efekarakus efekarakus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

cf-custom-resources/lib/alb-rule-priority-generator.js Outdated Show resolved Hide resolved
Currently, each Load Balanced Web App is created and is asigned
a path of "/{app name}" on the ALB. This makes sense, but there
are some gotchas.

First, your app has to be prepared to handle paths of "/{app name}".
This is probably a little unlikely unless your lucky. Most apps
expect to be run as if they are receiving requests on the root
path "/" (see every tutorial ever) 😂

What this change does is it defaults your first app to being hosted
on "/" but at the last evaluated rule. This is probably a more
intuitive default (and we've gotten some customer feedback on this).

Subsequent apps still have to use the path based route.

So:

```sh
ecs init --app front-end # produces a URL of http://my-lb.us-west-2.amazon.com/
ecs init --app api       # produces a URL of http://my-lb.us-west-2.amazon.com/api/
```

This change adjusts the priority generator so that "/" is evaluated last.

Customers are still free to change the path in their manifest. They can use
the special "/" path to signify that they want this to be their default route.

__ Why didn't you just use the default action ? __

One kind of odd thing we did here is give the "/" path a really high rule
priority, rather than just setting it as the default route. There are a few
reasons we did that.

1. It's a bit messy as the default route action is managed in the environment stack
   and there's really not a great way to update it.
2. If a customer changes their app to use a named path, rather than the default "/"
   path - it will only require a dpeloyment of the app, rather than then the app
   AND the env (which is a different stack).

This change also has some other E2E bug fixes in it (like setting the healthcheck
path by default).
@kohidave kohidave merged commit 7ccb6ca into aws:master Mar 17, 2020
Sprint 🏃‍♀️ automation moved this from In review to Pending release Mar 17, 2020
@kohidave kohidave deleted the slash-by-default branch March 17, 2020 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/manifest Issues about infrastructure-as-code templates. area/svc Issues about services.
Projects
Sprint 🏃‍♀️
  
Pending release
Development

Successfully merging this pull request may close these issues.

Allow setting "/" path with the lowest priority
3 participants