https://serverless-stack.com/ logo
Join Slack
Powered by
Sorry for sending too many questions, but I’m tryi...
# sst
a
Sorry for sending too many questions, but I’m trying to migrate my project structure from SLS to SST and can’t find examples or recommendations. My current SLS structure is…
Copy code
services
- apiGateway -> defines root for /tasks + custom authorizer function -> this uses REST API
- tasksApi -> defines functions for /tasks + references API GW defined above from CF resources
- surveyApi -> defines functions for /tasks/{id}/surveys + references API GW defined above from CF resources
So my idea is to migrate these 3 projects into 3 separated SST projects / stacks.
Copy code
services
- main -> defines MainStack -> contains the API root + Authorizer
- tasksApi -> defines TasksApiStack -> contains functions + references MainStack (how?)
- surveyApi -> defines SurveyApiStack -> contains functions + references MainStack (how?)
Is there any recommendation or best practices on how to do this? Should I use this structure of separated services, or should I move into 1 single SST project with many-stacks?
f
@Adrián Mouly, sorry for not documenting this better.
Yo @Jay let’s do a call first thing in the morning and put a migration example together.
@Adrián Mouly So definitely 1 SST project with multiple stacks.
There are 2 migration strategies for API endpoint. Let me describe both, and you can see which one works for you better.
Strategy 1
1. Move 1 stack at the time, ie. start with 
surveyApi
. So, you’d first create a new 
surveyApi
stack in the SST app, and it will import ur existing REST API, and add ie. 
/tasks/{id}/surveys_new
2. Then change your frontend to point to 
/tasks/{id}/surveys_new
3. After no more requests are hitting 
/tasks/{id}/surveys
, you can safely remove the 
surveyApi
SLS service 4. Follow the same strategy to move over the other services.
Strategy 2
1. Create a new Api in SST app, and proxy all the routes to ur existing REST API. 2. Then switch your frontend to call the new Api domain. Everything should work as before since all requests passes through the new Api. 3. Then you can start adding 
/
, 
/tasks
, 
/tasks/{id}/surveys
routes to the new Api. As each route you add, the new Api will now handle it’s request, while all unhandled routes get proxied to the old REST API.
Let me know which strategy makes more sense to you. And I’m willing to go into more details.
Btw, some ppl choose Strategy 2 b/c it lets them to recreate the Api using HTTP API.
a
Thank you @Frank, I’m going to think about this. My project structure has been made following this architecture that you guys created: serverless-lerna-yarn-starter
@Frank for reference, if this helps to create better documentation… I’ve been using the following projects that you guys created, one inside the other: Repo level -> serverless-lerna-yarn-starter Project level -> serverless-typescript-starter
f
Yup got it! I just updated the issue with what we need to cover in the Lerna+Yarn starter.
Having a recommended setup is pretty important. I will get to it asap https://github.com/serverless-stack/serverless-stack/issues/446
a
Looking to use that 😍 .
Thank you @Frank.
f
Hi @Adrián Mouly, I put together an SST repo together using Lerna and Yarn workspaces https://github.com/serverless-stack/sst-lerna-yarn-starter
It’s very raw, and I need to write up the README.
The repo is fully working, and I was not able to reproduce the linting issue u mentioned above.
a
OMG.
Going to check it.
Thanks @Frank for making extra effort.
Going to provide feedback on it too.
@Frank is the repo private? I’m getting 404.
f
Oops… should be public now!
a
Ok I see it now.
Thank you.
@Frank I see all the files are 
.js
, can we do something with TS?
Not sure why tests are 
.ts
but the rest of the code is 
.js
.
f
Hey @Adrián Mouly ah yeah it was created in .ts originally (and worked fine). Then I converted it to .js.
Maybe we should have both versions up.
a
Yeah I think so.
2 Views
Open in Slack
PreviousNext
Powered by