https://serverless-stack.com/ logo
Join Slack
Powered by
another question about devs working on Lambda func...
# help
s
another question about devs working on Lambda funcs in their own sandboxes: one of the issues with the usual way of working w/ serverless is that while you have stages like dev, prod, etc.. it becomes tricky for multiple devs to work on the same Lambda functions, because you’d wind up deploying over each other’s work. how would this work with SST? if I do 
yarn start
, I see I get a debug stack spun up. but what if another dev also runs 
yarn start
? how do we test in isolation? and (probably a tougher question to answer), how would a dev running either a local instance of a Vue app (or deployed to a preview branch) point that Vue app to use their debug/test API?
well, I should RTFM 😉 looks like this answers some of my questions: https://docs.serverless-stack.com/live-lambda-development
j
s
separate AWS accounts seems overkill. not to mention, devs wouldn’t have access to our core stacks (database, auth, etc) that are not spun up for each dev
the 
--stage dev-name
approach seems feasible
and then I suppose they’d just set the Vue app’s API URL to point to their own API Gateway w/ their stack
@Jay I gotta say, I was blown away by how easy it was to set up an HTTP API w/ a custom domain + SSL! with Serverless Framework, it required the serverless-domain-manager plugin and some extra setup. a little clunky
j
Yeah the separate account this is more of an organizational choice. Some folks do that outside of the context of SST, so that makes sense for them.
That’s really awesome to hear!
s
love what you guys are doing. and it seems like SST should be pretty well future-proofed since it depends on CDK, yeah?
j
Yeah CDK definitely feels like the way the industry is headed.
It makes sense for how we want to design SST, something that’s easy to get started but completely configurable. https://docs.serverless-stack.com/design-principles#progressive-disclosure
s
@Jay and as I mentioned in my other thread above.. it looks like SST encourages a monorepo setup? so we would have one repo/project with several stacks within (e.g. one stack for our core services that everything else depends on - auth, DB, buckets; a stack for the API, a stack for a Stripe webhook handler, etc)?
j
We need to write something up about this but the general progression I see is: “One app w/ one stack” > “One app w/ multiple packages” > “One app w/ multiple stacks” > “Multiple apps w/ multiple stacks”. @Frank shared something about this as well https://serverless-stack.slack.com/archives/C01UJ8MDHEH/p1627446256251200?thread_ts=1627427616.242500&cid=C01UJ8MDHEH. And here’s an example of the multiple package approach https://github.com/serverless-stack/lerna-yarn-starter.
s
thanks Jay, that’s super helpful! that repo is pretty much how I think we’d structure our application
Open in Slack
PreviousNext
Powered by