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

Use universal-middleware #16

Open
wants to merge 21 commits into
base: main
Choose a base branch
from
Open

Conversation

magne4000
Copy link
Member

@magne4000 magne4000 commented Oct 9, 2024

Notable changes

  • Use @universal-middleware/compress for compression
  • All cache related features have been dropped
  • getPageContext hook is removed. The whole context from universal middlewares is given as a Context to renderPage. This means that the same effect can be achieved by any custom universal middleware.
  • No more distinction between node and non-node envs (at least for now 🤞)

Next steps (not in this PR)

  • Put cache feature back?
  • Is it possible to have some generic way to handle HMR websocket connections, perhaps with crossws?

@jasonhilldm
Copy link

jasonhilldm commented Oct 14, 2024

Hi. I stumbled across this extension while trying to figure out the best way to deploy to Node and it looks awesome. The one issue I have is that I am using Auth.js for authentication and was previously using universal middleware to add the logged in user to the context.

When I use the vike-node extension though, my modified context is not being seen by Vike so I assume it's using a different context. I'm assuming these draft changes will mean my context changes will be seen by Vike via the use of universal middleware...is that right?

Not sure how far away these changes are, but is there another way that I can add the user to the context using regular middleware so that Vike will see that when I am using vike-node?

@magne4000
Copy link
Member Author

@jasonhilldm I would suggest to wait for this PR to be finished, as it will fix your issue.
Nevertheless, you could still retrieve the context for your server using the getContext function of your server inside the pageContext hook. Something like this should do the trick (untested, and probably does not work for all servers):

import { getContext } from "@universal-middleware/hono";

app.use(
  vike({
    pageContext: (req) => getContext(req)
  })
)

@jasonhilldm
Copy link

Thank you - that worked perfectly.

@magne4000 magne4000 force-pushed the magne4000/universal-middleware branch from 05aa8d6 to 775df55 Compare October 16, 2024 10:10
@magne4000 magne4000 marked this pull request as ready for review October 16, 2024 10:11
Copy link
Member

@brillout brillout left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started reviewing a bit, I'll resume tomorrow.

Express:
[See complete list of supported servers](https://universal-middleware.dev/reference/supported-adapters)

#### Express:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example needs to be updated to use vike-node/express.

```
### Codebase without `vike-node`
```diff
// server/index.js

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here: example bellow uses vike-node/connect.

const port = +(process.env.PORT || 3000)
app.listen(port, () => console.log(`Server running at http://localhost:${port}`))
}
```
## Migration guide:
### `0.1.x` to `0.2.x`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's use CHANGELOG.md instead.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like a couple of BREAKING CHANGE: are missing. I guess we'll squash merge so we can just push empty commits to append any missing BREAKING CHANGE:.

"browser": "./dist/runtime/handler-web-only.js",
"default": "./dist/runtime/handler-web-and-node.js",
"types": "./dist/runtime/handler-web-only.d.ts"
"./handler": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should remove this export; I wonder why the user would want to import Vike's handler which, it itself, is fairly boring (the compression is nice but vike-node's main benefit is Vite server transpilation + HMR + standalone build).

@@ -0,0 +1,10 @@
import { Get, UniversalHandler, pipe } from '@universal-middleware/core'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious: does the file name extension .handler have a functionality or is it just a convention?

const compressMiddleware = compressMiddlewareFactory()(request)

return async (response) => {
if (!globalStore.isPluginLoaded && nodeReq) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why && nodeReq? We don't want to compress for CF but it still seems too restrictive 👀

headers,
platformRequest,
options
export const renderPageCompress = ((options?) => async (request, _context, runtime: any) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style: it seems to be agnostic to renderPage so I'd call it differently e.g. compressMiddleware.

staticConfig = resolveStaticConfig(options?.static)
}

if (globalStore.isPluginLoaded) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style: I'd rename globalStore.isPluginLoaded to globalStore.isDev. It's more explicit and, at the end of the day, that's the info we're looking for and testing against.

async function serveStaticFiles(req: IncomingMessage, res: ServerResponse): Promise<boolean> {
if (!staticMiddleware) {
const { default: sirv } = await import('sirv')
staticMiddleware = sirv((staticConfig as { root: string; cache: boolean }).root, { etag: true })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In itself I like the idea to have a built-in static server. Just not sure this is the right place. But let's keep it since it was already here before this PR.

In the long term (after this PR), what could be lovely is to leverage the upcoming partial eject functionality: upon running $ eject vike-hono entry the Hono entry is ejected, giving the user the opportunity to switch out the static server. In other words, the user can use a Hono server without writing a single line of server code. The idea here is that vike-hono, vike-telefunc, vike-auth, ... would all automatically integrate with each other. To swap the server all the user needs to do is to install vike-express instead of vike-hono (assuming he didn't write/eject any server code) and everything would work equally.

@@ -27,7 +27,8 @@
},
"pnpm": {
"overrides": {
"vike-node": "link:./packages/vike-node/"
"vike-node": "link:./packages/vike-node/",
"esbuild": "^0.24.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we can remove this line?

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

Successfully merging this pull request may close these issues.

3 participants