feat: updates for remix 1.19.3

[andersquist]

As I mentioned there are issues when using remix-mount-routes that are unresolved. My guess it that it is both build and runtime related.

Eslint-config and tsconfig were updated to match those in the Remix repo.

[brettdh]

First question: what are the playwright tests? I couldn't find any such tests in the repo.

Second question: I'm trying to set up an example app for some manual testing, but I'm getting stuck very early on:

serverless-remix/example on  feat/version-bump [!?] via ⬢ v16.20.0
➜ npm run dev

> dev
> remix dev


 💿  remix dev

 info  building...
 info  built (285ms)
Remix App Server started at http://localhost:3000 (http://192.168.7.203:3000)

/Users/brhiggins/src/serverless-remix/example/node_modules/@remix-run/server-runtime/dist/dev.js:26
      buildHash: build.assets.version
                              ^
TypeError: Cannot read properties of undefined (reading 'version')
    at Object.broadcastDevReady (/Users/brhiggins/src/serverless-remix/example/node_modules/@remix-run/server-runtime/dist/dev.js:26:31)
    at Server.onListen (/Users/brhiggins/src/serverless-remix/example/node_modules/@remix-run/serve/dist/cli.js:48:10)
    at Object.onceWrapper (node:events:627:28)
    at Server.emit (node:events:513:28)
    at emitListeningNT (node:net:1497:10)
    at processTicksAndRejections (node:internal/process/task_queues:82:21)

Example app here: https://github.com/brettdh/serverless-remix/tree/feat/version-bump-with-example-app/example

Based on the "just the basics" output of npx create-remix, plus following the instructions in the serverless-remix readme.

[brettdh]

Ok I might be confused and just figuring out that the server.js file that uses serverless-remix should not also be used with remix dev; only when deploying with Serverless. Is that right? (Still getting used to Remix)

[andersquist]

The answer to the first question is that I just tried to merge everything from the origin, comments and all. In this case the Architect adapter is the origin so the updated comment that is changed is also reflected in their source. 😊 https://github.com/remix-run/remix/blob/30bcd9e9dfbeda1707329da017f9ceccfac21521/packages/remix-architect/__tests__/server-test.ts#L18

Regarding the second question when running your code two things comes to mind.

• The parent is using yarn version 1.22.19to be precise and I see that you are running npm. Not really sure how that will affect things.
• There is no dependency to serverless-remix in your example. There are perhaps two ways to achieve this. Either with yarn link etc or using a file url pointing to the parent:

"dependencies": {
    ...
    "serverless-remix": "file:../../dist",
    ...
  },

Both approaches will require you to build serverless-remix using yarn build so that the dist folder exists.

[brettdh]

The example app is a separate npm package, so I figured that would be fine. I was using npm link most recently, but I'd also previously tested with serverless-remix in the example's devDependencies, with the same result. (Before I took one of these approaches, I did encounter an import error, and before I built serverless-remix, I encountered a path error on dist, so I think those issues are taken care of now.)

I've also tried this with an example app outside of the serverless-remix tree, but I got the same result.

[brettdh]

Whoops, I overlooked this detail in the serverless-remix readme:

The current way to get started is to bootstrap a new Remix project with the built in Architect template and then do some modifications.

(emphasis mine)

The default setup for this runs arc sandbox as the custom server, though; should this example app use serverless-offline or similar to be a realistic test? (Or to work at all?)

[brettdh]

Spent some more time on this today, but when I go to test this in AWS, the resulting zipfile is over 300MB, and AWS rejects it. Is there something special that Architect is doing to avoid this?

I also tried using serverDependenciesToBundle to try to not include the entirety of node_modules in the zipfile, but I quickly realized that this would require listing every module that's transitively imported by the built server module, so I abandoned that. I could imagine webpack/rollup/vite being a way to go about reducing lambda package size, but I feel like this must already be a solved problem, since there are various other first-party cloud function runtimes for Remix that don't seem to have this problem.

[brettdh]

Hmm... upon further searching around:

• this other serverless+remix example uses the serverless-esbuild plugin
• this netlify support thread seems to indicate they're using esbuild as well

so maybe that's the way this has to go? Have you seen zipfile-too-large with prior versions of Remix?

[cayblood]

@brettdh I'm just coming to this conversation now, but am interested in a similar setup. I'd like to get remix running on lambda, deployed using serverless, and probably talking to an RDS instance. I would recommend looking into Lambda Layers, which allows you to drastically reduce the size of your build by moving your dependencies elsewhere.

[brettdh]

@cayblood thanks for the reply. I did attempt using a lambda layer for node_modules, but this still hit a size limit. However, serverless-esbuild is working for me now, which has let me move on to the real issue: remix-mount-routes, as @andersquist originally said would be the case. 🙂

[cayblood]

@brettdh is support for remix-mount-routes necessary, if you're not serving from a subdir? Also, how did serverless-esbuild overcome the size limit?

[cayblood]

@brettdh would you be willing to share an example repo with your work so far?

[brettdh]

is support for remix-mount-routes necessary, if you're not serving from a subdir?

From #137 (comment):

remix-mount-routes is a necessity if you are exposing your site without a custom domain but instead with the stage path that API Gateway enforces you to have.

We are using custom domains for only some of our envs, so we need the ability to serve from a path like /dev.

Also, how did serverless-esbuild overcome the size limit?

My understanding is that serverless-esbuild helps because, rather than packaging the entirety of node_modules (minus devDependencies, which serverless prunes out), it just bundles the things that the Remix server build imports and tree-shakes out the rest. It's possible that I could have achieved some size reduction by making sure I didn't have anything in dependencies that belongs in devDependencies, but probably not the over 100x reduction that I saw with esbuild.

would you be willing to share an example repo with your work so far?

I'm working on an example app to add to this repo, which I hope to push tomorrow or later this week.

[brettdh]

I found an update from the author of remix-mount-routes that I hadn't seen before:

Another option is remix-flat-routes. This is preferred over remix-mount-routes as it supports the new v2 routing convention. I've incorporated basePath support as an option.

This matches what I see when trying to use remix-mount-routes with v2 routes configured - it doesn't understand that _index.tsx is an index route, since the v1 convention was index.tsx.

I've started looking at remix-flat-routes to fill this role. So far, I think the tricky bit is going to be ensuring that the app works both when accessed without a custom domain (e.g. with the /dev path prefix) and with a custom domain (without the path prefix).

The example setup linked from the same discussion above might be a promising approach - though we won't use nginx, API Gateway is doing something similar by serving the app with and without the /dev path prefix depending on what domain is used to access it, and the example code handles the dynamic basename in the Remix route structure. I'll play with this some more tomorrow.

[cayblood]

My understanding is that serverless-esbuild helps because, rather than packaging the entirety of node_modules (minus devDependencies, which serverless prunes out), it just bundles the things that the Remix server build imports and tree-shakes out the rest. It's possible that I could have achieved some size reduction by making sure I didn't have anything in dependencies that belongs in devDependencies, but probably not the over 100x reduction that I saw with esbuild.

Forgive the repetition, but shouldn't lambda layers also bundle everything in node_modules in a separate layer? Not sure why serverless-esbuild would have been such a dramatic improvement.

I'm working on an example app to add to this repo, which I hope to push tomorrow or later this week.

Thanks!

[brettdh]

The key detail is that there is also a maximum compressed size for a lambda layer:

Resource	Quota
Deployment package (.zip file archive) size	50 MB (zipped, for direct upload) 250 MB (unzipped) This quota applies to all the files you upload, including layers and custom runtimes. 3 MB (console editor)

[cayblood]

Cool! Do you think there would be a benefit in combining both approaches? Does serverless-esbuild result in a small enough code base to edit the lambda in the AWS console?

[brettdh]

Do you think there would be a benefit in combining both approaches?

One could probably do something like that with esbuild using chunks, as suggested in the example linked here: evanw/esbuild#2321

Does serverless-esbuild result in a small enough code base to edit the lambda in the AWS console?

The current build of my barebones example app (based on the grunge stack) is 2.7 MB. While this is just below the limit of 3 MB, it's probably not something you'd want to edit most of the time, even in its non-minified state. Getting the node_modules deps into a layer would help, but editing esbuild-bundled code is generally not a great dev experience. Luckily, esbuild and the deploy are pretty fast.

[brettdh]

Ok, good news and bad news.

• Good news: I pushed my very very WIP example app here: brettdh@d88ec21
• Bad news: I'm not going to be pursuing this path any further. Instead, I'm going to be using @remix-run/architect with API Gateway v2, as in this example setup.

Once I came to the point of needing to have the optional base path (which is specific to API Gateway v1) as part of the Remix app, rather than managed by the adapter, I took that moment as a good time to step back and revisit the API Gateway v2 approach, which my team had considered initially but had tabled as too complicated. When I returned to it, though, I was able to get it working within a day.

I still think there's a place for a plugin like serverless-remix, particularly if it can deal with the above API Gateway v1 complexity so that app authors don't have to. For my immediate purposes, though, I'm moving forward with API Gateway v2.

[cayblood]

Thanks for sharing this, @brettdh. It will be a huge help to be able to benefit from your diligent efforts.

[cayblood]

@brettdh if you have a moment, please push your starter project to a git repo once you get it working. It would be nice have an easy-to-follow of remix 2 running on AWS. I am working on adapting the grunge stack to use RDS, as I don't want to use DynamoDB.

[brettdh]

Sorry if I was unclear. I'm not currently doing any more work on the WIP starter project, since I'm not continuing in the serverless-remix direction; I pushed it in case others want to take it from there. The commit message has some next steps that I would have been looking into had I continued.

[cayblood]

@brettdh I was mostly confused because the "example setup" you linked to was also a serverless project. Are you saying you just created a grunge stack app and then deployed it without serverless? If so, how did you deploy it? I took a look at AWS architect (used in the grunge stack) but it seemed to require DynamoDB, while I would prefer to use RDS postgres or something that at least has SQL support.

[brettdh]

When I wrote this:

Instead, I'm going to be using @remix-run/architect with API Gateway v2, as in this example setup.

I meant that I'm just using the architect adapter, which is probably misnamed. I'm deploying the lambda (which uses that adapter, by way of remix build and a custom server request handler) via serverless framework, as is the example (not mine) that I linked to.

FWIW, architect supports RDS in the same way that serverless does - via custom cloudformation resources.