https://serverless-stack.com/ logo
Join Slack
Powered by
I've come across an interesting behavior when usin...
# help
s
I've come across an interesting behavior when using the 
customDomain
setting on the API Construct
I created a custom domain to serve my development api (dev-api.<mydomainname>.com, which worked well. However, I've noticed that the domain is pointing to the websocket endpoint that is created when I use 
sst start
which, is a cool behavior in development, but not what I want when the API is deployed. I wonder if I misunderstood something about the 
customDomain
feature
I'm wondering if this is a side effect of running 
sst start
after configuring the customDomain, instead of running 
sst deploy
f
wow.. really?! that’s pretty hard to believe..
s
I'm sure I did something wonky to procure this situation
This custom domain existed at one point before I used SST
using serverless-domain-manager in my sls app
wanting to move things over to SST, I removed the custom domain from API gateway
and defined the customDomain in SST on my API Construct
f
right yeah
I created a custom domain to serve my development api (dev-api.<mydomainname>.com, which worked well
u mean dev-api.domain.com worked for you after u configured customDomain in SST?
s
I deployed the SST app to my development environment in seed.run
That's correct
f
did that work after you did 
sst deploy
or 
sst start
?
s
but by "working", I mean it was tunneling back to my dev environment via websockets
once I saw everything work locally (
sst start
only), I configured seed.run to deploy the app
which was the first time 
sst deploy
was run
then, something tried to hit my dev-api.mydomain.com endpoint, which failed
looking at the logs, I saw websocket error messages
Copy code
{
  "errorType": "Error",
  "errorMessage": "Debug client not connected.",
  "stack": [
    "Error: Debug client not connected.",
    "    at receiveMessage (/var/task/index.js:153:13)",
    "    at WebSocket._ref.ws.onmessage (/var/task/index.js:83:7)",
    "    at WebSocket.onMessage (/var/task/node_modules/ws/lib/event-target.js:132:16)",
    "    at WebSocket.emit (events.js:314:20)",
    "    at Receiver.receiverOnMessage (/var/task/node_modules/ws/lib/websocket.js:825:20)",
    "    at Receiver.emit (events.js:314:20)",
    "    at Receiver.dataMessage (/var/task/node_modules/ws/lib/receiver.js:437:14)",
    "    at /var/task/node_modules/ws/lib/receiver.js:394:23",
    "    at /var/task/node_modules/ws/lib/permessage-deflate.js:308:9",
    "    at /var/task/node_modules/ws/lib/permessage-deflate.js:387:7"
  ]
}
since I don't use websockets in my API, I suspected it was trying to hit my dev environment
which was not running at the time
I fired up my dev environment with 
sst start
and hit the API endpoint, and it worked
lol
f
Oh I see… it seems after you deployed through Seed, when u try to hit the API endpoint, it still tries to connect to your local
s
right
that was the first and only time 
sst deploy
was called
f
I see.. what stage were u running 
sst start
with?
like did you pass in a 
--stage
option when u run 
sst start
?
s
I did not, I just run 
yarn start
, which is executing 
sst start
with no args
although...
it looks like the stage defaults to 
dev
f
i see.. can u send me ur sst.json?
s
Copy code
{
  "name": "signup-and-run",
  "stage": "dev",
  "region": "us-west-2",
  "lint": true
}
f
can you also give me your Seed org name?
s
sethgeoghegan
f
Thanks, let me take a look at what is going on
s
Thanks!
f
hmm.. from the build log, it seems the lambda were built and deployed fine
do you have a minute to try something now?
s
sure
f
If you could stop 
sst start
then trigger a deploy through Seed
let’s see if it still trys to connect to your local
s
deploying now
f
yup
s
build was successful
f
aight.. can you make a request to your api?
s
ahh, API appears to work properly now
hmm, that's a fun one
f
hmm.. yeah that was weird..
but yeah if you see it again, let me know.. we can jump on it if i’m around
s
Thanks for the help! I'm wondering if this came about because I did an SST start with the customDomain before ever deploying the code. Although, I'm content not to understand for now 🙂
f
hmm that shouldn’t matter.. so the ONLY difference between an 
sst start
and 
sst deploy
is that:
when running 
sst start
SST doesn’t deploy your real lambda code, it deploys some stub code to send/receive websockets to your local
and when running 
sst deploy
SST deploys your real lambda code
s
This is interesting, I did another 
sst start
to fire up my development environment, and things appear to be back in the prior state
f
yeah… when you run 
sst start
you are pretty much doing a new deployment (with stub lambdas)
s
dev-api.mydomain.com is back to routing to my local development environment
and when I kill the process, dev-api is still trying to reach my development environment
f
Yeah dev-api.mydomain.com is always routing to your Lambda.
and if you run 
sst start
, the stub lambdas are deployed and requests are send to your local
until you run 
sst deploy
again, the stub lambdas are not getting replaced with real Lambdas
so it will keep sending requests to your local
you need to run 
sst deploy
again to deploy the real lambdas
s
Ah, ok, so this is expected behavior. It's not the case that the requests to my customDomain will always point to deployed lambdas
I suppose that makes sense
just wasn't my mental model of what was happening
f
I see the confusion
i think ur mental model actually makes a lot sense
if you kill 
sst start
it should work normally
“I shouldn’t need to run sst deploy again to switch to the normal state”
s
Yeah, I'm thinking of when I have a production setup. I want api.mydomain.com to always point to production resources
which I think I carried over to how i thought of my development environment
f
oh wait.. the api.mydomain.com IS ALWAYS pointed to your production Lambda functions
Just that 
sst start
replaced the underlying function code, so your production Lambda functions are sending the requests to your local
s
That makes sense. I guess I spent so long in my dev environment, I never dabbled with the deploy process until recently
I need to be mindful about what state my environment is in at any given time. The switching back and forth between local lambdas and deployed lambdas was not obvious to me. I had mistakenly thought that ending 
sst start
stopped the routing to my dev environment.
f
Your thought is legit.. that’d be the more natural behavior.. i’m going to talk to the team about this
s
"you'll never guess what this guy was trying to do..."
😆
f
LOL user is always right
r
Sounds like a bad idea if you can run sst start --stage prod and replace your api with stubs 🤣
f
Ah good point. We should probably let u defined a list of stages that are safe to run sst start on.
s
@Roger Rajaratnam one of the reasons I have separate production and development accounts and do not have credentials for the production account anywhere on my laptop 😆
r
@Seth Geoghegan That’s sounds like sensible practice.
3 Views
Open in Slack
PreviousNext
Powered by