It would definitely be a sharp knife! We believe we have the script transition case handled, but can understand the hesitation.

Ultimately it looks like we'll be asking devs to modify entry.server.tsx.

I actually had a use-case for this. While making the MDN Remix app, I have a route for documents that pulls in the data from MDN JSON endpoint. However, they also have images that are served up from the same folder. For example, the document /en-US/docs/Learn/Getting_started_with_the_web/HTML_basics also has an image /en-US/docs/Learn/Getting_started_with_the_web/HTML_basics/grumpy-cat-small.png.

In my loader, I was checking the extension and if it was an image, I would fetch the image from MDN. Initially I wanted to simply return the fetch response. But since this route had a default component, it was trying to render a non-JSON response.

I updated entry.server to check the content-type header and tried to return the response there. Unfortunately, the binary image data was already converted to a string by the time the entry was executed. I ended up converting the binary data to base64 and back.

I had another route just for /static/* assets (outside of a document), and these I simply used as a resource route and my loader returned the fetch response directly.

All this to say is that it would be nice if the loader sets the response content-type to something other than application/json that it doesn't try to stringify the body.

Like I said, I was able to work around it, so this is more of a "nice to have".

It looks like that library expects a Node response object, in that case, and if there’s no way to get the result instead of sending it directly, you will need to move the code to Express.

Check if there’s a way to get the result as an object instead of sending it.

I think you will need to build a version of this https://github.com/contra/graphql-helix/blob/master/packages/core/lib/send-result/node-http.tsbut using Fetch Response instead of the Node Response

Appreciate your help! I will take a try, thank you!

For anyone who sees this, I solved it. Turns out it's not that hard: I just added this to my entry.server.ts in the handleRequest function before the existing return statement:

if (isBanned()) { // or any other condition you want
    return new Response('You are not allowed to access this site', { // or any other custom response data
        status: 403,
    });
}

The one caveat is that handleRequest is not async, which can be inconvenient depending on the logic you need to call into, but there are tricks to call async functions in non-async scopes so if you need to do that it's just hacky. Adding async to the signature of handleRequest doesn't appear to cause any issues.