https://serverless-stack.com/ logo
Join Slack
Powered by
Is there any example of this setup? SLS + SST + SE...
# seed
a
Is there any example of this setup? SLS + SST + SEED + Monorepo?
f
Hey @Adrián Mouly, do you have multiple SST apps in the repo? or just 1 (ie. sst.json at the root)?
a
1 sst in the root, but 1 stack for each service.
How should I build this in a way that SEED can show me each individual service?
The other problem I have is… each of my services has different NPM dependencies… then I don’t want to have a shared package.json for all the functions.
Maybe I will need to create 1 SST for each service….
f
Ah I see.. there might be some confusions, and we haven’t done a good job documenting it.
How should I build this in a way that SEED can show me each individual service?
An SST app shows up as 1 service on Seed. Each stack doesn’t show up as a separate service on Seed. If you go to the 
Resources
tab on Seed, and expand the SST service, you can see there are multiple stacks within the service.
1 sst in the root, but 1 stack for each service.
It works. But this structure works better with incremental service deploy algorithm. So when you push changes in 
sst/
, Seed knows only the 
sst
service needs to be deploy, and will skip 
slsServiceA
and 
slsServiceB
.
Copy code
/
  services/
    slsServiceA/
      serverless.yml
    slsServiceB/
      serverless.yml
    sst/
      sst.json
@Jay I think there are some confusion around the term 
service
in the https://github.com/serverless-stack/lerna-yarn-starter repo vs the 
service
on Seed.
The entire SST app is 1 single service on Seed.
a
Ok.
So my problem is.. I want to deploy 1 single 
service
from SEED, sometimes… and with SST I don’t have a way to do that?
With service I mean… for example, a single API.
Conceptually speaking a service, as a micro-service.
I have micros like… Tasks API, Users API, Surveys API … all of those should be able to be promoted/deployed individually from SEED.
I’m already doing that with SLS today.
@Frank my use-case makes any sense to you?
For example… sometimes I have a change for Task API, that lives on a feature-branch, and I want to promote that single service to PROD.
I don’t know what to do 😞
f
Ah yeah that makes sense.
btw.. if you have ie. 5 services in the SST app, and only 1 changed, SST will skip deploying the rest 4 services.
So in the example above, is the Task API the only service that’s changed in the feature-branch?
a
Could be, but could be that is not.
It doesn’t feel well to move from multi-service in SEED into mono-service in SEED.
It just doesn’t feel right.
I mean, I been using SLS in the current setup displayed above and works well for us.
I would like to have something similar with SST.
With current setup I feel like I have more control, to be honest.
f
Yup, I see your point! With SLS, you have a handful of services and Seed is tying them together in the pipeline. But with SST, you just have 1 app, and you want visibility into each service/stack.
a
Yeah 😩
So… what if I create 1 SST for each of my services? is that right? or I’m following an anti-pattern?
One of my challenges is that I have 1 Gateway that is shared across multiple services… I’m not sure if SST is going to help me on that scenario.
Like… heyYabble-gateyway -> contains the gw • hy-tasks -> uses that gw • hy-surveyRes -> uses that same gw
This is my phase structure.
Would I be able to do the same with SST apps, one for each of those boxes?
f
Just gave this some thought. You can have 1 SST app with multiple stacks, or have multiple SST apps. It depends on tightly coupled these stacks are. A benefit of having multiple stacks in 1 SST app is that it makes cross-stack references easier. And SST is able to figure out the order to deploy the stacks based on the cross-stack references. On the flip side, if the stacks are not tightly couple, especially if different developer/team takes ownership of different stacks, it makes sense to split them up. This way, when you run 
sst start
, it let’s you work on only the stack(s) in your app.
a
I see, yeah.
These stacks has some relation… but at the application level… like.. Service1 makes a call to Service2 over HTTP.
I was thinking to use cloud-map to do service-discovery.
Then, each of the services registers on cloud-map, and they talk with each other based on the discovery service.
I think that this can provide me some level of abstraction between each of them… and also allows me to deploy or manage them on Seed individually.
f
I see. Yeah but I think you should pick 1 SST app vs multiple SST apps based on how you foresee them working together; not based on the limitation to Seed’s UI. I’m sure as we get more feedback, Seed’s UI for SST app will change.
a
Ok.
Yeah kind of a hard choice to make.
Because, today, with SLS.. I have a “main project” which creates a Bus and a Gateway.. then shares those with CF Output and shared with Service1 and Service2.
I think having 1 stack would make that easier… but also couple them.
Feeling like doing 1 SST is going to couple them, and today the only connection point is a Bus, an SQS, or an HTTP Path etc.
f
Oh a quite note on the side, when you name your SST app/stack, you can use this trick. Say you decide to create 3 SST apps, name them like this in your `sst.json`: • name the 1st app 
yabble-api
and name the stack 
main
• name the 2nd app 
yabble-tasks
and name the stack 
main
• name the 3rd app 
yabble-survey
and name the stack 
main
When you deploy to the 
dev
stage, this will create 3 CloudFormation stacks: • 
dev-yabble-api-main
• 
dev-yabble-tasks-main
• 
dev-yabble-survey-main
And if 1 day u decide to restructure them into 1 SST app, you can name the app 
yabble
and it has 3 stacks: 
api-main
, 
tasks-main
, and 
survey-main
This way, the underlying CloudFormation stack names remain the same. And it will be a smooth transition.
a
That’s interesting.
I like the idea, I think I got to that point just as a coincidence, haha.
I named all the stacks as “stack”.. 😂
But yeah I like it, thank you!
f
Np! Let me know how it goes.
a
Yeah, for sure!
15 Views
Open in Slack
PreviousNext
Powered by