https://serverless-stack.com/ logo
Join Slack
Powered by
has anyone figured out how to set up an environmen...
# general
s
has anyone figured out how to set up an environment where the front end has preview branches deployed? my old setup was obviously built for a single developer (or two), but it was: most resources had one dev instance (bucket-dev, database-dev, etc) and a prod instance. when I’d open a PR, it deploys to pr-xxx.(domain), and that would use 
.env.staging
which pointed to the dev instances of resources, dev API endpoint, etc. now that I’m using SST w/ multiple devs in their own AWS accounts, I’m not really sure how to set this up. if a PR is opened and a preview branch is deployed, how will it know where to point for the non-production resources it depends on?
t
I tend to build a full environment for each PR so there's no shared resources. But if there are I do this through ssm params pointing at resources
s
yeah, that’s what I mean.. there shouldn’t be shared resources. so for example, when a developer opens a PR and pr-110.myapp is created.. how does it know how to set its 
API_URL
env var to point to the right place?
a
I do this sharing resources from the other stacks.
Like 
apiStack
exports the url, and 
webStack
receives it by parameter.
Actually is not exporting, it’s just exposing it with a public attribute.
Due API and Web both are stacks referenced on my 
index.ts
.
s
🤔 I still don’t know how that would work. how would my CI/CD setup deploying the preview branch know what value to use for the API URL?
a
On each PR, I deploy a new Web-UI instance.
You mean for the UI repository?
s
yeah, the front end app. right now it just uses 
.env.staging
with hardcoded API URL, GraphQL URL, etc. but with this multi-dev SST setup, that won’t work .. can’t hardcode those.
if I have 10 developers on the team, then there are potentially 10 different API URLs
a
But your FE app lives in a different repo?
s
yeah
a
So I had the same problem… what I did is.. 1. Before deploying the Stacks, pull FE code from their repo 2. Deploy all the APIs and export their URLs 3. Build the UI, receiving the exported URLs by paramter 4. Deploy the UI
That means I have 1 UI for each PR.
That’s why I’m saying that my SST is also deploying the FE, is the same for you?
I’m following a mono-repo architecture, but having the FE in a different repo, and merging all together on the ci/cd.
s
no, my FE is totally separate repo.. it’s a Vue app. so I don’t think those steps would work for me. like, step #3.. the UI being built in CI/CD has no way to receive the API URLs
a
No, then you can’t follow the PR schema.
For me it’s also another repo, that doesn’t matter.
You can pull from the other repo, and SST will deploy it.
s
ah I see, you’re deploying it using SST
I’m using AWS’s CI/CD
a
If you want to have only 1 FE instance, you can create a Config screen, and they can put the API URL manually.
Well, SST deploys everything for me.
UI, APIs, everything.
You can still do it in your usecase.
s
not sure how, I’ll have to brainstorm on it later
a
Did you check the monorepo repository?
s
which one?
a
Which has example of react app + sst.
The one that Frank built, let me check.
You are going to do this…
Copy code
const service1 = new Service1Stack(app, "service1-stack");
  const service2 = new Service2Stack(app, "service2-stack");
  new WebsiteStack(app, "website-stack", {
    api1: service1.api,
    api2: service2.api,
  });
s
I can’t move my front end into the SST repo though
I dunno if that will work. Vue has its own specific setup.
a
You can clone the repo or use sub-module from git.
s
so then SST deploys the front end.. are you using GitHub Actions for your SST CI/CD?
a
I’m using seed, but should be similar.
SST deploys React apps really easy, but is nothing more than just a helper.
You can do the same steps for vue… creating s3, creating sub-domain, etc etc.
s
interesting
a
If you use React, they already built a helper construct.
Or maybe ask Frank if they plan to build a construct for Vue.
The other solution is what I’ve said… you can create a Config page in your front-end, where the QA or developer can put the API_URL manually, but that requires some team-agreements.
Or maybe could be a query parameter, and the CI/CD generates it somehow.
Those are some of the ideas, due I’ve been thinking the same as you are, couple of weeks ago.
s
that’s true, maybe in staging mode, the front end can ask for the API URL to be input.. rather than rely on the env var
I’ll have to look at all my options and see what’s doable, and not too time-consuming to set up
thanks for the ideas 🙂
a
Exactly!
f
Hey guys, just wanted to chime in with what ppl are doing on Seed, but should be applicable to any CI.
So the out of the box way would be moving the Vue app into SST, and the 
sst.StaticSite
construct can automatically replace the deployed API URL in ur Vue app.
If u can’t move it into SST, you can export the API URL as 
pr123-api-url
, and in the CI for ur frontend, as long as u know which PR it is, you can import value via AWS CLI.
s
the first scenario could work.. I’m not too hot on the idea of merging front end & back end into the same repo. I can see situations where I’d want to hire strictly front-end or back-end devs, and having the separation is ideal. I dunno if the 2nd scenario would work, since I’m not using Route 53 to assign specific URLs to the dev API endpoint. it’s just the API Gateway default (xxxxxxxxxxxxx.execute-api.us-east-1.amazonaws.com)
AWS Amplify Console (their CI/CD solution) apparently has a way to pull env vars from SSM parameters. so.. I might be able to leverage that to put the API/GraphQL URLs into SSM so the build process can grab them. it’d work as long as two devs didn’t open PRs at the same time, since the build config file can only read from one SSM param
tricky stuff 🤔
t
Yeah this is a classic problem. My recommendation is to merge into the same repo if you're team is submitting prs across frontend and backend. If you get to a place where backend moves independently of frontend you can split things up and have the front usually use a stable release of the backend. You can create a contingency to repoint to a different env through SSM if needed
I've seen people do this with PR tags as well but that's more work
a
No need to merge repos, you can use git submodules or clones during build time.
The final effect is the same.
Open in Slack
PreviousNext
Powered by