We have to control the app because we control the CLI, and we control loading code.

To be clear what I mean is I'd love if we could support any framework with a web handler, eg. hono, h3, fastify etc. But I understand the challenge

Ah yeah, hadn't thought of that. That would mean us creating N number of framework adapters, so just moving the problem somewhere else. And the idea here is that certain features, like Actions or redirects, could still exist as middleware that you use in this file, so would want to avoid writing N of those too.

Maybe relevant: https://srvx.h3.dev/. There are examples with hono and express

• Wouldn't integrations being able to invisibly insert middleware defeat the purpose of the user controlling the order? What's wrong with having your middleware be imported and used by them directly? To be clear, my intent here is that even Astro core features aren't auto inserted. If you don't add the pages() middleware as shown above you don't even get file-based routing! I was thinking that we'd have some sort of everyAstroFeature() middleware that just bundles them all as one, but you'd still need to import and use it. In any event, since you have access to Vite plugins, I would think you could still do whatever you want, by effectively "wrapping" the user's src/app.ts with your own implementation.
• I think so, I haven't fully thought out what this means for adapters. It could be transparent to them, in which case the APIs they use don't change and this is all internal. But the downside of that is that the user isn't really "in front" like this is intended. Need to figure that part out.
• Short term if the user doesn't provide src/app.ts then they get the exact experience of today. Long-term we might push some of these features into only be used as middleware (some in core and some as integrations). Astro middleware is the only one that's really redundant if we do this RFC, but migrating those should be pretty easy.

Wouldn't integrations being able to invisibly insert middleware defeat the purpose

Maybe? But still worth discussing head on. One of the great DX things we can offer right now is a single point of configuration for integrations that can inject routes, middleware, etc. And because of that architecture we can offer astro add as a super convenient path for users to achieve things. To me it feels kind of like an API design weakness whenever adding a feature requires configuration in multiple locations: I want to go to the “code for feature X” and not have to think about all the ways it’s wired up.

(Current example where this bugs me is astro.config and content.config: Starlight can’t inject collections so users have to configure it in both locations. Most people use a starter template for Starlight so it’s not too bad, but the more this is the case for “add-on” features, the more annoying it is.)

Yeah I understand the tradeoff here. What would Starlight use middleware for here?

What would Starlight use middleware for here?

Not sure — we don’t use it currently. Depends if we would no longer have injectRoute()?

There's no plan to remove injectRoute(), in fact the idea behind #1318 was to give integrations deeper capabilities in order to allow more of Astro's core features to be moved into integrations.

No, I don't think we could replace platform APIs like that even if we wanted to. app.ts becomes the entrypoint within "Astro code", but there's still the platform layer outside of it (and adapters). We need to figure out how this works, but presumably we'd expose the Hono instance to the user who's writing a custom worker.ts file.

Also need to figure out what changes in the adapter's API. I am thinking that the Hono instance replaces the current App class which stays around as a very thin layer for backwards compat purposes only.

What I mean especially is this. In today's custom worker.ts entrypoint you can do something like this:

import { handle } from '@astrojs/cloudflare/handler';
import { DurableObject } from 'cloudflare:workers';

export class MyDurableObject extends DurableObject<Env> {
  // ...
}

export default {
  async fetch(request, env, ctx) {
    await env.MY_QUEUE.send('log');
    return handle(request, env, ctx);
  },
  async queue(batch, _env) {
    let messages = JSON.stringify(batch.messages);
    console.log(`consumed from our queue: ${messages}`);
  },
} satisfies ExportedHandler<Env>;

In my understanding the fetch would be replaced by export default { fetch: app.fetch }. But where do I put the export class MyDurableObject {} or the queue from the default export. Would that all be top-level in app.ts. It sounds like it, but I just want to make sure.

Since we are going for a fetch based API, I think app.ts and worker.ts would be the same file

The problem is, how do you do the raw fetch method while breaking apart the Astro features? It's easy when it's just astro(request): Response but when you want to use the features piece-meal we need to come up with some sort of new API to allow this. And how do you do that without essentially just creating your own Hono-like API? If we can figure out how to do that then I'd be happy to relax that.

Since you still show an 'astro/app/hono' module I assume you are ok with having Hono middleware for those that want to use it?

Here's a small example that might work:

export default {
  fetch(request) {
    const state = new FetchState(request);
    
    await i18n(state);
    await sessions(state);
    await pages(state);

    return state.response;
  }
}

Not pretty but might work.

Alternatively we could store state on the request, eg. __astroInternal. I think it's doable so I'm not going to share more ideas just yet in terms of implementation, can happen during Stage 2.

Since you still show an 'astro/app/hono' module I assume you are ok with having Hono middleware for those that want to use it?

Yes definitely

I've renamed the proposal to Advanced Routing and removed the strict dependency on Hono, while still allowing users to easily use Hono.

cc @ematipico

Since Florian made a similar point above, I answered both there.

Yeah, I agree too. Right now, Astro isn't flexible enough to provide enough customisation at runtime.

We tried with Actions, and it ended badly.

Got ahead of myself, updated to just be entrypoints.

You have my 👍 too

You have my 👍🏻 . I was concerned with the Hono dependency, but making it generic is fine.

This has been moved to stage 2: #1342

LETS GOOO!!! I've been following this proposal. Great work y'all. Good discussion.

Hmm... I'm not sure, but some details for demoing this feature came out experimentally in https://astro.build/blog/astro-630/