Fixes to facilitate keeping private + public repos in sync

[djoksimo]

• Changes that should be applied in both this repo and the private fork one.
• The private repo uses more than just /proxy/ endpoints.

[djoksimo]

turns out this wasn't necessary after all and impeded local development against http.

[devinmorgan]

Nice!

[devinmorgan]

So I think there is a bit of a design question going on here around what URL information should be centralized in EnvConfig vs can live inside of the buildVaultUrl() method.

The proposed change to move proxy/ to .addPathSegment() would make a lot of sense if we anticipate or already use multiple paths for the vault.joinforage.app host. For example:

• vault.joinforage.app/some_path
• vault.joinforage.app/another_path

In that world, the "common part" to would be vault.joinforage.app and it would make sense in my mind that specific buildVaultUrl()s would customize the /path portion for their own needs (e.g. adding /some_path or /another_path)

However, if all current and foreseeable usages of vault.joinforage.app are always vault.joinforage.app/path, then I think we're decentralizing information a portion of the "common part", which (albeit slightly) hurts readability (now you need to go to two files to understand that we're hitting vault.joinforage.app/path instead of just one file EnvConfig).

So, my two cents are:

1. 🆗 deleting of the .scheme("https")
2. 🚫 let's no include the changes that add .addPathSegment("proxy"), unless we use multiple paths on vault.joinforage.app

[devinmorgan]

Nice!

[djoksimo]

So I think there is a bit of a design question going on here around what URL information should be centralized in EnvConfig vs can live inside of the buildVaultUrl() method.

The proposed change to move proxy/ to .addPathSegment() would make a lot of sense if we anticipate or already use multiple paths for the vault.joinforage.app host. For example:

• vault.joinforage.app/some_path
• vault.joinforage.app/another_path

In that world, the "common part" to would be vault.joinforage.app and it would make sense in my mind that specific buildVaultUrl()s would customize the /path portion for their own needs (e.g. adding /some_path or /another_path)

However, if all current and foreseeable usages of vault.joinforage.app are always vault.joinforage.app/path, then I think we're decentralizing information a portion of the "common part", which (albeit slightly) hurts readability (now you need to go to two files to understand that we're hitting vault.joinforage.app/path instead of just one file EnvConfig).

So, my two cents are:

1. 🆗 deleting of the .scheme("https")
2. 🚫 let's no include the changes that add .addPathSegment("proxy"), unless we use multiple paths on vault.joinforage.app

@devinmorgan We use other paths of vault.joinforage.app (besides /proxy/) in the private repo, which is why I made this PR.

[devinmorgan]

So I think there is a bit of a design question going on here around what URL information should be centralized in EnvConfig vs can live inside of the buildVaultUrl() method.
The proposed change to move proxy/ to .addPathSegment() would make a lot of sense if we anticipate or already use multiple paths for the vault.joinforage.app host. For example:

• vault.joinforage.app/some_path
• vault.joinforage.app/another_path

In that world, the "common part" to would be vault.joinforage.app and it would make sense in my mind that specific buildVaultUrl()s would customize the /path portion for their own needs (e.g. adding /some_path or /another_path)
However, if all current and foreseeable usages of vault.joinforage.app are always vault.joinforage.app/path, then I think we're decentralizing information a portion of the "common part", which (albeit slightly) hurts readability (now you need to go to two files to understand that we're hitting vault.joinforage.app/path instead of just one file EnvConfig).
So, my two cents are:

1. 🆗 deleting of the .scheme("https")
2. 🚫 let's no include the changes that add .addPathSegment("proxy"), unless we use multiple paths on vault.joinforage.app

@devinmorgan We use other paths of vault.joinforage.app (besides /proxy/) in the private repo, which is why I made this PR.

Can you update the PR description to communicate this? Specifically, I'd love to better understand which paths we use against vault.joinforage.app because this PR seems to only touch /proxy. And, if we do touch other paths besides /proxy/, should edits to that be made in this PR as well? From what I can tell, this PR touches /post. Thanks in advance!

[devinmorgan]

Nice!