Apps for each of the adapters

[Rich-Harris]

The adapters don't have tests, and it's not totally clear what value they'd provide if they did, but I think we should have hello world apps for each of the officially supported adapters running on the respective platforms.

Should they live in this repo? In examples or a new directory? Or in the package directories themselves? Or should they have their own individual repos?

Most importantly, who feels like setting it up? 😀

[antony]

I think under examples is fine - examples/begin-adapter perhaps.

We could deploy each via API and ensure that the relevant CLI tool returns ok and not an error. We could also possibly ping the deployed endpoint looking for a 200 or similar. Optionally a very quick playwright test run against the deployed app. It'd be a pretty reasonable test.

[benmccann]

I think most of the adapters should be in separate repos. Keeping the most used ones here is fine as long as we're going to be maintaining them. I don't know if we want to be responsible for an influx of community adapters though

For the examples, should we have separate standalone apps or can we just repurpose some of the existing ones. E.g. deploy the HN to Netlify and the Realworld example to Vercel

[antony]

I'm not suggesting we should adopt all community adapters at all - I think we're talking about the basic set of us-maintained ones here. It makes sense for the example apps to live in the monorepo, so that they aren't a maintenance burden.

I think it should be the same app across all adapters - that way we can make checks for consistency, and spot misbehaving adapters early.

[Rich-Harris]

Yeah, I was thinking a super basic hello world that has page with a dynamic parameter, an endpoint with a dynamic parameter, a handful of static files, something prerenderable, maybe a setup function to make sure things work in an env-agnostic way, etc. svelte-kit-demo is probably pretty close already. Maybe we could even have a single codebase, and we could deploy it by swapping out the adapter at build time according to whatever env var is currently applicable

[benmccann]

Maybe we could use demo or sandbox app

The other part of this is detecting when it breaks. If we have an app for each adapter we need someone to periodically visit those apps in order to detect issues. We could use a downtime monitoring service like Pingdom

[benmccann]

Although I guess if the deploy just fails there wouldn't be downtime - we'd get an old version instead. Maybe we need to do a GitHub Actions redeploy on each commit and see when it fails

[Rich-Harris]

Depending on how quotas are structured, we could blow through free tiers pretty quickly if we were deploying on every commit. It might need to be a more manual thing, or something that happens whenever Kit or the relevant adapter gets a release

[Rich-Harris]

Something that just popped up: it's not enough to build the apps in CI, we need to check that they're actually working as intended — at the very least that they're responding to requests (and that it's the new deployment that is serving responses, not a previous one because the new one failed)