![]() When the service gets deployed with Serverless ( sls deploy) it will create a Lambda function and the API Gateway that will listen for the GET requests and trigger the Lambda to resize the image. events: - http: path: /resizer method: GET #. The Lambda function only requires getObject & putObject permissions to our specific S3 bucket. In a production environment, I recommend following the principle of least privilege and set more restrictive access. Only use AmazonS3FullAccess policy for a quick demonstrative setup. View and copy the API Key & Secret to a temporary place, we'll need them for the Lambda config. Go to Users and click "Add users" > pick a username that'll be easier to remember > check "Programmatic access"Ĭlick "Next" to go through to the Permissions page, click on "Attach existing policies" directly, and select AmazonS3FullAccess* Log in to the AWS account and go to the Identity & Access Management (IAM) ![]() We'll start by creating an IAM user that will allow our Lambda function to put the resized images on S3. Architecture overviewġ) The user requests a resized image via Cloudfront (if the asset exists it will be returned and everything stops here)Ģ) Cloudfront requests the asset from the S3 bucket (using a website endpoint)ģ) Because the asset doesn't exist the browser will be temporary redirected (307) to the API Gateway endpointĤ) API Gateway triggers the Lambda functionĥ) The Lambda function downloads the original image from the S3 bucket, resizes it, and uploads the resized image back into the bucket with the requested keyĦ) The API Gateway returns a permanent redirect (301) to the newly created asset Cloudfront URL The Setup Why process and store the assets that may not even be accessed by users? I'm going to process them on the fly (lazily), a resized image will only be created if a user requests that specific size. There are about 300k images to be resized, running a batch process to resize all the images into new dimensions will be time-consuming and quite costly. It does the job, but wastes server resources. The old logic works like this: the user uploads product photos > the app server creates predefined image sizes using GD Library > uploads into an S3 bucket. The new design features larger images, it will display thumbnails with different proportions and also makes use of "srcset" attribute to display responsive images. At the time of writing, the marketplace has close to 40k active products for sale, not including the drafts, products pending approval, or the sold ones. I've been working (on the side) lately on a redesign for the first SaaS I've built, a handmade marketplace for Romania's market.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |