https://serverless-stack.com/ logo
Join Slack
Powered by
hey all! I finally managed to get a working SST + ...
# general
s
hey all! I finally managed to get a working SST + Vite SSR (using Vue 3) stack together! still working on some final polish, but if anyone’s interested in seeing the code (or helping to improve it), reply to this msg.
r
Yes please 😁
r
hey @Sam Hulick interested for sure, i've been working on this as well and have a basic POC without static content yet. I went down the 
vite-plugin-ssr
path, https://vite-plugin-ssr.com/ How did you end up rigging yours up? S3, APIgw and Cloudfront still?
s
it’s not 100% ideal yet. I couldn’t get vite-plugin-ssr working at all, so I went with a vanilla Vite SSR setup I copied from somewhere, and modified. it uses express which isn’t great.. BUT it doesn’t seem to slow down the Lambda much, and express makes it super easy to store static assets in the Lambda itself (so no S3). I’ll eventually rig it to use CloudFront I’ll give you a link to the repo once I’ve pushed my changes & added a to-do list to the README
r
Interesting I went the opposite way. Started with vite ssr and ended up with the plug in. So right now are ya bundling the whole site into a lambda? If there is no s3?
s
correct. client side assets are in the Lambda, and express’s static-site middleware will interpret the Lambda calls for those assets & serve them up. the repeated calls to the Lambda func aren’t great, but once CloudFront sits in front of the HTTP API, that won’t be an issue anymore
r
I gotcha, so when I went in I wanted to stay clear of express and potentially big bundled lambdas, for cold start times. I think the ssr plug in is all working now, I just need to move static assets to s3. Plan is APIgw for the lambda to deal with dynamic ssr stuff, s3 for status assets also thru APIgw. This is pretty much done. Then next up will be local dev, live lambda for both dynamic and local static assets. Hoping to use vite inside the context handler itself in dev mode so no extra commands need to be run during local dev. We will see if it all comes together.
Hope is that this will then also work for remix 🤞
s
yeah, I think S3 + CloudFront makes more sense for static assets. but then there’s that whole step to automate, of copying the assets to S3. not sure of the best way to approach that. the bundle size isn’t that bad actually. barebones Vite SSR w/ express = 3.3MB. could be a bit smaller. it’s easy enough to rip that out once static assets are handled better
r
I think thats one thing we are missing from SST right now, is a Lambda + s3 combo.
s
yeah
r
I think cloudfront should be optional in the mix though. So i am hoping APIGW -> s3 and APIGW -> lambda. So that cloudfront can be more of an optimization
we are all in on cloudflare over here, so would like to keep that option open
s
ah yeah.. not everyone is using CloudFront of course 🙂
r
but if we had a lower level context for lambda + s3 we could do all sorts. even simply express based handlebar templating with some static JSON/videos/images, etc
@Frank or @thdxr I know I bugged ya in DM's about this, but just confirming there is no way right now to hook a bucket construct to a API construct, right? something magic like
Copy code
{
  routes: {
    "GET /public/*": s3Bucket
  }
}
t
Could you use a normal http proxy?
we support forwarding to an arbitrary url though not sure what happens to the path
r
t
yeah I believe the path is forwarded although not entirely sure
r
I am guessing permission would need to be public read for the s3 bucket. Not horrible really, though the other method does keep it all contained in s3 + apigw
t
does apig have direct support for s3?
r
but with less work 🙂
t
ah so it does we can definitely support this, we have a nice framework for this in the upcoming release
r
I believe this is how arc also does their @static stuff
I guess the real trick here would be during live lambda dev, it would be great if the normal socket communication could serve the file from my machine. then when deployed that code is stripped out and its all deployed s3 and lambda
d
you are basically describing Next/Nuxt.js, just as an FYI.
s
not a fan of Nuxt. too bulky, doesn’t play well with Lambda
r
Yeah all of this is in the same world, for sure. heck we are also describing PHP 😛
Whichever way folks like to tinker with requests and also server static content is 👌 with me, but i would love to do it with SST in a nice simple package
d
Specifically the “serving static files from an SSR” part, is essentially the specialty of those frameworks. The normal SSR you guys are shooting for is very comparable to standard PHP, or ASP.NET, or…
s
the static files we’re talking about is the JS/CSS files, not the actual content
the content is fully dynamic
static files, as in, the client-side stuff that gets hydrated
r
Sure, all that fancy stuff can come from a simple foundation though. We simply need a way to say this is static and this is dynamic. Then you could do next, or nuxt, or remix or vite SSR or whatever new thingy happens haha. We could do this now with L@E through cloudfront as well, but thats not as appealing to me, as i mentioned i am not really interesting the overhead of cloudfront. Also I could see this being a handy thing for just a static site and an API that you want to run on the same domain. Just like a 
index.html
, and maybe some CSS and JS if needed. and then a couple API endpoints all running on the same API GW. but when deployed the site is static. Seems like this kind of basic construct could do a lot.
f
Hey guys, just wanted to chime in real quick. I’ve been thinking about this lately. For constructs that we might not be able to get to work on and support right away, this is what I’m thinking: 1. We help however we can to get the use case working, and then write an example to gauge interest. 2. And if we start getting more questions about the example, we will then tweak an existing construct to support the use case, or create a dedicated construct. (^ I didn’t run this thought by the team, @thdxr @Jay do u guys agree?)
t
solidjs's metaframework solid-start is also built on vite ssr
j
Yup that makes sense!
r
@Frank do you all take outside contrib? Is it worth spending some time getting a PR for some kind of basic lambda + s3 + apiGw setup to handle this stuff? Though maybe its best to just get a POC in github for review for an example first, as you mentioned?
t
we definitely do but right now we're doing some huge changes to the codebase for our v1 beta. That'll be out in a few weeks so best to maybe start off of that
r
Oh great, I am guessing "huge changes" like dont even both starting down some of these roads because there will be new fancy paths to take anyway? 🙂
t
haha it's mostly just reorganizing the apis of our constructs, nothing earth shattering
just letting you know you'll have to redo some of the work in a few weeks but the bulk of it probably won't change
r
Alright so still ok to figure out what would need to get pulled together to make this all work. Not like starting from scratch. At this point one could use arc to do these more basic setups though. If ya just need an API, dynamo and a site, you can crank it out pretty dang fast. However the dev flow for SST has sold me, so would be nice to get some of these more basic patterns in as well.
Plus everyone here loves Seed + SST now, I think making any change would cause a riot. 🙂
s
@Ross Gerbasi @Ross Coundon hey guys, it’s up! https://github.com/ffxsam/vite-ssr-sst not sure how clunky it is as far as structure goes.. but it works! you can just work on the Vite app by running 
yarn vite:dev
, or you can fire up the whole SST stack and the Vite app (via HTTP API) by running 
yarn start
r
Fantastic, thanks Sam, I’ll take a look
s
@Ross Coundon 👍 it’s just a start, still needs refinement. if you have time and it benefits you, contributions are definitely welcome.
bah. it’s in a non-working state again 😞 I mean, it works until you include a package that’s intended for Node.js only, like 
@sentry/serverless
. 
yarn vite:dev
works ok but 
yarn vite:build
fails:
Copy code
'readFile' is not exported by __vite-browser-external, imported by ../node_modules/@sentry/node/esm/integrations/contextlines.js
file: /Users/samh/Code/vite-ssr-sst/node_modules/@sentry/node/esm/integrations/contextlines.js:4:9
2: import { getCurrentHub } from '@sentry/core';
3: import { addContextToFrame } from '@sentry/utils';
4: import { readFile } from 'fs';
            ^
5: import { LRUMap } from 'lru_map';
6: var FILE_CONTENT_CACHE = new LRUMap(100);
anyone know how to fix this? I’m happy to pay for your time
r
This is actually where I got originally with vite ssr and gave up 😕 and moved to the plugin
s
oh dang
this is actually just pure Vite, not the 
vite-ssr
package. I’ll try filing an issue on GitHub. this seems like a bug
r
That's what I mean just vites built in ssr bundling.
s
gotcha
r
I was struggling to get things to resolve, it was just experimental for me though so I wasn't super focused on making it work. Just was like this sucks, oh well I am gonna try this other way.
s
I just opened this, hopefully it’ll get some attention and someone who knows more about this can help. https://github.com/vitejs/vite/issues/7483
a
@Sam Hulick @Ross Gerbasi You ever got further with those attempts? I'm also currently trying to get an SST project going with some simple SSR (pretty open for frameworks at the moment). I tried the NextjsSite construct that SST has, but I can't get the EdgeLambdaBucket deployed, so I'm looking for alternatives
r
I put together a pretty basic SSR demo using lit for my SST 1.0 Conf talk. It uses lambda for dynamic routes and s3 for static assets. It also hydrates on the client to bring in any interactivity. This part could be skipped if you just need a app with normal routing. Code is over here https://github.com/aphex/sst-lit-hfwa
a
Thanks, gonna take a look tomorrow, it's late 🙂
s
Should work right out of the box
a
@Sam Hulick Thanks again, I've taken a look at it, but I don't like to have infrastructure config in global .env file
s
Your secrets should never be in those files anyway. App secrets would be in SSM. For deployment secrets, you could use GitHub OIDC
5 Views
Open in Slack
PreviousNext
Powered by