Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A way of intercepting requests and populating session #9

Closed
Rich-Harris opened this issue Sep 16, 2020 · 3 comments
Closed

A way of intercepting requests and populating session #9

Rich-Harris opened this issue Sep 16, 2020 · 3 comments

Comments

@Rich-Harris
Copy link
Member

In current Sapper it's easy to intercept requests and do whatever you want with them since you're building a server — this is useful for auth, custom headers and so on. The Sapper middleware also has a session property that populates the session store when a request is made that falls within Sapper's purview.

In a serverless-first world this gets a bit trickier. It needs to be possible to do both things, in a way that maps to the various serverless platforms out there, which most likely precludes using the (req, res) => {...} signature (and by extension, the ecosystem of Express middleware).

Maybe this is a new src/request.js file (naming subject to extensive bikeshedding):

export function intercept({ url, cookies, headers, blah }) {
  return {
    headers: {
      'x-my-header': 'banana'
    }
  };
}

export async function session({ url, cookies, headers, blah }) {
  return {
    user: await get_user_from_cookies(cookies)
  };
}

It probably doesn't make sense to intercept all requests (since in many cases the responses get baked out as flat files), so we probably have to work within the constraint of only intercepting requests for pages and server routes.

@Rich-Harris
Copy link
Member Author

Remix is handling differences between platforms by using standardised Request and Response objects everywhere https://twitter.com/ryanflorence/status/1306261914553442304

@Rich-Harris
Copy link
Member Author

After discussion with the team, we're going to avoid Request and Response in favour of POJOs, which are much less cumbersome.

@Rich-Harris Rich-Harris transferred this issue from another repository Oct 15, 2020
@Rich-Harris Rich-Harris mentioned this issue Oct 20, 2020
@Rich-Harris
Copy link
Member Author

closing this in favour of the more comprehensive #46

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant