Support for Next 13.x App Directory

[nick-cheatwood7]

Hi @htunnicliff, firstly I want to say thank you for creating this awesome package. I use this in several Next apps at work and honestly love it. In my opinion, Next should have included this syntax and functionality out of the box, but I digress.

Are there any plans to make this package compatible with the new App Directory in Next 13.x? I realize this is asking a lot, seeing as though the underlying API has changed considerably.

Thankfully, it seems Vercel has committed to supporting the Pages directory for the near future, however the eventual migration to the App directory is something that is looming over mine and most other Next devs' heads right now.

[htunnicliff]

Hi @nick-cheatwood7! Thanks for the kind words.

I haven't yet considered adopting this library for use with the App Router. Are you wanting to use middleware within Route Handlers, or is there a different part of the App Router that you'd like to see this library support?

If you'd be able to share an example of how you'd like things to work, I can do some investigation to see if there is a good fit for this library within the App Router paradigm.

[nick-cheatwood7]

@htunnicliff,

I think primarily in route handlers would be fantastic. I've tried to think where else it might make sense to add middleware using this library, but I think the standard middleware.{j | t}s file in Next handles those cases well enough.

As far as examples, here is what I'm imagining:

// withMiddleware HOF
const withMiddleware = label(
  {
    addRequestId,
    sentry: captureErrors, // <-- Optionally alias middleware
  },
  ["sentry"] // <-- Provide a list of middleware to call automatically
);

// handler function
const getHandler = async (req) => {
  return new Response("Hello World", { status: 200, headers: {
      'Content-Type': 'text/plain'
  }});
};

// named export
export const GET = withMiddleware("addRequestId")(getHandler);

However, the big question is how to mutate the response and its Headers via middleware. It seems the old paradigm used Event Emitters to emit "send" events when res.send() or res.json() was called. Now, in the App Directory, it seems that either a Response or NextResponse object actually has to be explicitly returned to send a response back to the client.

I loved the old model where you could do something like set a X-Request-ID header in middleware like res.setHeader("X-Request-ID", nanoid()), but unfortunately this does not seem possible in the new Web Request and Response API-based model. Or at least not as fluid. I'm definitely open to suggestions here.

I created this Gist to demonstrate how middleware effectively have to be "chained" using this new model: https://gist.github.com/nick-cheatwood7/68a127ce79d04fee35bedeb44157b4d3. Admittedly, it's not very pretty and lacks the readability of the previous model. Ideally, a library like next-api-middleware could abstract some of this and provide better DX.

[htunnicliff]

Hey @nick-cheatwood7,

I gave this a good amount of thought and tried out a few concepts to get a feel for different APIs such as the one you suggested. Since I designed this library prior to Next.js introducing the App Router and Web Fetch API request and response objects, I think refactoring next-api-middleware to work with both concepts is a bit of a stretch of the original purpose for the library.

I'd gladly encourage someone to create a next-route-middleware library to meet this need though, and you or others are welcome to fork or branch off of next-api-middleware.