Blitz: [Feature] Add custom server support for websockets, etc

[dajinchu]

What do you want and why?

Apologies if this is already supported, but it doesn't seem possible to run websockets since there's no way to hook into the http server?

Possible implementation(s)

There could be dedicated support for websockets.

1. In the queries and mutations you could import 'ws' similar to 'db', which gets a singleton of a SocketIO.Server which you can use to emit things.
2. Using the blitz config, you could specify a function that binds listeners to Socket.IO server (io: SocketIO.Server) => void.

There could be a more generic way to hook into the blitz server

Basically just do what next.js does

This has the advantage of making it obvious that websockets don't work in a serverless deployment.

[Zeko369]

If I'm not mistaken @flybayer suggested having an ability to expose the server in the future for full-stack deploys, because then we have a problem of the app not being able to be hosted on now/zeit/vercel/howeverItIsCalledNow

[ryardley]

This is a good suggestion however it is not easily compatible with our primary deployment target which right now is serverless api functions. This sort of usecase could be abstracted away by an eventual underlying architecture that enables serverside resolvers can call clientside resolvers via long polling or something like that but for now this is likely a backlog item.

[flybayer]

I would love to support websockets for blitz start --production, which runs as a server.

I don't have much experience with websockets, so I'd love ideas and/or prototypes for how this could be implemented.

And maybe it is just enough to expose a custom server. Probably should do that regardless of websocket support.

[wKovacs64]

And maybe it is just enough to expose a custom server. Probably should do that regardless of websocket support.

Yep. I've written a websocket app in vanilla Next.js and the custom server feature was all I needed. Explicit, baked-in support (as DJ mentioned) could be supported down the road but I doubt the juice would be worth the squeeze (at least initially).

[dajinchu]

100% I think the custom server would be the best option. Websockets are a niche use case, with this project being geared towards serverless, so it probably doesn't make sense for baked in support.
However, IMO blitz has a lot of great features other than serverless, but needing to use websockets or other long-running server features shouldn't preclude you from using the rest of blitz.

Seems like exposing the server Next-style and adding an example/installer/recipe would be quite nice.

I'd be happy to try to help make it happen!

[flybayer]

Ok let's do that. Support a custom server.js file.

If server.js is present, blitz start will use that instead of next dev/start

[dajinchu]

Hey, got caught up with consultancy stuff but have time to pick this back up. I'm unsure what our API for hooking a custom server into Blitz should be and whether we should expose a hook or let people just use next's custom server?

Theoretically, we could just let people import next and use their getRequestHandler exactly as displayed in their docs https://nextjs.org/docs/advanced-features/custom-server
Not sure what our policy is on letting next.js "leak" into Blitz userland code?

Additionally, it seems like #471 would impact how importing next would work, so I'm unsure what the play is here.

@flybayer advice would be greatly appreciated :)

[flybayer]

Good question! My initial thought is to let people use the custom server just like next, but we can import from 'blitz' instead of 'next'.

@ryardley do you have thoughts on this?

471 will not affect this, since Next is installed one way or the other.

[ryardley]

My opinion might be a little extreme but I think that Blitz should own data fetching wholesale and this should be done by having code that runs on the server calling and talking to code that runs in the browser using the framework. This might be more neatly done using a pubsub system but we might be able to workshop it to be congruent with our current APIs. In theory we should not need to support a websocket server although we would use it under the hood and perhaps provide plugins for pusher, custom servers etc.

This is rough off the top of my head but I think it is worth exploring

import clientResolver from '...';

@server()
function serverResolver(args){
  // would only fire for the current users browser session
  clientResolver(args)
}

import serverResolver from '...';

@client()
function clientResolver(args){
  // some how set data on the datastore in the react app
  // leads to a greater question about blitz and how it caches data on the clientside and how we can interact with it outside of the data queries we are using
}

[dajinchu]

I think with or without explicit data fetching support, there will inevitably be an ask for custom server support, so I think we can still just follow the next.js custom server pattern?

[flybayer]

Yes that's what I think @dajinchu

[ryardley]

Yes I agree we should support using blitz in the same way that one would use next. so custom server support needs to be supported. I just think websockets is something blitz should try to manage.

[flybayer]

To summarize how to build this:

• Enable custom server by adding server.js at the project root
• Start blitz the same as without custom server via blitz start and blitz start --production

And basically what we'll do with blitz start is run node .blitz/caches/dev/server.js and node .blitz/caches/build/server.js.

In a Next.js app you have this inside the server file:

const next = require('next')
const app = next({ dev })

But in Blitz we can rename those and export like this:

const {createBlitzApp} = require('@blitzjs/server')
const app = createBlitzApp({ dev })

[KATT]

I have made a working POC of something similar to what @flybayer proposes in #1492.