Non-Express version?

[isaachinman]

Hi @jamuhl - wanted to raise an issue (finally) for this long-standing desire.

Currently, i18next-express-middleware powers next-i18next and is a critical dep. The fact that we're relying on Express unfortunately means we're tied to a custom-Node-server type of setup.

This prevents next-i18next and any other consumers from going serverless.

I wonder what, if any, features of Express are being used here that couldn't be relatively easily replaced by vanilla Node HTTP interfaces? If this package exported a middleware that did not rely on Express syntax/features, and consumed normal HTTP interfaces, it could be used not only in serverless applications, but also with other HTTP frameworks like Koa, Hapi, etc.

Let me know what you think. I am mostly interested in your opinion of how much work this would take. I am very happy to fork this repo and maintain a i18next-node-middleware sort of thing if necessary. But, I do believe that using vanilla interfaces is the best way forward to enable the most users possible.

[jamuhl]

Sorry for the late reply...this one got under the radar at some point...(I missed to reply instantly and forgot about it totally).

I think there is not too much express specific things in this...and it should be not to hard to convert it to not depend on express.

[isaachinman]

@jamuhl Since Express is a superset of normal HTTP interfaces, would you be open to changing the default i18next middleware to not rely on Express if we end up finding that this is possible?

This change shouldn't affect users at all, as the config/API and behaviour would remain exactly the same.

It would allow i18next to be used in serverless setups, and also allow Koa/Hapi users to use the middleware.

[jamuhl]

sure that would be awesome...just we would have to rename this repo afterwards to some more general name...or create a new one and mark this obsolete with a link on the new one...

[isaachinman]

@jamuhl Unless I've missed something, it was indeed quite simple. Do you have time to review #191?

In general, I think the best approach is to create an entirely new repository and deprecate this one, but I will leave that up to you. I think renaming could cause confusion for users and may make upgrading kind of weird.

[jamuhl]

@isaachinman looks ok to me...and yes I think we better take the way of creating a new repository / npm module and deprecate this one...

Currently lack of a good idea for the name...i18next-node-http, i18next-node-middleware, i18next-middleware ?!?!

[isaachinman]

I prefer i18next-middleware, but aren't there other languages in the i18next ecosystem? Maybe i18next-node-middleware is the safest bet.

[adrai]

i18next-http-middleware?

[jamuhl]

there is i18next-php, i18next-net, ... so currently I am for adding node somewhere

i18next-node-middleware
i18next-node-http

let see if we get some suggestions until tomorrow - will then create a new repo

[cryptiklemur]

i18next-node-middleware makes the most sense IMO

[isaachinman]

Yes, i18next-node-middleware is fine. There's still some work to be done on the PR and I'd appreciate any help that can be offered!

Let's wait until the PR is mergeable, and then clone this repo into i18next/i18next-node-middleware and release it on a prerelease/alpha.

[jamuhl]

@isaachinman just created and added you as admin: https://github.com/i18next/i18next-node-middleware

[gurkerl83]

@iamjochem I have continued on my local branch, today. Express provides a powerful middleware concept, which to my knowledge is not available in vanilla HTTP provided by Nodes http library. The current approach is to use the connect library, which provides a middleware concept for http. After working on this for some time, I switched to next-i18next to see how this library gets integrated. Is my understanding correct that next-i18next uses the i18next-express-middleware but also others for locale subpath work?

To me, it's quite confusing spreading middleware logic throughout several libraries. Another question is about custom servers, which, according to the Next developers, gets not supported in serverless deployment. I saw a lot of projects are deploying Express in their Next project. But what is the difference, implementing a server through Nodes http library is basically a server, too right. So the general question is - are sever deployments supported in a serverless development concept, or do we need to fetch resources like i18n files directly with Next?

[isaachinman]

@gurkerl83 Please do not double post - it isn't helpful to anyone.

To answer your questions:

1. Middleware is not a "thing" in vanilla Node HTTP, but can be replicated in just a few lines
2. You are currently writing in an issue inside the i18next-express-middleware repository. It is indeed used by next-i18next, but that is completely coincidental for our purposes here. They are separate packages and serve separate purposes
3. i18next-express-middleware has nothing to do with NextJs

The work that needs to be done here has nothing to do with next-i18next or NextJs. Let's not confuse things!

[adrai]

@isaachinman perhaps this may help: https://github.com/i18next/i18next-http-middleware

[isaachinman]

@adrai Very nice! I remember discussing this with @jamuhl. Is this ready for me to have a look?

[adrai]

@isaachinman for sure 😉

[isaachinman]

@adrai Here's a PR on next-i18next tracking usage: i18next/next-i18next#688. I was able to do a simple find-and-replace, and our test suite is green. Looks very good initially!