You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@eyalb181 raised a concern, that in mirrord v1 we defaulted to listen on port 80 remotely, regardless of the local port used.
This was due to technical limitations (we couldn't let the user really run the application on port 80, like we can with v2) but also has a very fluent experience, as the developer doesn't need to change the port listened in their app to work locally with mirrord (as when they develop locally they are most likely to use a port different then 80, which is what would probably be configured in staging/remote).
In my opinion, we state that we run the local process in the context of the remote pod, and it's very cool that we literally do that, so port listened locally is the same listened remotely. I fear that by adding a "magic" change (that might ease newcomers) we will create some sort of a quirk that many developers will eventually turn off. Especially when we bring in #25 and then it'll probably set the same port as the remote environment, as listened ports are usually environment controlled.
We decided to leave the experience of v2.0 as is - if the user listens on port 80 it listens remotely on 80, and based on feedback on our v2 release candidate we will decide whether to change it or not.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
@eyalb181 raised a concern, that in mirrord v1 we defaulted to listen on port 80 remotely, regardless of the local port used.
This was due to technical limitations (we couldn't let the user really run the application on port 80, like we can with v2) but also has a very fluent experience, as the developer doesn't need to change the port listened in their app to work locally with mirrord (as when they develop locally they are most likely to use a port different then 80, which is what would probably be configured in staging/remote).
In my opinion, we state that we run the local process in the context of the remote pod, and it's very cool that we literally do that, so port listened locally is the same listened remotely. I fear that by adding a "magic" change (that might ease newcomers) we will create some sort of a quirk that many developers will eventually turn off. Especially when we bring in #25 and then it'll probably set the same port as the remote environment, as listened ports are usually environment controlled.
We decided to leave the experience of v2.0 as is - if the user listens on port 80 it listens remotely on 80, and based on feedback on our v2 release candidate we will decide whether to change it or not.
Beta Was this translation helpful? Give feedback.
All reactions