8 ms·

If what you need is something minimal, then why not to use a JSON API server and have your front-end app use your API. I compose APIs from Go and NodeJS server

by oakaz 12y ago

If what you need is something minimal, then why not to use a JSON API server and have your front-end app use your API. I compose APIs from Go and NodeJS servers and get really good productivity & performance benefits. And this is what I use; http://github.com/azer/atlas http://github.com/azer/atlas

chc 12y ago
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 12y ago
  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
  - deleted 12y ago
    [deleted]
- espeed 12y ago
  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 https://github.com/defunkt/jquery-pjax).
cheez 12y ago
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 12y ago
  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.
forgotAgain 12y ago
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.
phea 12y ago
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.
- oakaz 12y ago
  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.
- marcus_holmes 12y ago
  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 12y ago
    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/ http://tardisgo.github.io/
- otikik 12y ago

by oakaz 12y ago

chc 12y ago

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 12y ago
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
- deleted 12y ago
  [deleted]
espeed 12y ago
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 https://github.com/defunkt/jquery-pjax).

cheez 12y ago

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 12y ago
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.

forgotAgain 12y ago

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.

phea 12y ago

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.

oakaz 12y ago
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.
marcus_holmes 12y ago
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 12y ago
  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/ http://tardisgo.github.io/
otikik 12y ago