Go: Embedded backend vs app engine

I'm one of those classic native programmers that has spent most of his past with .exe's and .jar's. As of the past year I've thrown my self into the world of web frameworks and technologies that seize to impress me. As of the past 1½ month I have fallen In love with Go because of it's strictness, and also how 'stand-alone' it seems to be. So now to the real question...

• Go app engine application, why do we need this?

• What is the difference and reasoning to choose a wrapped application (framework)?

I assume its purpose is to load some of the communication off the application to the wrapper, but sadly I can't seem to figure out (through documentation and discussion) what the specific purpose behind this modulation is.

Best regards and cyber high fives in your direction!

These really are two different questions.

1. Why GAE?

It's up to you. GAE provides cloud-based hosting that you pay rental to use. It's a bit similar to Amazon Web Services. Your Go app would be uploaded to GAE, where it provides your web service and your users can do lots of wonderful things. Meanwhile you never need to know which actual server is doing the serving at any given time - the app can migrate across their servers dynamically. GAE provides a high uptime and a low effort for you in keeping the server secure, backed up etc. It will also be elastic to cope with surges in load.

You may instead prefer to rent a private server (e.g. at Rackspace) or just a virtual machine. You'd perferably need to be a Linux expert (get lots of help at Serverfault) and you'll have to do the backup, firewall etc all yourself. It may cost (much) less. Or more.

2. Choosing a framework?

The net/http API allows you to write HTTP server code to do pretty well anything you want. But you have to do quite a lot of hard work. At the opposite extreme, frameworks like Revel make rapid server development possible, as long as it does the things you want of it. If you stray into functionality beyond what it offers, you might have to do quite a lot of digging to find out how to extend the framework.

Other interesting toolkits include Gorilla, Gocraft Web and Goji. In terms of complexity, these sit about halfway between Revel and basic net/http.

To answer your second question, here are some pros and cons of using a framework (e.g., revel) vs. something simpler like a toolkit (e.g., gorilla)

In general, the pros of using a framework are:

• it provides a lot of sub-packages to handle important web-related sub-tasks like templating, generating data in specified formats like json or xml, query escaping, etc.
• it handles boilerplate http handling
• it (hopefully) enforces best practices like escaping strings
• it helps you manage complexity by enforcing a consistent design pattern in the way you handle requests

Cons of using a framework:

• frameworks tend to be "opinionated," meaning you have to buy into their general philosophy and understand their core concepts before you can make use of them; for a lot of frameworks this can be quite a bit of mental overhead
• extra layer of abstraction, meaning you're another step removed from what's really going on, and there will be more stuff to understand and debug if something goes wrong
• it can be brittle and hard to do something that isn't a standard use case in the framework
• future maintainability: most frameworks don't tend to have a super long lifespan. Django and Rails have been around for a long time, but there's a massive graveyard of frameworks that came before them. Hindsight is 20/20, but it's hard to pick the right horse from the outset.

Recommendation

It's hard to make the call upfront. So much depends on the specifics of your problem, but I'd say in the case of Go, opt for the simpler option. Much of the value-add of frameworks in other languages is the fact that they contain useful sub-packages that handle important tasks, but Go already contains a lot of these in its standard library (e.g., encoding/json, net/http, net/url, text/template). I've built a fairly sophisticated web app using just the Gorilla toolkit and the go standard library, and it's been amazingly good, and the best part is, it's incredibly easy to understand what the code does and I can explain it to someone else without requiring them to first read through the massive About page of some third party framework.

If you want to get a sense of how other people use Gorilla, you might try looking at real-world usage examples. Compare that to how people use more sophisticated frameworks and pick whichever you like better.