Plans for future maintenance

Hello,
I'm currently deploying a business-critical application using iisnode on IIS 10, and was wondering if there are plans for continual maintenance on this project. I'm aware that iisnode works on IIS 10, but as updates occur, we'll need to continue to support this project, and I want to verify that iisnode will continue to work.

Any news on this?

Mario Meyrelles (@mariomeyrelles)

@JonathanJamesRasmussen , Mario Meyrelles (@mariomeyrelles) I hope this helps:

https://twitter.com/AzureSupport/status/1153806803265654787

FYI, Azure support has redirected me to the IIS forum:

If there was someone at Microsoft responsible for this project, we would have gotten an answer much faster than this.

So I think this answers your question.

Mario Meyrelles (@mariomeyrelles)

@JonathanJamesRasmussen Mario Meyrelles (@mariomeyrelles) Michael Haufe (@mlhaufe) Daan (@landgenoot) We apologize for the delay in reaching out to you. We checked with the product group and they verified that they have no plans to deprecate IISNode at this time. Thank you for your patience.

There is a difference between deprecated and abandoned.

Can you be more specific about the future plans? When can we expect someone to look at the pull request that have been open for over a year? Right now, it is not actively maintained in my humble opinion.

Daan (@landgenoot)

Daan (@landgenoot) Thank you for your concerns. I have shared them with the product group and will share any updates with you as they develop. We appreciate your patience.

@BryanTrach-MSFT Thanks for reaching out to the product group. Do you have any further information on the status of this product?

@JonathanJamesRasmussen Apologies for the delay, we are working internally with our product team to get more details on this, will keep you updated as we hear more. Thanks again for your patience.

It's been a few months. @BryanTrach-MSFT we would love to know if this is going to be maintained by MSFT so we can decide whether this is a viable solution or if we need to move in fear of deprecation/EOL.

We have been running IISNode for a number of years (5+) and it has been the weakest link in our Azure cloud infrastructure.

Decomposing an HTTP request we get the following pipeline:

Chrome [OK] --->
Azure Windows Server [OK] --->
IIS [OK] --->
IISNode [?] --->
NodeJS [OK] --->
In-house Code [That's our problem]

Currently, we are trying to investigate a performance issue where the first request is taking between 4 - 20 seconds.

Here are some UTC timings taken today:

Sent by Chrome at 19.56:00
Received by IIS at  19.56:00
 <IISNode> 			  <---- 14 seconds lost
Received by Node at 19:56:15 	
Returned by Node  at  19:56:15
Returned by IIS  at  19:56:15
Chrome Reported Duration =  14.74 seconds

We've tried all the settings in ISSNode. With the only alternative to IISNode being a completely radical rewriting of the deployment process, we feel we're stuck between a rock and a hard place.

I feel there is no point opening a new issue considering the last release was over 2 years ago.

@BryanTrach-MSFT, since IISNode is not deprecated, how do we get someone to investigate these issues?

Thanks

PS: This is not an IIS cold-start problem, because we already have configured the IIS-ApplicationInit feature which has ensured the NodeJS processes are up and running. There is something wrong with the IISNode routing and no way to figure this out.

I've recently moved away from a node backend and adopted dotnet core with C# on the backend and just providing RESTful APIs (or GraphQL in some instances) through that platform.

It's a little disturbing that MS seem to have problems curating their official repos. Yes, there are a lot of them, but when investigating a problem space that is precisely why it is so important to be able to quickly see the "archived" banner for stuff which is now old hat or abandoned

@BryanTrach-MSFT
It is problematic to run missing critical apps on Azure App Service (Node) if one of the core components in the pipeline e.g. iisnode is not being actively maintained anymore. I came here to report a bug in iisnode but I guess what I will need to do is to find an alternative platform to host Node.

I think no answer is the answer. I posted a note last year (!) and got sent to this ticket also.

It's no answer.

No updates for a LONG time :(

Where is it going?

Is IIS with any modern technologies now abandoned?

BharathNimmala-MSFT

I came across this article dated 3/23/2022 and it gave me a glimpse of hope that iisnode is still actively being used by MS. https://learn.microsoft.com/en-us/azure/app-service/app-service-web-nodejs-best-practices-and-troubleshoot-guide

I have been running in production iisnode on a server 2012r2 for about the last 7 years and I'm starting to look into upgrading to server 2022 but I am concerned by this thread.

What are some of the alternatives to iisnode that individuals have used? I was thinking about using HttpPlatformHandler or setting up IIS as a reverse proxy.

I would love to keep using iisnode but am concerned like everyone else in this thread.
@BryanTrach-MSFT BharathNimmala-MSFT any update or comment?

While the main question about IISNode's future remains unknown, you should know that HttpPlatformHandler (also from Microsoft) has been a good alternative since 2015, https://docs.lextudio.com/blog/the-rough-history-of-iis-httpplatformhandler/ And it works for both IIS and Azure App Service.

While the main question about IISNode's future remains unknown, you should know that HttpPlatformHandler (also from Microsoft) has been a good alternative since 2015, https://docs.lextudio.com/blog/the-rough-history-of-iis-httpplatformhandler/ And it works for both IIS and Azure App Service.

Does HttpPlatformHandler also need the UrlRewrite stuff? I tried configuring IISNode with path="*" but it seems like this will not be fixed unless someone from the community fixes it. I'll give HttpPlatformHandler a go in the mean time...

Louis Somers (@mlsomers)

Does HttpPlatformHandler also need the UrlRewrite stuff?

No. You can use HttpPlatformHandler without URL rewrite module, because it uses its own internal rewrite engine to proxy requests from IIS pipeline to Node.js web server. That's why you can see that no more complex rewrite rules in the examples. Louis Somers (@mlsomers)

Navigation Menu

Repository navigation

Plans for future maintenance #76

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Plans for future maintenance #76

Description

Activity

mariomeyrelles commented on Jul 23, 2019

mlhaufe commented on Jul 23, 2019

mlhaufe commented on Aug 19, 2019

landgenoot commented on Sep 4, 2019

BryanTrach-Personal commented on Sep 16, 2019

landgenoot commented on Sep 16, 2019

BryanTrach-Personal commented on Sep 17, 2019

StellaJaneRasmussen commented on Nov 4, 2019

BharathNimmala-MSFT commented on Nov 13, 2019

timothyfarmer commented on Feb 6, 2020

NoelAbrahams commented on Feb 24, 2020

timothyfarmer commented on Jun 3, 2020

DevRCRun commented on Sep 9, 2020

drian0 commented on Mar 17, 2021

jgwinner commented on Aug 26, 2021

jgwinner commented on Aug 28, 2021

chrisgh1 commented on Oct 21, 2022

lextm commented on Jun 1, 2024

mlsomers commented on Oct 24, 2024

lextm commented on Nov 6, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions