[Bug?]: SolidStart aws_lambda preset unable to serve JS and CSS artifacts when deployed to AWS Lambda #1524
Comments
|
Reproduction repo here. Nitro's To override this you can set import { defineConfig } from "@solidjs/start/config";
export default defineConfig({
server: {
preset: "aws-lambda",
serveStatic: true,
},
});And change your CDK config to include all of const backendLambda = new lambda.Function(this, "SolidBackendLambda", {
runtime: lambda.Runtime.NODEJS_20_X,
handler: "server/index.handler",
code: lambda.Code.fromAsset("./.output"),
architecture: lambda.Architecture.ARM_64,
});Though seeing as each static asset would require a function invocation, it might be better to put the assets in CloudFront for faster access. SST Ion's Solid Start component does this via Pulumi. |
|
@Brendonovich what's your recommendation here? It sounds like this might be by design? It doesn't sound like Start could do much here. Is there something that could be submitted against Nitro? |
|
Yeah I'd say this is by design. If Nitro were to do anything i think they should mention in the lambda preset docs that the files in |
|
Thank you, @Brendonovich, for the helpful reply. I am in agreement. I was interested in a single-service (i.e., Lambda-only) deployment of the build from the perspective of simplicity, but it's not a good setup for production. It is an anti-pattern given that Lambda is pay-by-use and you're wasting CPU time funneling static assets through it. It turns out not much more difficult to go ahead and set up CloudFront with the server-bundle Lambda as the default origin, and the static frontend bundle/assets from an S3 origin. I think that is the sane default, to push users into "the pit of success". |
Duplicates
Latest version
Current behavior 😯
The
handlerin.output/server/index.jsproduced when usingfrom a new SolidStart project is able to handle the initial request and provide the initial rendered HTML, but fails to return the remaining requested assets (JavaScript chunks and CSS). Responses coming back for the remaining requested assets are all 404 page HTML renderings, instead of the expected filetype (JavaScript or CSS). The JavaScript files all have responses like this:
The status code for these responses is 200, not 404.
Expected behavior 🤔
The bundle produced serves an identical rendered page to the local rendering seen when using
npm run dev. The CSS contents are CSS, the JavaScript contents are JavaScript, and the status codes for the responses are 200.If the 404 page is rendered, I'd like to see a 404 status code in the response, not a 200.
Steps to reproduce 🕹
Steps:
Create a new SolidStart project:
I chose "with-tailwindcss" but I don't think it matters.
Build the SolidStart bundle targeting AWS Lambda deployment:
Install the CDK dependencies:
Create the CDK directories:
Add the CDK stack to
cdk/lib/solid-stack.ts:Add the CDK app to
cdk/bin/cdk.ts:Add the
cdk.jsonfile:{ "app": "npx tsx cdk/bin/cdk.ts", "watch": { "include": ["cdk/**"], "exclude": [ "README.md", "cdk*.json", "**/*.d.ts", "**/*.js", "tsconfig.json", "package*.json", "yarn.lock", "node_modules", "test" ] }, "context": { "@aws-cdk/aws-lambda:recognizeLayerVersion": true, "@aws-cdk/core:checkSecretUsage": true, "@aws-cdk/core:target-partitions": ["aws", "aws-cn"], "@aws-cdk-containers/ecs-service-extensions:enableDefaultLogDriver": true, "@aws-cdk/aws-ec2:uniqueImdsv2TemplateName": true, "@aws-cdk/aws-ecs:arnFormatIncludesClusterName": true, "@aws-cdk/aws-iam:minimizePolicies": true, "@aws-cdk/core:validateSnapshotRemovalPolicy": true, "@aws-cdk/aws-codepipeline:crossAccountKeyAliasStackSafeResourceName": true, "@aws-cdk/aws-s3:createDefaultLoggingPolicy": true, "@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption": true, "@aws-cdk/aws-apigateway:disableCloudWatchRole": true, "@aws-cdk/core:enablePartitionLiterals": true, "@aws-cdk/aws-events:eventsTargetQueueSameAccount": true, "@aws-cdk/aws-iam:standardizedServicePrincipals": true, "@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker": true, "@aws-cdk/aws-iam:importedRoleStackSafeDefaultPolicyName": true, "@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy": true, "@aws-cdk/aws-route53-patters:useCertificate": true, "@aws-cdk/customresources:installLatestAwsSdkDefault": false, "@aws-cdk/aws-rds:databaseProxyUniqueResourceName": true, "@aws-cdk/aws-codedeploy:removeAlarmsFromDeploymentGroup": true, "@aws-cdk/aws-apigateway:authorizerChangeDeploymentLogicalId": true, "@aws-cdk/aws-ec2:launchTemplateDefaultUserData": true, "@aws-cdk/aws-secretsmanager:useAttachedSecretResourcePolicyForSecretTargetAttachments": true, "@aws-cdk/aws-redshift:columnId": true, "@aws-cdk/aws-stepfunctions-tasks:enableEmrServicePolicyV2": true, "@aws-cdk/aws-ec2:restrictDefaultSecurityGroup": true, "@aws-cdk/aws-apigateway:requestValidatorUniqueId": true, "@aws-cdk/aws-kms:aliasNameRef": true, "@aws-cdk/aws-autoscaling:generateLaunchTemplateInsteadOfLaunchConfig": true, "@aws-cdk/core:includePrefixInUniqueNameGeneration": true, "@aws-cdk/aws-efs:denyAnonymousAccess": true, "@aws-cdk/aws-opensearchservice:enableOpensearchMultiAzWithStandby": true, "@aws-cdk/aws-lambda-nodejs:useLatestRuntimeVersion": true, "@aws-cdk/aws-efs:mountTargetOrderInsensitiveLogicalId": true, "@aws-cdk/aws-rds:auroraClusterChangeScopeOfInstanceParameterGroupWithEachParameters": true, "@aws-cdk/aws-appsync:useArnForSourceApiAssociationIdentifier": true, "@aws-cdk/aws-rds:preventRenderingDeprecatedCredentials": true, "@aws-cdk/aws-codepipeline-actions:useNewDefaultBranchForCodeCommitSource": true, "@aws-cdk/aws-cloudwatch-actions:changeLambdaPermissionLogicalIdForLambdaAction": true, "@aws-cdk/aws-codepipeline:crossAccountKeysDefaultValueToFalse": true, "@aws-cdk/aws-codepipeline:defaultPipelineTypeToV2": true, "@aws-cdk/aws-kms:reduceCrossAccountRegionPolicyScope": true, "@aws-cdk/aws-eks:nodegroupNameAttribute": true, "@aws-cdk/aws-ec2:ebsDefaultGp3Volume": true } }Export your CDK environment variables:
Ensure AWS CLI credentials are set up; for me this looks like:
Deploy the CDK stack:
The deployment should succeed, and you should see an output like:
where the
HTTPAPIURLshould be a valid URL that you can hit to see your SolidStart app.Open the URL in your browser and you should see a basic HTML page with the counter button and with no styling. Inspecting the network calls, you should see that the responses for the CSS and JS files are HTML with the rendered 404 page, but with status code 200.
Context 🔦
I'm trying to deploy a SSR SolidStart site with AWS Lambda as the deployment target. I expect the Lambda to serve the dynamic content as well as the static assets by default.
Later I would like to gather the static client assets and deploy them to CloudFront, letting CloudFront serve the static content and the Lambda instance serving the dynamic portion, but right now, I'm just trying to prove out I can get a deployment target of AWS Lambda to work.
I was attracted to SolidStart as a framework because, after a bit of digging, I realized that users seemed to be able to leverage all the deployment providers available in Nitro.
It's possible this functionality is entirely Vinxi's responsibility and it never worked for any meta-metaframework built on it—not only SolidStart—however, I'm starting here with SolidStart because that's what I'm intending to use, and I'm not yet familiar with this Jenga tower of SolidStart→Vinxi→Nitro→Vite→Rollup (and anything else I missed). 😅
Your environment 🌎
No response
The text was updated successfully, but these errors were encountered: