31–40 of 51 posts
Oh yeah, REST APIs are one of Go’s sweet spots. I have yet to find a better language for APIs and CLIs
I have been using Java for a long time but will soon be using Go because of a job change and I am trying to get a better sense of the trade-offs and advantages.
Yes, 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).
What were you using before Go? I notice in the relies that a lot of people are coming from Python. Did you consider using Java? And if so what made you use Go in the end?
- I didn't love the Java tooling at the time. Maven for example. - I don't love OOP. Go has just enough OOP patterns for me.
I tried Go as an experiment, but didn't know it would become my go-to language. What I found was super fast build times (big win), built in testing, and a simple language that almost anyone can understand (versus the relative sophistication of something like Scala).
I went from Python to Go to Rust. Go plays up this fantasy of types helping you catch bugs, buts it’s really C with lipstick. There’s no enums, no exhaustive matching of any kinds, there’s null to worry about everywhere, and every utility function has to be painfully written out for each type (maybe that’s starting to change now with Go having basic support for generics).
First 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…
After reading the article you linked in another sibling comment's response, can you point to an example of what a true RESTful service looks like. I see how under that definition an API can't be RESTful, but what service then can be? And how do clients interact with it?
First 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 I ask about the choice to not use any libraries? As in your go.mod file is empty? I understand the desire to keep dependencies to a minimum but surely there are use cases where it is better to import existing code rather than writing something from scratch no? Do you use internal libraries?
This also removes any problems with third party dependencies that suddenly gets abandoned yet still have serious issues, supply chain attack problems, etc.
We have also found that most third party libraries tries to be (more or less) general purpose, so they often contain lots of stuff we would never need, so we prefer to e.g. write our own specific code.
The way we work require a little extra effort because we write the things we need our selves, but of course we reuse our HTTP handler code, our custom runtime error handler code, etc., from project to project, but in general the benefits far outweigh the cost in our experience. The fewer dependencies, the fewer problems - and Go shines in this because of how much is covered in the standard library.
Earlier quoted context omitted.
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?
This is one of my favorite posts about it. https://www.unixsheikh.com/articles/no-your-api-isnt-rest.ht... The author got Roy T. Fielding, one of the principle authors of the HTTP specification and the originator of the Representational State Transfer (REST), to comment on this issue by email (was since removed when the author changed his blog).
Earlier quoted context omitted.
Can I ask about the choice to not use any libraries? As in your go.mod file is empty? I understand the desire to keep dependencies to a minimum but surely there are use cases where it is better to import existing code rather than writing something from scratch no? Do you use internal libraries?
We basically only use the Go standard library. So far we have found no use cases where that didn't cover us well enough. This also removes any problems with third party dependencies that suddenly gets abandoned yet still have serious issues, supply chain attack problems, etc. We have also found that most third party libraries tries to be (more or less) general purpose, so they often contain lots of stuff we would nev…
Yes, 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).
1. How do you handle DB interactions? A data mapper/repository pattern?
2. Do you have a service layer to coordinate between the different "inputs" (the REST API, event processing, and scheduled jobs)
3. Is this REST API used by a web front end or other services? Interested in how people handle token auth and/or using session tokens.
I've been reading about architecture patterns more and I've realized which patterns I've used without knowing it, so now I'm interested in how others handle similar situations in different languages and ecosystems.
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.
Which generators do you use to transform the OpenAPI spec?
Yes, 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).