apollo-server-cloudflare is building at >1MB

[GregBrimble]

Using the latest version of apollo-server-cloudflare (2.0.2), a minimal app builds to greater than 1MB, which is the limit of Cloudflare Workers (so cannot be deployed).

A project build with 1.0.0-beta.0 builds to less than 350KB.

See 1.0.0-beta.0 example at https://github.com/jbaxleyiii/apollo-server-cloudflare. Then, install the latest version, and see the new size of dist/app.js.

---

Update: Still an issue as of 2.2.2 (2018-11-13)

[GregBrimble]

CC: @jbaxleyiii

[bsbechtel]

@GregBrimble Did you make it past this issue? I'm interested in trying out the cloudflare workers with an apollo server, but haven't heard any updates recently. I'm worried the project may be abandoned.

[GregBrimble]

@bsbechtel - no. I just used pinned to the 1.0.0-beta.0 version, which continued to work fine. However, I doubt this is abandoned, since Cloudflare Workers are still being actively developed, and the Apollo Server Cloudflare package was only developed this summer, but I don't know for sure.

[bsbechtel]

Ok cool. I've been hesitant to try it out because it hasn't been officially released yet, and I haven't heard much from the community regarding if it's working well for them. Are you using it with a db connection and it's working effectively?

[GregBrimble]

@bsbechtel I tried connecting to Firebase, but again, the script ballooned above the 1MB limit. I'm in the new Cloudflare Workers KV beta though, so will be trying out that soon.

I was successful in proxying requests however, serving Apollo, and using other APIs are data-sources, behind the scenes.

[bsbechtel]

@GregBrimble Ok awesome. I may try it out then. My backend is Mongo. If using the mongo driver or Mongoose puts it over the limit, Mongo offers Stitch as an API alternative.

[gcoda]

I do not need uploads, so i just aliased busboy to null in webpack.config.js, barely fits(968KiB) but works.
Also cloudflare needs a addEventListener. here is a gist

[kristianfreeman]

hi all, dev advocate for the cloudflare workers team here 👋 we recently pushed some updates to how we bundle scripts at deploy time in workers – after some testing, it looks to me like deploying an apollo server on workers... works! (again)

would love someone to double-check my work who has been running into this issue in this thread – here's an example project you can configure: https://github.com/signalnerve/workers-graphql

[GregBrimble]

@signalnerve, looks to have done the trick 🎉 Build size for your example repo was 452KB, and worked perfectly.

Many thanks to the team for the work done, and to you for following up here! I'll close down this issue ✔️

[dkolba]

@signalnerve, looks to have done the trick 🎉 Build size for your example repo was 452KB, and worked perfectly.

@GregBrimble how did you get the bundle size to 452KB? I get 1.559MB without modifying the code.

[GregBrimble]

@dkolba, sorry I wasn't clear. My Worker script was also ~1.5MB locally, but I believe that the work that @signalnerve and co. did, gzips the script as it deploys. It was this file that was 452KB. Did you try deploying the 1.559MB worker with Serverless, as in @signalnerve's repo?

[dkolba]

@GregBrimble I deployed it via CloudFlare's wrangler, which worked and is also pretty nice. Apollo queries and GraphiQL seem to work fine but now I get the warning Your script is too large. The maximum file size is 1MB. in CloudFlare's Worker editor. Is this expected behaviour @signalnerve?

[vladinator1000]

This is a problem for me when I use TypeScript, here's an example that produces a 1.5MiB build. I've also logged an issue in @signalnerve's repo

[vladinator1000]

I think we should reopen this issue, here's how my bundle looks like, it has 1.5 MiB of dependencies.

When I use bundle optimize helper it says a bunch of deps are not tree shakeable because they're not using ES modules.

[GregBrimble]

@vladinator1000 , how are you deploying? Like I said above, (for me at least), although the build itself is ~1.5MB, once it is gzipped, it shrinks down to 452KB, so wrangler is able to deploy just fine.

[vladinator1000]

@GregBrimble I used cargo publish in this repo

[GregBrimble]

Ah, I can reproduce now. Yes, looks like TypeScript & Apollo Server are too large together. (I haven't tried setting up a repo from scratch myself, but your example one looks correct from a quick skim).

In my own projects (which are just about all exclusively TypeScript), I've been using graphql directly, avoiding Apollo Server entirely. The build sizes were getting too large as soon as I began introducing anything sizable beyond a simple proof-of-concept. Here's an example file which loads the schema/resolvers, and responds to GET/POST requests (sorry that I don't have a more minimal example to hand).

[vladinator1000]

This looks like a nice approach @GregBrimble I bet with a bit of codegen it can become even easier