We recently started using sst and seed. Currently ...
# help
We recently started using sst and seed. Currently we have a couple of lambdas in there that connect to our RDS for various things. Sst has made that really easy without needing to know much about aws. Now, we want to implement an image handling service and https://github.com/aws-solutions/serverless-image-handler has the exact functionality we want. In my head, ideally we would migrate that project (which is cdk based if I understand correctly?) to sst so that everything is unified. Is this a good idea? There's a lot of code there so I don't know how simple it will be to do this migration so asking up front if it's worth doing and how much work it might be for someone unfamiliar with it all. Keeping in mind we don't have any of the resources it uses or any state to carry over. It's a complete greenfield for us
I did this exact scenario, and it wasn't too terrible. The worst part was migrating it from a REST to HTTP API Gateway, but that was mostly because the code is not very clean. If you left everything alone and just switched the API and functions to SST, I dont think it would be much effort at all, just use SST API v1.
Also, you could make use of a layer for sharp, that's what we do. You can get the layer definition here and it's simple to add that as part of the SST definition
Unpack the zip into a layers folder in the root of your app so it looks like:
Then in your stack:
Copy code
const sharpLayer = new LayerVersion(this, 'SharpLayer', {
      code: Code.fromAsset('layers/sharp'),
      compatibleRuntimes: [Runtime.NODEJS_14_X],
In your function def:
Copy code
layers: [sharpLayer]
Ok thank you both, sounds like it's doable! I'll get started tomorrow, will probably have some more questions then
@Derek Kershner @Ross Coundon sorry for the pings, I'm finding myself a bit lost by this again, I don't have any experience with aws beyond sst. There is a lot of stuff in the repo, setting policies, creating roles, caching policies, logging policies, and more. In addition it seems to use another cdk based library to set up the cloudfront and api gateway. So how much of this code should remain? What is key to it running on sst? Can I ignore everything outside of this directory and really just set up the lambda that lives there at some api route in my stack? That seems to be where the actual implementation is, everything else outside of it looks like set up. The constructs directory is particularly confusing, so I'm hoping I can ignore it, but im afraid of losing all the stuff in there pertaining to caching and cdn, which I can't find sst constructs for
Can I ignore everything outside of this directory and really just set up the lambda that lives there at some api route in my stack?
To be honest, personally I'd go with the layer approach I described above, it's nice and simple
I will do, thanks for sharing
I set this up in my stack with the sharp layer and it's running locally but it's sending a response that isn't a valid image but not throwing any errors. It's decoding my request correctly and the lambda is firing and accessing my bucket and returning a response, but its just not a valid image. If I send the same response in the non sst version deployed via the aws ui the same request works fine. Did either of you run into this?
Could it be content-type related? Are you setting the right headers on the response from your lambda?
Make sure you have the right version of Sharp. Changing it breaks lots of things. Shouldnt matter if its in a layer or not.
The latest version from that repo is 0.29.3 - I’ve submitted a PR for upgrade to 0.30.0
Downgraded to 0.27 from 0.29.3 and same thing. The response headers are set
Copy code
  'content-type': 'image/png',
  'content-length': '124928',
  connection: 'close',
  date: 'Wed, 09 Feb 2022 16:05:40 GMT',
  'x-amzn-requestid': '6e4330d3-d77f-4f6a-8163-64e2e2c11ca0',
  'last-modified': 'Mon, 03 Jan 2022 23:43:08 GMT',
  'access-control-allow-headers': 'Content-Type, Authorization',
  'x-amz-apigw-id': 'NSDs7G9coAMFyxA=',
  'cache-control': 'max-age=31536000,public',
  'access-control-allow-methods': 'GET',
  'x-amzn-trace-id': 'Root=1-6203e652-1ef7542901330cb02a548d40',
  'access-control-allow-credentials': 'true',
  'x-cache': 'Miss from cloudfront',
  via: '1.1 <http://c1efe604ffd79a90be8f4d5002f8e908.cloudfront.net|c1efe604ffd79a90be8f4d5002f8e908.cloudfront.net> (CloudFront)',
  'x-amz-cf-pop': 'LHR3-C1',
  'x-amz-cf-id': 'RusCp2o9xzpSz7MsTJFOatNuRXd2yaFgVTKk7lioDzZcrQuXdo2TnA=='
I think the image being returned is base64 encoded. Looks like some api gateway setup im missing
Ok got it working! Had to add
binaryMediaTypes: ['*/*']
to the config in my stack
Thanks a bunch for all the help/tips
I need to send back a zip file as a response from an API and I think part of that is the need to set the
so curious where in the stack you configured it @Jason?
Is that a ReST API thing rather than HTTP API?
Yeah that's a REST thing. It was
Copy code
restApi: {
   binaryMediaTypes: ['*/*'],
in the api v1 props. When I converted it to a http API earlier today I removed it
Not sure if it applies but for responses larger than 6mb I'm just planning to redirect in the response directly to the file in s3, perhaps you can do something similar for the zip
Thank you. It’s all in memory at the moment, might have to switch to writing it to S3 and returning a signed URL
@Jason, did you find a better method than me for adapting the code to HTTP? Or did you just have to change all the parameter names in every place and hope you never have to upgrade?
@Derek Kershner I changed the
where it was needed and removed everything in the
file unrelated to the
request type which meant I could remove a few of the functions and unnecessary calls to that
method. it should be stable enough, im hoping. next I need to get the unit tests running though which should give me more confidence
also deleted that thumbor mapping file completely
ok, you are removing more than I, which should help, but I do have tests working