vote: make underlying server lib replaceable

[smashercosmo]

Please vote for this feature by using the Github Reactions button and the 👍 reaction. When this feature reaches 70 votes, it will be reconsidered.

---

I have a feeling that this is a "won't fix", but still...

Feature Use Case

It's a best practice to have local dev and prod setups as similar as possible. So, if we are using express or hapi as our production server (with different middlewares, sessions, authorization logic etc.), it's quite strange to implement the same server logic with koa for local development.

Feature Proposal

Have no idea what's the best way to implement it.

[TrySound]

Why introduce this complexity? To save some bytes in node_modules?

[smashercosmo]

I don't quite get your question. I'm not talking about bytes, I'm talking about sharing server logic between production and development server.

[shellscape]

Express middleware can typically be used with koa via koa-connect, koa-connect2, etc. If there is middleware from another vendor you'd like to use that isn't playing nicely, I'm happy to help with making that work. And I'd ask you give that possibility a chance first.

But, as you feared, I'm of the opinion that making the underlying server hot-swappable would introduce way more complexity than needed or of benefit to our userbase.

I wil however tag this as a vote-feature request with a threshold. If it gets enough votes, we can take another look at it.

Note that if we did allow for this, you'd have to re-implment the entirety of processes that we run internally around Koa. And at that point, given all of the extra work, why run this plugin instead of a custom dev setup?

FWIW vote thresholds are determined by using a whole number that is roughly 10% of the NPM downloads for the given month. If a feature isn't deemed acceptable or widely useful initially, it should meet the criteria of being useful to at please 10% of the user base. Thresholds are never raised, but they can be lowered.

[mindpivot]

I don't think it's a good idea to view WPS as a replicated environment of your server environment. It is brittle long-term to co-locate a node server's build process with the client app's build process.

Maybe I'm wrong here but it seems the WPS use-case is for client-code development, not server development. If you intend to develop both at the same time I've found it's more durable to isolate client development from server development and run both development servers concurrently when developing both at the same time.

I personally use a docker image (but virtual paths would work for a non-docker project) to map my node.js server to the output location of a WPS development build and turn on watch on the server. When WPS outputs new assets in the client app, the browser window pointed to the client build refreshes and the files update triggers the watch on the node.js server which refreshes the second browser window pointed at its url endpoint.

To that end, any middleware used in WPS should in most cases be specifically written for the needs of the development server, not the production server. If you happen to be able to re-use one or more pieces of server middleware between environments that's cool but I certainly wouldn't pursue it as a goal or development practice.

If you're interested in writing your development server in an Express/Hapi style, @shellscape's point about using koa's converters would be the route to pursue.