Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Code Reviews Meta
Q&A
Posts Tags Edits
Ask Question

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

77%
+5 −0
Q&A Using an existing web server vs writing your own

3rd Option: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common. There are a few reason I ...

posted 1y ago by jmathew‭  ·  edited 1y ago by jmathew‭

Answer
#4: Post edited by user avatar jmathew‭ · 2023-10-20T18:50:56Z (about 1 year ago)
  • **3rd Option**: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common.
  • There are a few reason I do this:
  • * Something like Nginx is more tested than your framework's internal networking code. So it's safer to be exposed to the internet. Its scope is more limited (ie it only does networking) which means there's less to be exploited. This security applies strictly to the handling of network requests, obviously your application can still be exploited in other ways even behind a proxy.
  • * There are more 'network transport' level features that are going to be available because that's all those those products are designed to do.
  • * There are some tasks that don't make sense to include in your application code at all. For example load balancing between several copies of your application server.
  • * You can hand off your application server to a devops/sysadmin and let them manage the network traffic. If the application is designed to solely handle its own traffic, those teammates will now need to know how to code in your language to configure it.
  • * Simplifies your application server code. For example, handling HTTPS can require extra configuration specific to your framework. You'll still require that configuration if you put an existing web server in front of you application server but there is likely to be much more resources available for figuring out how to do that.
  • I'm not familiar with Rust, but in ASP.net there's Kestrel which is a webserver built into the framework. But typically you would not deploy it facing the internet.
  • [Their reasoning (reverse proxy being the 'existing web server'):](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-7.0)
  • > Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.
  • > A reverse proxy:
  • > * Can limit the exposed public surface area of the apps that it hosts.
  • > * Provides an additional layer of configuration and defense.
  • > * Might integrate better with existing infrastructure.
  • > * Simplifies load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires the X.509 certificate for the public domain(s). That server can communicate with the app's servers on the internal network using plain HTTP or HTTPS with locally managed certificates. Internal HTTPS increases security but adds significant overhead.
  • **3rd Option**: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common.
  • There are a few reason I do this:
  • * Something like Nginx is more tested than your framework's internal networking code. So it's safer to be exposed to the internet. Its scope is more limited (ie it only does networking) which means there's less to be exploited. This security applies strictly to the handling of network requests, obviously your application can still be exploited in other ways even behind a proxy.
  • * There are more 'network transport' level features that are going to be available because that's all those those products are designed to do.
  • * There are some tasks that don't make sense to include in your application code at all. For example load balancing between several copies of your application server.
  • * You can hand off your application server to a devops/sysadmin and let them manage the network traffic. If the application is designed to solely handle its own traffic, those teammates will now need to know how to code in your language to configure it.
  • * Simplifies your application server code. For example, handling HTTPS can require extra configuration specific to your framework. You'll still require that configuration if you put an existing web server in front of you application server but there is likely to be much more resources available for figuring out how to do that.
  • I'm not familiar with Rust, but in ASP.net there's Kestrel which is a webserver built into the framework. But typically you would not deploy it facing the internet.
  • [Their reasoning (reverse proxy being the 'existing web server'):](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-7.0)
  • > Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.
  • > A reverse proxy:
  • > * Can limit the exposed public surface area of the apps that it hosts.
  • > * Provides an additional layer of configuration and defense.
  • > * Might integrate better with existing infrastructure.
  • > * Simplifies load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires the X.509 certificate for the public domain(s). That server can communicate with the app's servers on the internal network using plain HTTP or HTTPS with locally managed certificates. Internal HTTPS increases security but adds significant overhead.
  • The only case where I wouldn't care to put a proxy in front of my application server would be for proofs of concept and application servers that don't face the internet.
#3: Post edited by user avatar jmathew‭ · 2023-10-20T18:49:25Z (about 1 year ago)
  • **3rd Option**: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common.
  • There are a few reason I do this:
  • * Something like Nginx is more tested than your framework's internal networking code. So it's safer to be exposed to the internet. It also "does less" which means there's less to be exploited. This security applies strictly to the handling of network requests, obviously your application can still be exploited in other ways even behind a proxy.
  • * There are more 'network transport' level features that are going to be available because that's all those those products are designed to do.
  • * There are some tasks that don't make sense to include in your application code at all. For example load balancing between several copies of your application server.
  • * You can hand off your application server to a devops/sysadmin and let them manage the network traffic. If the application is designed to solely handle its own traffic, those teammates will now need to know how to code in your language to configure it.
  • * Simplifies your application server code. For example, handling HTTPS can require extra configuration specific to your framework. You'll still require that configuration if you put an existing web server in front of you application server but there is likely to be much more resources available for figuring out how to do that.
  • I'm not familiar with Rust, but in ASP.net there's Kestrel which is a webserver built into the framework. But typically you would not deploy it facing the internet.
  • [Their reasoning (reverse proxy being the 'existing web server'):](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-7.0)
  • > Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.
  • > A reverse proxy:
  • > * Can limit the exposed public surface area of the apps that it hosts.
  • > * Provides an additional layer of configuration and defense.
  • > * Might integrate better with existing infrastructure.
  • > * Simplifies load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires the X.509 certificate for the public domain(s). That server can communicate with the app's servers on the internal network using plain HTTP or HTTPS with locally managed certificates. Internal HTTPS increases security but adds significant overhead.
  • **3rd Option**: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common.
  • There are a few reason I do this:
  • * Something like Nginx is more tested than your framework's internal networking code. So it's safer to be exposed to the internet. Its scope is more limited (ie it only does networking) which means there's less to be exploited. This security applies strictly to the handling of network requests, obviously your application can still be exploited in other ways even behind a proxy.
  • * There are more 'network transport' level features that are going to be available because that's all those those products are designed to do.
  • * There are some tasks that don't make sense to include in your application code at all. For example load balancing between several copies of your application server.
  • * You can hand off your application server to a devops/sysadmin and let them manage the network traffic. If the application is designed to solely handle its own traffic, those teammates will now need to know how to code in your language to configure it.
  • * Simplifies your application server code. For example, handling HTTPS can require extra configuration specific to your framework. You'll still require that configuration if you put an existing web server in front of you application server but there is likely to be much more resources available for figuring out how to do that.
  • I'm not familiar with Rust, but in ASP.net there's Kestrel which is a webserver built into the framework. But typically you would not deploy it facing the internet.
  • [Their reasoning (reverse proxy being the 'existing web server'):](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-7.0)
  • > Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.
  • > A reverse proxy:
  • > * Can limit the exposed public surface area of the apps that it hosts.
  • > * Provides an additional layer of configuration and defense.
  • > * Might integrate better with existing infrastructure.
  • > * Simplifies load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires the X.509 certificate for the public domain(s). That server can communicate with the app's servers on the internal network using plain HTTP or HTTPS with locally managed certificates. Internal HTTPS increases security but adds significant overhead.
#2: Post edited by user avatar jmathew‭ · 2023-10-20T18:42:32Z (about 1 year ago)
  • **3rd Option**: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common.
  • There are a few reason I do this:
  • * Something like Nginx is more tested than your framework's internal networking code. So it's safer to be exposed to the internet.
  • * There are more 'network transport' level features that are going to be available because that's all those those products are designed to do.
  • * There are some tasks that don't make sense to include in your application code at all. For example load balancing between several copies of your application server.
  • * You can hand off your application server to a devops/sysadmin and let them manage the network traffic. If the application is designed to solely handle its own traffic, those teammates will now need to know how to code in your language to configure it.
  • * Simplifies your application server code. For example, handling HTTPS can require extra configuration specific to your framework. You'll still require that configuration if you put an existing web server in front of you application server but there is likely to be much more resources available for figuring out how to do that.
  • I'm not familiar with Rust, but in ASP.net there's Kestrel which is a webserver built into the framework. But typically you would not deploy it facing the internet.
  • [Their reasoning (reverse proxy being the 'existing web server'):](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-7.0)
  • > Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.
  • > A reverse proxy:
  • > * Can limit the exposed public surface area of the apps that it hosts.
  • > * Provides an additional layer of configuration and defense.
  • > * Might integrate better with existing infrastructure.
  • > * Simplifies load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires the X.509 certificate for the public domain(s). That server can communicate with the app's servers on the internal network using plain HTTP or HTTPS with locally managed certificates. Internal HTTPS increases security but adds significant overhead.
  • **3rd Option**: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common.
  • There are a few reason I do this:
  • * Something like Nginx is more tested than your framework's internal networking code. So it's safer to be exposed to the internet. It also "does less" which means there's less to be exploited. This security applies strictly to the handling of network requests, obviously your application can still be exploited in other ways even behind a proxy.
  • * There are more 'network transport' level features that are going to be available because that's all those those products are designed to do.
  • * There are some tasks that don't make sense to include in your application code at all. For example load balancing between several copies of your application server.
  • * You can hand off your application server to a devops/sysadmin and let them manage the network traffic. If the application is designed to solely handle its own traffic, those teammates will now need to know how to code in your language to configure it.
  • * Simplifies your application server code. For example, handling HTTPS can require extra configuration specific to your framework. You'll still require that configuration if you put an existing web server in front of you application server but there is likely to be much more resources available for figuring out how to do that.
  • I'm not familiar with Rust, but in ASP.net there's Kestrel which is a webserver built into the framework. But typically you would not deploy it facing the internet.
  • [Their reasoning (reverse proxy being the 'existing web server'):](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-7.0)
  • > Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.
  • > A reverse proxy:
  • > * Can limit the exposed public surface area of the apps that it hosts.
  • > * Provides an additional layer of configuration and defense.
  • > * Might integrate better with existing infrastructure.
  • > * Simplifies load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires the X.509 certificate for the public domain(s). That server can communicate with the app's servers on the internal network using plain HTTP or HTTPS with locally managed certificates. Internal HTTPS increases security but adds significant overhead.
#1: Initial revision by user avatar jmathew‭ · 2023-10-20T18:40:51Z (about 1 year ago) 
**3rd Option**: You put a web server like Nginx, etc in front of your application server which can also handle 'raw' network traffic. Even in the PHP scenario this is common. 

There are a few reason I do this:
* Something like Nginx is more tested than your framework's internal networking code. So it's safer to be exposed to the internet.
* There are more 'network transport' level features that are going to be available because that's all those those products are designed to do. 
* There are some tasks that don't make sense to include in your application code at all. For example load balancing between several copies of your application server. 
* You can hand off your application server to a devops/sysadmin and let them manage the network traffic. If the application is designed to solely handle its own traffic, those teammates will now need to know how to code in your language to configure it.
* Simplifies your application server code. For example, handling HTTPS can require extra configuration specific to your framework. You'll still require that configuration if you put an existing web server in front of you application server but there is likely to be much more resources available for figuring out how to do that.

I'm not familiar with Rust, but in ASP.net there's Kestrel which is a webserver built into the framework. But typically you would not deploy it facing the internet.

[Their reasoning (reverse proxy being the 'existing web server'):](https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel/when-to-use-a-reverse-proxy?view=aspnetcore-7.0)

> Even if a reverse proxy server isn't required, using a reverse proxy server might be a good choice.
> A reverse proxy:
> * Can limit the exposed public surface area of the apps that it hosts.
> * Provides an additional layer of configuration and defense.
> * Might integrate better with existing infrastructure.
> * Simplifies load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires the X.509 certificate for the public domain(s). That server can communicate with the app's servers on the internal network using plain HTTP or HTTPS with locally managed certificates. Internal HTTPS increases security but adds significant overhead.