GSoC Refactor: serverMode, clientMode, replace sockjs with ws

[hulkish]

• we should not define sockjs as a direct dependency, by default this will be replaced with ws
• clientMode: 'ws', by default
• user must install sockjs themselves, then set clientMode: require.resolve('sockjs') if they want to support older browsers with dicey websocket support.

[knagaitsev]

If we do that require method to allow sockjs as a clientMode then if the user wanted to make their own server implementation they would need to implement in the same way as the sockjs API, specifically the parts the Dev Server uses (they would need a createServer method, event listeners, etc.). We could also alter this API slightly as we like and create adapters for essential servers like sockjs. Then we can make an adapter for ws and simply implement it as the default in that way. (Should this be called serverMode instead since it is the server implementation?)

We need a similar method for the client. I'm not sure how to do this best so that the user can pass their implementation into the Node server. Maybe I am missing an easier way. My thoughts are:

• user specifies a path to their client implementation script/package
• script/package is added to the Webpack compilation as an entry
• dev server client uses user's client implementation

[knagaitsev]

Tasks to complete for client/server refactor:

Server

• Encapsulate SockJS server (started above)
• Deal with any SockJS workarounds that have been added to the Dev Server over time
• Finalize a server wrapper API that is simple, such that users can implement their own wrappers (prototype here)
• Use the wrapper to encapsulate ws
• Switch to native WebSockets on client for simple proof of concept with ws
• Add serverMode option which takes a string for existing/default implementations, or a class (extending some class like BaseServer) which the user would have to implement themselves

Client

• Create client wrapper API, similar to that of server
• Encapsulate SockJS client, native WebSockets using the wrapper
• Insert client implementation as an entry in the Webpack compilation, making it easier for the user to supply their own implementation (tentative, see my comment above)
• Add clientMode option, again takes a string for existing/default implementations or a class that the user implements

Extra

• Add functionality for the user to send their own custom messages from the server/client or intercept incoming/outgoing messages

Edit

• Add checks to ensure that the user implemented custom server/client correctly
• Add checks to confirm that the server and client types that the user chooses are compatible (e.g. ws server should go with ws client)

[hulkish]

@Loonride LGTM @evilebottnawi thoughts?

[alexander-akait]

LGTM, we can introduce serverMode and clientMode as experimental to allow us do breaking changes without major release

Don't forget about CLI refactor

[alexander-akait]

/cc @Loonride friendly ping, what is status of ws?

[knagaitsev]

@evilebottnawi Once #2090 is merged, ws mode will work by doing:

{
  serverMode: 'ws',
  clientMode: 'ws'
}

Then what remains is:

Higher priority

• Update docs
• Make ws mode default on next branch (Should be an easy switch)

Lower priority (More related to custom implementations than to ws)

• Add checks to ensure that the user implemented custom server/client correctly (Some discussion on this here: feat(server): check that serverMode implementation is correct #2051)
• Add checks to confirm that the server and client types that the user chooses are compatible (e.g. ws server should go with ws client)
• Add functionality for the user to send their own custom messages from the server/client or intercept incoming/outgoing messages (I'm unsure if this is a desired feature at all, and you could technically do it already by providing your own serverMode and clientMode implementations)

[alexander-akait]

{
  serverMode: 'ws',
  clientMode: 'ws'
}

For do you think about union this options to one,

• mode: 'ws` - set websocket
• mode: { serverMode: 'ws' } - ser only server in ws mode
• mode: { clientMode: 'ws' } - ser only client in ws mode
• mode: { serverMode: 'ws' and clientMode: 'ws' } - set server and client in ws mode, same as { mode: 'ws }

Why?

• Easy configuration, no need two option
• Better DX

[knagaitsev]

@evilebottnawi Good idea, maybe we should use a different name like socketMode or transportMode though?

[alexander-akait]

agree, transportMode sounds good, in theory transport can be not socket
/cc @hiroppy what do you think about name?

[hiroppy]

I like this schema:)

transportMode: {
  server: 'ws',
  client: 'ws'
}

[alexander-akait]

@Loonride yep, let's rename mode to transportMode, we can't save compatibility because it is experimental

[alexander-akait]

Done and ws is default for v4