9 ms·

I used to use PHP as a web backend and then moved to Go. Forgetting the debate about the actual languages, it makes so much more sense to me for a web app to b

I used to use PHP as a web backend and then moved to Go. Forgetting the debate about the actual languages, it makes so much more sense to me for a web app to be a full-fledged, self-contained program which happens to listen on a network interface and respond when things make HTTP requests at it. The old-school style, where routes map to scripts or parts of scripts and a separate web server like Apache or Nginx sits in front of the app, feels harder to reason about (does this thing persist across requests?), harder to debug (where did that error message end up?) more brittle (did this fail because of my script or my web server config or something else?) and more dependent on configuration magic (i.e. various text files lying around governing the behaviour of things). So although some of these changes look cool, I don't think it's the language itself that most needs improving.

waheoo 6y ago
Interesting take. I don't really agree, php routes are handled natively and very simply and easy to reason about using the .php extension. Its the frameworkers that broke that design with clean urls and fancy complicated routers. Php behind Apache or nginx is incredibly simple and easy to reason about. Browser loooks up this file url, this file url runs as a script and its output is returned. A bug in one file isn't propogated to all others so you can have highly reliable services with only partial failures from time to time. Whereas a bug in one route of a golang server may take the entire service offline. I do much prefer the deployment and shipability of a golang service, so much I am willing to give up the simplicity of PHP.
sergiosgc 6y ago
Funny. I completely disagree, and actually find it odd someone actually wants desktop style application state on web apps. One of the beauties of the PHP style of app execution is that application state is a lot simpler. Instead of having a running application server-side, which can be in a continuum of states, PHP forces you to start every request with a blank slate. Application state must be explicit (with serialized server-side sessions or browser-stored cookies). This makes it trivial to reproduce requests, trivial to debug, trivial to scale horizontally. To each his own, I guess. I just find your position genuinely surprising.
- zapt02 6y ago
  By starting every request from a clean slate, you have much less mental overhead (did I accidentally reuse a variable from a previous request?) and it eliminates an entire class of programming bugs. It's the best thing about PHP, and despite this approach PHP still runs faster than many similar languages.
  - mjw_byrne 6y ago
    I think the "clean slate" benefit is achievable almost for free in a monolith though - each request is a separate invocation of a handler function which is given the context it needs to run (e.g. an HTTP request, an output stream and user-defined context). The user-defined context is the only route into the application state and can be as wide or narrow as you need. So you can share persistent state deliberately, e.g. by having that context contain a pointer to a db conn, but this is always a conscious, opt-in choice, and errors like accidental reuse should be impossible unless you're doing something inadvisable like using global variables.
    - fetbaffe 6y ago
      After doing Java Spring I realized that the Java monolith was very leaky and inflexible. That is why you have strong trend of micro services. In 99.9% of cases in web development you want the PHP model of doing things. The 0.1% case is the asynchronous background job, that can be solved, maybe not as elegant as in other languages, but why optimize the edge case?
      - jjeaff 6y ago
        My backend is written in php and I simply have a separate container running a copy of the same php codebase that has a long running process pulling from a pubsub queue in a loop. So anything that needs to be processed asynchronously, like say, sending out a few dozen emails or notifications, I just publish the task to the queue and that other container handles them. This could be simplified even further if you use a pubsub service that can post data to a url as it comes in. Thus allowing the single php container to asynchronously process the tasks all in their own individual threads. This didn't work for me as Google cloud's pubsub seems to absolutely flood it's target with requests seemingly ignoring 503 or any other error code and not backing off until it has dos'ed your server.
fetbaffe 6y ago
Personally I think that separating the application from the web server is good thing, but I do agree that this is the part that can give you the most trouble. Running a PHP project isn’t as easy as git clone make run because of the web server. Difficult to configure, hard to share configurations between machines, differences between operating systems (and Linux distributions) where to put configurations, different ways to hook into php. Projects starting to rely on specific web server configurations for different application behavior, e.g. htaccess files. Hard to debug when you need to special request handling like terminating the request but continue executing or continuously stream data (web server response cache). I guess that is the price you pay for separating the application from the web server.
clon 6y ago
Absolutely, having a service that just listens on port 80 is so much simpler to reason about. I would also add a much easier development setup, as well as deployment to your list of advantages. That said, having a Go service just be exposed to the wild wild internet may not be a smart idea. Take a look at this issue [1], it is perfectly clear that Go services (relying on net/http) still need babysitting by a competent reverse proxy. It is a case where Go's mantra about simplicity leads to leaky abstractions and just clearly immature solutions. Also not talking about TLS certs, WAF and other concerns that also may bring nginx etc on board anyhow. [1] https://github.com/golang/go/issues/16100 https://github.com/golang/go/issues/16100
- eggsnbacon1 6y ago
  Lol I remember seeing this timeout issue years ago and immediately deciding I would never use Go for HTTP (which is what it was designed for). This makes Go vulnerable to numerous slow attacks and there's no way around it besides "use a proxy". My guess as to why this issue is left open? Google has global timeouts set on all the network edges so they don't want each service to use its own. Whats good for Google overrides whats good for the supposedly open source project. This is pervasive in most of their projects. Google open source is like the Reapers from Mass Effect series. They leave some crumbs behind to ensure the software ecosystem develops along desired paths. Not out of charity, they do it to ensure a successful harvest.
  - clon 6y ago
    This timeout issue is indeed baffling. I believe many Go services out there may have set their timeouts to something ridiculous like 3600 or 86400 as a "fix". Hello slow lori. Another concern is that the lifetime of a PHP app is rather short, measured in milliseconds. This is actually a rather robust approach. Crashes, memory leaks, all sort of weird states are brushed away immediately to be replaced with fresh state for the next request. Apache/nginx is acting as a supervisor and allowing a lot of shit code live out it's days unnoticed. Contrast that with long-running Golang processes. You won't get away with sloppy code there, raising he bar considerably. Running a Go executable without a monitoring supervisor is sketchy at best.
golergka 6y ago
> web app I think that this vague definition, right here, is the source of disagreement. Are we talking about small blog with comments? Or are we talking about one of the services of a medium-sized company, that needs to provide a platform-agnostic API, and real-time updates to subscribed clients with websockets?
- mjw_byrne 6y ago
  Yeah, in my case I'm talking about a thing that is largely a web app but also does other things which don't fit well into the one-script-execution-per-request model. That being said, I would still prefer a monolithic application for a small blog with comments because I think it's easier to manage, deploy, encapsulate, test etc.
AegirLeet 6y ago
The old-school style you describe is indeed old-school and was abandoned by most PHP developers ~10 years ago. Modern PHP projects will have a single entry point that handles all requests, with path-based routing done in code.
- jrururufuf666 6y ago
  in cheap shared hosting apache setups its still the best way to do 7t oldschool. still love it
dingdingdang 6y ago
I know this replicates the sentiment expressed by other in this thread but still: Go does not do away with the need for front end servers for deployed end products. And so the eventual proxying Go behind Nginx or Apache comes with it's own cost since Go is nowhere near as tested as PHP when it comes to server integration.
stephenr 6y ago
Shared nothing is a huge benefit in simplicity. “Does this thing persist across requests” is ridiculously simple to answer in php because the answer is “no, unless you very explicitly told it to”. In a go or java or whatever service you have to know if your “thing” is specific to the request handler, or if it’s part of shared state. There is no reason that routing in a php app has to be done via mapping urls to php files, it’s a very common practice to have a front controller that bootstraps the app environment and in turn handles routing of the request to a piece of logic.

waheoo 6y ago

Interesting take. I don't really agree, php routes are handled natively and very simply and easy to reason about using the .php extension. Its the frameworkers that broke that design with clean urls and fancy complicated routers. Php behind Apache or nginx is incredibly simple and easy to reason about. Browser loooks up this file url, this file url runs as a script and its output is returned. A bug in one file isn't propogated to all others so you can have highly reliable services with only partial failures from time to time. Whereas a bug in one route of a golang server may take the entire service offline. I do much prefer the deployment and shipability of a golang service, so much I am willing to give up the simplicity of PHP.

sergiosgc 6y ago

Funny. I completely disagree, and actually find it odd someone actually wants desktop style application state on web apps. One of the beauties of the PHP style of app execution is that application state is a lot simpler. Instead of having a running application server-side, which can be in a continuum of states, PHP forces you to start every request with a blank slate. Application state must be explicit (with serialized server-side sessions or browser-stored cookies). This makes it trivial to reproduce requests, trivial to debug, trivial to scale horizontally. To each his own, I guess. I just find your position genuinely surprising.

zapt02 6y ago
By starting every request from a clean slate, you have much less mental overhead (did I accidentally reuse a variable from a previous request?) and it eliminates an entire class of programming bugs. It's the best thing about PHP, and despite this approach PHP still runs faster than many similar languages.
- mjw_byrne 6y ago
  I think the "clean slate" benefit is achievable almost for free in a monolith though - each request is a separate invocation of a handler function which is given the context it needs to run (e.g. an HTTP request, an output stream and user-defined context). The user-defined context is the only route into the application state and can be as wide or narrow as you need. So you can share persistent state deliberately, e.g. by having that context contain a pointer to a db conn, but this is always a conscious, opt-in choice, and errors like accidental reuse should be impossible unless you're doing something inadvisable like using global variables.
  - fetbaffe 6y ago
    After doing Java Spring I realized that the Java monolith was very leaky and inflexible. That is why you have strong trend of micro services. In 99.9% of cases in web development you want the PHP model of doing things. The 0.1% case is the asynchronous background job, that can be solved, maybe not as elegant as in other languages, but why optimize the edge case?
    - jjeaff 6y ago
      My backend is written in php and I simply have a separate container running a copy of the same php codebase that has a long running process pulling from a pubsub queue in a loop. So anything that needs to be processed asynchronously, like say, sending out a few dozen emails or notifications, I just publish the task to the queue and that other container handles them. This could be simplified even further if you use a pubsub service that can post data to a url as it comes in. Thus allowing the single php container to asynchronously process the tasks all in their own individual threads. This didn't work for me as Google cloud's pubsub seems to absolutely flood it's target with requests seemingly ignoring 503 or any other error code and not backing off until it has dos'ed your server.

fetbaffe 6y ago

Personally I think that separating the application from the web server is good thing, but I do agree that this is the part that can give you the most trouble. Running a PHP project isn’t as easy as git clone make run because of the web server. Difficult to configure, hard to share configurations between machines, differences between operating systems (and Linux distributions) where to put configurations, different ways to hook into php. Projects starting to rely on specific web server configurations for different application behavior, e.g. htaccess files. Hard to debug when you need to special request handling like terminating the request but continue executing or continuously stream data (web server response cache). I guess that is the price you pay for separating the application from the web server.

clon 6y ago

Absolutely, having a service that just listens on port 80 is so much simpler to reason about. I would also add a much easier development setup, as well as deployment to your list of advantages. That said, having a Go service just be exposed to the wild wild internet may not be a smart idea. Take a look at this issue [1], it is perfectly clear that Go services (relying on net/http) still need babysitting by a competent reverse proxy. It is a case where Go's mantra about simplicity leads to leaky abstractions and just clearly immature solutions. Also not talking about TLS certs, WAF and other concerns that also may bring nginx etc on board anyhow. [1] https://github.com/golang/go/issues/16100 https://github.com/golang/go/issues/16100

eggsnbacon1 6y ago
Lol I remember seeing this timeout issue years ago and immediately deciding I would never use Go for HTTP (which is what it was designed for). This makes Go vulnerable to numerous slow attacks and there's no way around it besides "use a proxy". My guess as to why this issue is left open? Google has global timeouts set on all the network edges so they don't want each service to use its own. Whats good for Google overrides whats good for the supposedly open source project. This is pervasive in most of their projects. Google open source is like the Reapers from Mass Effect series. They leave some crumbs behind to ensure the software ecosystem develops along desired paths. Not out of charity, they do it to ensure a successful harvest.
- clon 6y ago
  This timeout issue is indeed baffling. I believe many Go services out there may have set their timeouts to something ridiculous like 3600 or 86400 as a "fix". Hello slow lori. Another concern is that the lifetime of a PHP app is rather short, measured in milliseconds. This is actually a rather robust approach. Crashes, memory leaks, all sort of weird states are brushed away immediately to be replaced with fresh state for the next request. Apache/nginx is acting as a supervisor and allowing a lot of shit code live out it's days unnoticed. Contrast that with long-running Golang processes. You won't get away with sloppy code there, raising he bar considerably. Running a Go executable without a monitoring supervisor is sketchy at best.

golergka 6y ago

> web app I think that this vague definition, right here, is the source of disagreement. Are we talking about small blog with comments? Or are we talking about one of the services of a medium-sized company, that needs to provide a platform-agnostic API, and real-time updates to subscribed clients with websockets?

mjw_byrne 6y ago
Yeah, in my case I'm talking about a thing that is largely a web app but also does other things which don't fit well into the one-script-execution-per-request model. That being said, I would still prefer a monolithic application for a small blog with comments because I think it's easier to manage, deploy, encapsulate, test etc.

AegirLeet 6y ago

The old-school style you describe is indeed old-school and was abandoned by most PHP developers ~10 years ago. Modern PHP projects will have a single entry point that handles all requests, with path-based routing done in code.

jrururufuf666 6y ago
in cheap shared hosting apache setups its still the best way to do 7t oldschool. still love it

dingdingdang 6y ago

I know this replicates the sentiment expressed by other in this thread but still: Go does not do away with the need for front end servers for deployed end products. And so the eventual proxying Go behind Nginx or Apache comes with it's own cost since Go is nowhere near as tested as PHP when it comes to server integration.

stephenr 6y ago

Shared nothing is a huge benefit in simplicity. “Does this thing persist across requests” is ridiculously simple to answer in php because the answer is “no, unless you very explicitly told it to”. In a go or java or whatever service you have to know if your “thing” is specific to the request handler, or if it’s part of shared state. There is no reason that routing in a php app has to be done via mapping urls to php files, it’s a very common practice to have a front controller that bootstraps the app environment and in turn handles routing of the request to a piece of logic.