tags:

views:

92

answers:

3

Hey Everyone,

I followed the directions on how to create web applications using Go, and I was able to get an application working great.

One thing I am confused about though is, when you run the application (./8.out), the terminal will sit there and listen on port 8080 until somebody accesses a page.

Does the terminal need to stay up all of the time to run the web application? Does the application act like apache? Does apache need to be run next to this app? Setting this up on a server environment seems very confusing to me right now because I dont understand what the best way to do this is.

Thanks for any help on this,
Metropolis

EDITED
Thanks for the replies. So if the Go app essentially acts like apache, is there a premade Go server app that has the verboseness of apache?

+2  A: 

I think your question is what is a good way to run a Go web application?

Running it in the terminal is fine, as long as you persist your terminal sessions. Programs like screen can do this.

Another way is to leverage your operating system's startup scripts. Most Linux systems, for instance, let you add scripts to /etc/init.d which spawn the web application. This is how apache starts.

The best way, in my opinion, is to use software like monit or daemontools. After some initial configuration, these constantly monitor the web application, and restarts the application if it goes down. This is how most production environments operate.

If you want to run multiple Go web applications on the same server, you could use apache or lighttpd as the gateway, and use a protocol like fastcgi or scgi to serve requests.

marketer
Thanks a lot for your help marketer. This is great information.
Metropolis
+3  A: 

Does the terminal need to stay up all of the time to run the web application?

If you run it normally from a terminal, then yes. Better options are to run it in the background by adding a "&" to the end of the command line (okay), start it from init (better), or use a process monitor like supervise (best).

Does the application act like apache?

Essentially, yes. It listens for HTTP requests and responds to them.

Does apache need to be run next to this app?

No, the Go application can handle the requests by itself. Some people run apache or some other server on the front end (listening to port 80) and forward requests to their application (listening on port 8080 or some other port) using mod_proxy.

One advantage to doing that are that you can run several different application servers in their own process. For example, you could use Ruby on Rails for the main site, and handle API requests with a Go program.

Another advantage is that your program doesn't need to be started as root to listen to port 80. You can just run as a normal user without worrying about dropping privileges after you open the connection.

Is there a premade Go server app that has the verboseness of apache?

As far as I know, there are no go servers that would compare to Apache. Go is new enough that it will probably be awhile for something like that.

There are some frameworks that makes it easier to write web applications using the built-in HTTP server though. The only one I'm familiar with is web.go. There's a tutorial on getwebgo.com.

Matthew Crumley
Awesome thanks a lot Matthew
Metropolis
+1  A: 

One thing I am confused about though is, when you run the application (./8.out), the terminal will sit there and listen on port 8080 until somebody accesses a page.

In Linux, every process has a parent. When you run a command in a terminal, such as ./8.out, or find, a new process is spawned that is the child of the shells process. When it is run without the ampersand at the end of the line (./8.out &), the shell waits for the process to complete before it lets you input further text. If it is run with the ampersand, it lets you continue to work with the shell while the process runs in the background. However, when you close the shell, you will notice that the server process also shuts down. This is because when you terminate a parent, all of its children are also terminated.

Does the terminal need to stay up all of the time to run the web application?

If you want the process to run without a terminal, and you probably don't want this, but if you really did:

jobs
disown %jobid

The first command gives you a list of the child processes of the shell, the second command changes the parent process of %jobid to init. Init is the process that is the parent of all processes.

Does the application act like apache?

Both apache and this application listen to a port provided by the operating system, but beyond that they are dissimilar.

Does apache need to be run next to this app?

No, this application works entirely separate from Apache. Apache is in no way magical (?), on a basic level it is just listening on a port, just like this app does.

Setting this up on a server environment seems very confusing to me right now because I dont understand what the best way to do this is.

It should seem confusing. Writing web servers/services is very hard, and this is by no means an example that is meant to be deployed beyond localhost.

Thanks for the replies. So if the Go app essentially acts like apache, is there a premade ?Go server app that has the verboseness of apache?

There are no production quality servers written in Go that I am aware of, at this point, Go is a very new language.

Seamus
Thanks for the extra info Seamus. I am glad to hear that this is supposed to be "very hard", because sometimes I wonder if I am the only programmer who cant figure these things out lol.
Metropolis
@MetropolisTrust Me, you aren't the only one. There are books written about the subject for a reason.
Seamus
Shouldn't things be getting easier instead of harder? lol.....It seems like everything is just getting more and more complicated, and all anyone does is throw a tool at it and hope it gets fixed....
Metropolis
@MetropolisIt gets easier and harder. Easier in that you learn how to compartmentalize your code, and how to interact with others code. It gets harder because you begin to fully appreciate the complexity of even the most simple "Hello World" program.
Seamus