Building an API with Go at Microco.sm(speakerdeck.com)
speakerdeck.com
Building an API with Go at Microco.sm
https://speakerdeck.com/mattcottingham/building-an-api-with-go-at-microco-dot-sm
7 comments
Thanks for pointing that out. The static routes in the talk are just for illustration -- we use nginx to serve them in production.
One thing I haven't touched on at all is html template rendering, something I'd like to take a look at in detail at some point.
Would like to hear more about your experience with Go -- is there a writeup somewhere?
One thing I haven't touched on at all is html template rendering, something I'd like to take a look at in detail at some point.
Would like to hear more about your experience with Go -- is there a writeup somewhere?
Despite the overall ecosystem being rather small, the standard library and adjoining experimental packages are excellent. I wouldn't be surprised if go 1.2's stdlib would cover most of what Python's stdlib and Twisted can do.
> My experience has been pretty similar: Go is perfect for building high performance APIs.
Like any native compiled language, it is just a matter of having the right set of libraries available.
Like any native compiled language, it is just a matter of having the right set of libraries available.
Maybe I missed it - but it would be really cool to see a large fragment of working code for some of the apis.
None of the links work in the embedded version, but if you download the PDF they're fine.
18k lines? Does that seem high to anyone else? Or am I missing something important?
High compared to what?
It's just the output of
It's just the output of
wc -l `find microcosm/ -name *.go`
Compared to the amount of work that needs to be done for this project to function.
In that case, I don't know a number that can be used for that comparison. 18k is the total number of lines in the source code files; the SLOC will be different.
In hindsight, I should've left this number out. It was intended to give background to the overall program size, but it's a small detail that shouldn't be the focus of this discussion.
In hindsight, I should've left this number out. It was intended to give background to the overall program size, but it's a small detail that shouldn't be the focus of this discussion.
Well, Go has been touted for lower lines of code.
It is high. Probably includes code site,docs etc.
Please call them web services or REST API, just API is confusing.
One suggestion: Don't bog down your application server with serving static files (Slide 7. favicon and robots.txt). I put all of my css, js and image files in a /static sub-directory and configured nginx to serve any URL starting with /static without hitting my go-server.