potentially dumb question: do I have to run `yarn ...
# help
s
potentially dumb question: do I have to run
yarn deploy
after stopping the
yarn start
process? any changes I’ve made during the debug process are already live anyway.. functions, at least. or does
yarn deploy
unhook the stubs & other magic needed to run stuff locally?
t
It's the latter, yarn deploy is "real" deploy and will deploy the real code instead of stubs
s
got it. so if I ran
yarn start
and then nothing after that.. people using the application would probably run into issues since it’d be trying to run code on my machine?
not that you should ever do
yarn start --stage prod
😄
t
yep haha
s
I wonder if either the docs should explain the bit about needing to run a deploy after live debug mode. or when you hit ^C, it makes it clear that you really need to deploy
t
Ah yeah that's a good point we can clarify that. Working on a process so we get around to these doc updates so we'll be able to address these things soon
s
I’m sure you guys have your hands full 🙂
d
fyi I had this question at first as well.
t
Curious about your workflow for this, what kind of environment do you need to switch between local debugging and normal? I actually go to the other extreme and have 2 environments even for my personal stacks, one always for local debugging and one always for a normal deployment
Copy code
"sst:start": "sst start --stage live",
    "sst:deploy": "sst deploy",
s
yeah, it may be a non issue really. I went with the 1-developer-per-AWS-account setup. so devs are always just using the “dev” stage, 100% isolated.. so I suppose they don’t really need to deploy
t
yeah that's what I have as well, the reason I ended up with 2 stages per developer was to allow sharing a link that other people can look at without their computer being up
Not common but kinda n ice to have
s
but if you had just one stage, dev, and did
yarn deploy
, wouldn’t that allow others to look at things? since deploying unhooks the stubs/websocket connections to the dev’s local machine?
t
Yeah it would, the reason I like having them seperate is it's slower to unhook/rehook when you want to switch back and forth
And it's nice to have a fixed url that'll always work even if an engineer forgets to unhook
s
that’s true. although I noticed the API URL doesn’t change between start mode & deploys
so when I run
yarn start
and work on a function, it’s modifying the deployed version
t
Yeah it'll stay consistent if you go between start/deploy
Basically I chose to give every engineer 2 stacks, one that's always hooked locally, and one that's never hooked locally. The latter won't get used often, just when they want to share their work. A lot of this is pointless if you setup feature environments for PRs
s
I see. I’m still trying to figure out how our setup is gonna work. obviously for the front end, devs will run that locally, and can set the API URL using .env.development.local or whatever, and point that to the dev SST in their AWS account. the tough part is, when they open a PR for the front end, it auto-deploys that to a temporary URL,
<http://pr-xxx.app.com|pr-xxx.app.com>
. I haven’t worked out how that will point to their dev setup yet
t
Yeah this is a classic problem when be/fe is decoupled, where to point FE for PR branches
In a monorepo you can just deploy the backend along with the frontend even just for frontend changes. If the repos are seperate the FEe will need to indicate what version of the backend to connect to. If your team doesn't operate super full stack this can point to a
master
version of the backend. But if changes tend to be with both repos you'll need to allow someone to override that