If what you need is something minimal, then why not to use a JSON API server and...

forgotAgain · on May 23, 2014

That's pretty much what I'm doing. The clients so far are javascript making calls that return json. I find it better to handle the UI display on the client rather than using a template package on the server.

It's resulted in a very straight forward go server implementation. The only package I use outside of the base go libraries is beego's session package.

cheez · on May 23, 2014

I think you're talking about single-page apps, if you're talking about the same use case as the original article.

That might be OK for some instances but many times, one needs to be able to serve a browser directly.

Your idea of a API is still a good one, you might just change the level at which you create this "backend" API.

oakaz · on May 23, 2014

You can get your frontend rendered statically before serving if the case is rendering HTML on the front-end. It doesn't have such a disadvantage for multiple page apps.

phea · on May 23, 2014

I'd disagree having a backend written in Go and a front-end written in another language is being minimal. Plus I think the majority of people attracted to Go are fundamentally opposed to Javascript.

marcus_holmes · on May 23, 2014

I don't think there's any other choice. You can only write javascript in the browser (anyone who writes in Go has to be fundamentally opposed to hacks like coffeescript).

I write Go on the server to serve pages, and write rich front ends using simple javascript and jQuery. Being able to do nice quick page fetches means I don't get into massive complexity on the front end with a bloated single-page app, and not trying to deal with front-end complexity on the server means my server routes stay nice and simple.

I use Gocraft/web on the server because it's a useful library not an opinionated framework, and IMHO the most Go-idiomatic of the options (I tried them all and it was a toss-up between Gorilla and Gocraft/web, which won because of the really simple, useful context and middleware paradigm).

Creating API endpoints and page routes is simple and easy, and then writing the javascript to call endpoints when needed is simple (once I'd learned to stop jQuery from appending my data to the url and put it in the request body!).

My only gripe about the mix is that GoConvey doesn't integrate with Jasmine so I have to run two test suites.

icebraining · on May 23, 2014

anyone who writes in Go has to be fundamentally opposed to hacks like coffeescript

Why? In fact, there's someone writing a Golang → Haxe transpiler, which is no less of a hack than CoffeeScript: http://tardisgo.github.io/

otikik · on May 23, 2014

> Plus I think the majority of people attracted to Go are fundamentally opposed to Javascript.

I think the majority of people attracted to go are fundamentally opposed to broad statements such as that one.

oakaz · on May 23, 2014

I assume that companies like Stripe have people writing JavaScript and people who write JS will be willing to use their own productive environment.

So if you're a single guy writing everything by yourself, yeah you can also use your own programming language for both backend and frontend.

chc · on May 22, 2014

Can you explain a little more? This sounds like a three-tier architecture, but that isn't something I'd normally describe as "minimal."

oakaz · on May 22, 2014

sorry for the confusion, I meant just having JSON API server is more minimal and let's you focus on what you actually do; programming your backend...

web frameworks do two things and they're terrible on both. they invent a lot of stuff that you'll likely try to get rid of a later time and it's gonna be too late since your codebase (both frontend and backend) is locked.

but API servers are not like that. they lead you the right (and the more productive) way; composing small libraries into something ideal for you. I'm not sure if it makes sense for people who tend to use frameworks but this works for me great. may be it's my taste

espeed · on May 23, 2014

Separating the JSON API from the presentation layer is a clean separation of concerns. Structuring your app this way makes it easy to expand to additional devices when you're ready -- the API can be consumed by multiple front-ends, e.g. your Web, Android, and iOS apps -- and it makes it easy to provide a public facing API that others can use.

For example, a Java-based website designed this way would have two servlets -- one serving the JSON API and one templating servlet that consumes the JSON API and generates the page.

Another approach would be to forgo the templating servlet (or Rails/Django templating layer) and do all the rendering in a JavaScript client-side app that consumes the JSON API, but this can have SEO implications that may mean you also need to generate static pages for bot consumption (pjax can be useful here https://github.com/defunkt/jquery-pjax).