Implement Dropbox as backend

references:
@mrkurt Go implementation

We can make a middleware that automatically encodes images as webp for supported clients.

This would apply to requests with image/webp in the accept header and image/jpeg or image/png in the response type from origin.

https://github.com/superfly/cdn/#try-the-starter-app

git clone https://gist.github.com/ebc48856b74fde392a6d62a032b59a97.git forking-cdn
cd forking-cdn
yarn install
yarn start # visit http://localhost:3000

The code in that example throws a 404 Not Found locally and "Too many recursions" when deploy to Fly.

Query strings are being ignored in requests.

Example: requests like blah.com/path?stuff are getting sent to backends as just /path

Found with the following code while creating middleware/device-router:

if (deviceType === "mobile" && osName === "Android") {
  const backend = origin({
      origin: `https://play.google.com/store/apps/details?id=${options.android}`,
      headers: {host: "play.google.com"}
  });
  return backend(req);
}

origin is only being seen as https://play.google.com/store/apps/details rather than https://play.google.com/store/apps/details?id=${options.android}

Tried to setup Typeform example form through Fly Sites in UI, but Preview link took me back to https://www.typeform.com/. Could this be because it's a free account and the form is private?

Typeform URL: https://kittybot.typeform.com/to/Su91j4

Middleware feature that will help improve page load time: Lazy Loading — delay the loading of images in long web pages. Images outside of the viewport will not be loaded until the user scrolls to them.

Replace src's with data-image-src tags. Use the IntersectionObserver API to observe when images enter the browsers viewport. When an image comes into view, switch back to src.

For background images, grab their url's and hide/store until image comes into view.

I can get started on this if we think it's a good feature to add.

Reminder to add

An app should be able to specify which error pages to serve up when it sends an error back to a visitor. A map of status -> file:/// should be enough for a first start at this.

Proxied requests occasionally fail due to intermittent network issues. We should have an option to retry those requests.

The recommended setup process is rather unconventional and difficult to recall without referencing the README. I think a better approach would be for the fly CLI to have a built in generator replicating the project structure in the referenced gist.

Setup might then look something like:

# create fly app, project folder, and `.fly.yml` config
# walk user through setup (similar to `npm init`):
#  - name: example-app
#  - eject (Y/n): y
#  - typescript (Y/n): y
#  - ...
fly apps create

If the user chose not to "eject" their fly app configuration into code upon initial setup, that can still be done later at anytime (prior art: Angular's ng eject):

# code generation based on current `.fly.yml` config
# create webpack, tsconfig, etc if they don't exist (error if they do)
# create/update `package.json` (adding `@fly/cdn` dependency)
# remove `flyCDN` config from `.fly.yml`
fly apps eject --app <name>

Another option, upon ejecting the config, would be to store fly-related configuration in the package.json and eliminate .fly.yml entirely. As an example, babel allows you to do this in place of a .babelrc.js). Would be nice because things like name could be shared between the two.

Nothing destroys a lighthouse score like 3rd party tracking scripts. It'd be great if we could offload tracking requests from the client to middleware. Google Analytics is the big one -- are there any other simple integrations? Mixpanel, Heap, Segment?

Protect some routes via a 3rd party auth system (in this case: Google.)

We had that with the old platform (sites), pretty sure it would still be useful.

Not sure if this issue has something to do with my local dev environment, but I was getting tons of TS errors and the only way to fix it was to update my tsconfig.json to the following:

{
  "include": ["./index.ts"],
  "compilerOptions": {
    "target": "es5",
    "lib": ["es2015", "dom"],
    "outDir": "./build/",
    "baseUrl": ".",
    "paths": {
      "@fly/cdn": ["./src/"]
    }
  }
}

• Newsletter (@KittyBot)
• Blog/tutorial (@barnese3)
• Docs (@WesleyDavid)
• Dev (@mrkurt @jeromegn @michaeldwan @steveberryman)
• Landing Page (@hkfoster)
  • Art (Annie)
  • Info (@KittyBot)
• Testing/break it! (@superfly)

Feel free to break out into separate issues the pieces you're working on, if applicable. Let's keep this thread updated with anything preventing a Wednesday release. :)

The CDN should be able to use S3 for storage. The simplest version of this would just use public bucket URLs. The razzle dazzle version should work with private buckets + AWS auth.

This cdn and the load balancer app would go great together, let's move it here!

The staticServer in superfly/fly is a handy way to serve a static site without another backend. This package would make a great new home for it.

Feature: device-based caching/dynamic serving

-Using the User-Agent header from requests to deliver cached content based on device type

import { responseCache } from '@fly/cache'

fly.http.respondWith(async function(req) {
	// use "vary: user-agent" header to tell Google that you’re tailoring the content to the User Agent
	req.headers.set("Vary", "User-Agent")

	// get user device type
	let type = req.headers.get("User-Agent").toLowerCase()

	// serve cached or new response based on device type
	if (type.includes("macintosh")) {
		let c = cache("mac", "Hi Mac user!")
		return c

	} else if (type.includes("windows") && !type.includes("mobile")) {
		let c = cache("windows", "Greetings desktop Windows user!")
		return c

	} else if (type.includes("iphone")) {
		let c = cache("iphone", "Howdy iPhone user!")
		return c

	} else if (type.includes("android" && "mobile")) {
		let c = cache("android", "Cheers mobile Android user!")
		return c

	} else {
		let c = cache("device unknown", "Welcome user!")
		return c
	}
})

async function cache(key, response) {
	// create a unique key
	let cacheKey = `${key} version of www.example.com`

	// get cached response if there is one and serve it
	let cachedValue = await responseCache.get(cacheKey)

	if (cachedValue) {
               console.log("response served from cache at key: ", cacheKey)
               return cachedValue
        } else {
              // serve new response and add it to the cache
	     let deviceResponse = new Response(response)
	     await responseCache.set(cacheKey, deviceResponse)
	     return deviceResponse
        }
}

MIddleware idea/ request: redirect www requests to the same host without www.

Alternatively the same middleware should support redirecting non-www requests to www requests.

The proxy function currently sets the x-forwarded-for header to the remoteAddr before sending a request to an origin. It would be better if it had options to:

• Not touch x-forwarded-for and just send it through as is
• Handle it like the MDN docs specify: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

Squarespace should work similarly to Ghost Pro. Most squarespace sites seem to be a subdomain + possible custom domain.