Golang Goji: How to serve static content and api at the same time

Question

I have been playing with Golang for the last two weeks and finally could make a real application work. It uses static HTML files served by NGINX and the API is using Goji Web Framework as backend. I don't use any Golang templating because everything is Angular.Js, so static is fine for my needs.

I would like to have the option to chose whether to use NGINX on production or let Go serve the static content at root using the same port the application uses (8000). This way development environments would not require NGINX to be installed.

So, tried adding a handle to the default mux like this

goji.DefaultMux.Handle("/*", serveStatic)

func serveStatic(w http.ResponseWriter, r *http.Request) {
//http.ServeFile(w, r, r.URL.Path[1:])
//http.FileServer(http.Dir("static"))
http.StripPrefix("/static/", http.FileServer(http.Dir("static")))

}

This handle is executed just after all the API paths have been registered (otherwise API would not work).

I already tried any sort of combination and either it redirects me to HTTP 404 or it displays the HTML content as text. Neither is good. I wonder if anyone has been here and could give me a heads up on what am I doing wrong.

Thanks.

Although this has nothing to do with my issue, here is the NGINX configuration I am using:

server {
listen 80;

# enable gzip compression
    gzip on;
    gzip_min_length  1100;
    gzip_buffers  4 32k;
    gzip_types    text/plain application/x-javascript text/xml text/css;
    gzip_vary on;
# end gzip configuration

location / {
    root /home/mleyzaola/go/src/bitbucket.org/mauleyzaola/goerp/static;
    try_files $uri $uri/ /index.html = 404;
}

location /api {
    proxy_pass http://localhost:8000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

}

Answer 1

I had run into similar issues so perhaps the following points would be helpful.

• Remember to register the handler for serving static content as the final route. Otherwise, it might match everything.

• Perhaps try using absolute paths instead of relative ones.

Here's a simplified version of how my routes are set up with Goji.

func apiExampleHandler(context web.C, resp http.ResponseWriter, req *http.Request) {
    fmt.Fprint(resp, "You've hit the API!")
}

func main() {
    goji.Handle("/api", apiExampleHandler)

    // Static file handler should generally be the last handler registered. Otherwise, it'll match every path.
    // Be sure to use an absolute path.
    staticFilesLocation := "Some absolute to the directory with your static content."
    goji.Handle("/*", http.FileServer(http.Dir(staticFilesLocation)))

    goji.Serve()
}

Answer 2

If you have full control over your URLs, a simple strategy is to divide them at the top level. I use /a at the start of all application URLs and /s at the start of all static URLs. This makes the routing very simple.

I was using Goji for a while, then switched to Gocraft-web. But the principles are the same in that the URLs will be unambiguous with either framework. Gocraft-web can obviously do subrouting; I think Goji can also do this but it's less obvious. Subrouting is helpful for several reasons:

• its an easy way to remove ambiguity
• the router might well be faster if its search patterns are simpler
• you can divide your code so it might be easier to understand

If you are serving static assets in production, you may like to measure it and improve its performance. I find that pre-compressing (gzip) my JS and CSS files can help. I have both uncompressed and compressed versions in the same file system and I have a bespoke static asset package that spots the pre-compressed files and serves them to all clients that understand (which is almost all browsers). Also, setting a future expiry date is worth exploring. Both of these ideas are built-into Nginx, and quite easy to code up with a bit of effort.