There are many “high level” ways to create web applications today so GO’s “low level” way with spawing it’s own server and serving the html directly thru templates seems (to me) as being a bit hackish.
Is this really a good way to do it in real world applications today? Most companies already have a server running and i would guees that creating a application where the server is included is simple not neccessary, but i might be wrong…?
by this, do you mean something like nginx/Apache?
Yes, or some microsoft software.
I am not sure If this could help:
Go vs Java Performance: Link
Why Parse Picked Google’s Go Over Microsoft’s C# To Replace Its Ailing Ruby Stack: Link
Go for Python Hackers: Link
From Node.js To Go, Why One Startup Made The Switch: Link
I think you can still have your web server application in front of your Go web app to handle things like handling of static content (i.e images), caching, reverse proxying and even load balancing.
But yeah, I’d like to see some performance stats between Go’s net/http and other web application interfaces like node.js, 'ruby, flask (python) etc.
Wow that speaks volumes.
I’ve heard Phoenix (Elixir) is also very performant
For me It seems strange if every application would spawn their own server instance inside their own .exe file just to server some html pages.
Of course you could spawn one http.ServeAndListen() and have different functions to handle different URLs, but then you would have to take down the server to add new functionality thru the http.HandleFunc().
My point is that it seems to be better to have one server which directs the requests to the correct application for a given request and that functionality could be added dynamically.
This is not possible in GO as i understand it.
It might be that i’m making to much of a problem of this, and that i have to realize that the server logic is not subject to change so often. In the real world this might not represent a big problem after all. The changes will probably be in the pages that are served and not the logic in the server code itself.
Does this makes sense?
You could use Apache+FastCGI to call go programs that just write template output to stdout. But why you would want to go through such pains to avoid a tiny process on your web server I can’t quite imagine.
I do not want to do more work than i need.
But if i make one process on my web server listen on port 8080, than this port is busy and this process must handle all the requests coming on this port. when you have several web applications running on one physical server this would mean that i can only have one listening process per server on port 8080.
I’m i missing something here?
Go handles connections in a concurrent manner. Multiple connections are enabled in separate processes.
For me It seems strange if every application would spawn their own server instance inside their own .exe file just to server some html pages.
This doesn’t seem odd to me. It’s a 1-liner in Go to do this.
My point is that it seems to be better to have one server which directs the requests to the correct application for a given request and that functionality could be added dynamically.
This is not mutually exclusive with having an HTTP server in the binary. In particular, the application will have to handle the request received from the routing HTTP server, so it will have to run some kind of server anyway–whether or not the router server and the application server communicate via HTTP is an irrelevant implementation detail.
EDIT: The fact that you’re talking about serving HTML pages leads me to believe you might mean to ask, “Why should you bundle the UI server and the backend application server in the same binary?”. If that’s your real question, my answer is “it hardly matters”, but bundling the UI server and the backend app server can be slightly more performant if the two need to talk to each other (shared memory vs IPC) and a bundled solution would make deployment easier. The right solution will depend on your system’s architecture.
Not to mention this would be much less efficient…
Why are you so extra attentive about the port in use?
If your webservice is relying on a database like mysql or postgresql the ports 3306 or 5432 are in use, too. There are so many ports you could use, IMHO this does not matter a lot. I would assume before you are running out of ports your server/service will run out of cpu, memory or io long before.
Forget the port number, i just wanted to be clear.
It seems like these questions are coming from my lack of experience. thanks for clarifying, i did learn something! 
It’s certainly possible. There’s nothing to stop you having nginx on the front end, dividing up requests by URL path and passing them on to any number of separate Go programs. Then you could down, replace and restart one of those Go programs without the rest of the site going down. This is known as reverse proxying.
This is basically what you end up with if you deploy to a Cloud Foundry setup. Your Go program is expected to read the environment to find out what port the reverse proxy will be expecting it to listen on.
You could even implement this kind of architecture all in Go, by writing yourself a reverse proxy in Go.
It may seem unnecessary work to serve your static content using Go, but honestly, it’s fewer lines of code to set up a static content server in Go than it takes lines of configuration to set up Apache or nginx. In addition, if you do your static content serving using Go, you have the ability to do clever stuff that’s difficult with nginx, like serving zopfli-precompressed versions of files to browsers that support gzip, or automatically serving different files based on the user’s browser language settings, or caching specific heavily-trafficked content in RAM.
I think it also depends on what type of application you’re gunning for, and what competition you’re up against.
For me, I don’t want to use a GUI framework and I’m competing against compiled programs- enter Go. I can use HTML, CSS, JS, and it will be faster than PHP7.
One thing I noticed is that the web browser takes between 50ms and 130 ms to load the DOM with a “Hello World” golang application, which is way more than what I thought it would be, but I’m sure that by using Go my program will drop considerably from the current 500ms it takes to load each page, which is unacceptable for me.
this happen because many of them didn’t hear too much about golang 
go is not like php and i guess that is more easy and fun to use net/http and gorilla/mux instead of reverse proxy techniques.
Ok, so to sum up a little bit:
My initial idea that including the http server in the same binary as the rest of the functionality that delivers the html to the web browser/client that makes the requests, as being “to low level”, is somewhat false. In my mind i had the idea that having a server like Apache running and adding pages/app was a better way.
What i have learned is that how the requests are redirected to the correct functionality/program is anyway just a detail in the implementation and the code that delivers the content must anyway run some kind of “server” to handle the requests that is being redirected to it from the HTTP server. In the end, the approach will depend on the solution that is being created and also the enviroment where it will be deployed, i think.
Typically, the kind of solution i’m thinking off looks like this:
webpage where users can get and add information <–> server and functionality <–> database.
i’m preparing for a project like this and i will be using GO or .NET and needed to get some concepts clear beforehand. I think that i did.
Thanks for all the input! 
