Yes, go is still my go to technology for API work. I usually go about it like this: write an OpenAPI spec, generate clients and servers, implement individual operations. I like how lightweight a go implementation is and how easy, no-bs it is to setup a new module. I like go for apis.
Ask HN: Anyone here switch to Go for building (REST) APIs?
11–20 of 51 posts
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#12For those that build REST APIs in Go, do you use an OpenAPI generator to scaffold most of it?
Yes.
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#13Oh yeah, REST APIs are one of Go’s sweet spots. I have yet to find a better language for APIs and CLIs
[deleted]
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#14Yes! trying to use it for new things.
Because of the stable nature of the base language and library, and the way libraries are imported, with multiple pinned versions allowed and without import loops, it gives better longevity to "set and forget" type back-end services.
I rarely have a problem when coming back to work on an old project, it still compiles and even updating dependencies is usually fine.
This helps with the problem of back-end services becoming "forgotten children" that don't receive attention for extended periods.
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#15Golang is my default for REST API’s. I may swap that to elixir for certain use cases.
That said, being able to use pprof to debug and the single binary deployment makes life really easy.
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#16My team and I have built many dozen services using Go and Fiber (fiber.io) and have been insanely pleased with the experience and the performance of the code. We have quickly onboarded new devs and got them productive very quickly thanks to the relative simplicity of the language, amazing documentation and strong start of tools. We are writing most of our components, APIs and tools in Go. Go for it!
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#17When some of the teams I've worked with switched from PHP / Laravel to go the most common complaint was that their code must be broken because it was just too fast.
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#18My team and I have built many dozen services using Go and Fiber (fiber.io) and have been insanely pleased with the experience and the performance of the code. We have quickly onboarded new devs and got them productive very quickly thanks to the relative simplicity of the language, amazing documentation and strong start of tools. We are writing most of our components, APIs and tools in Go. Go for it!
> fiber.io
Should be gofiber.io
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#19First of, just like the term "hacker" became popularized by the media and turned into the meaning of someone who cracks computers and software, so has HTTP based APIs been popularized and turned into REST applications, but this is wrong. A HTTP based API cannot, by its very nature, ever be REST. Now that's out of the way, yes. We use Go for both API and web development, actually full stack WITHOUT any JavaScript. We…
Can you elaborate on why HTTP APIs cannot be REST APIs? I know a lot of http services are misclassified as REST, but why can they by definition not be?
Re: Ask HN: Anyone here switch to Go for building (REST) APIs?
#20Yes, in 2017 and 3 companies later I've never looked back. Current application is an event-sourced system that includes a REST API, asynchronous event processing over SSE, and a scheduled job runner.
It's been great. We don't use any frameworks, just the http package. It's blazing fast and highly reliable (low bug occurrence and easy refactors due to the safety provided by strong typing).