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).
- 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).
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.
Now that's out of the way, yes. We use Go for both API and web development, actually full stack WITHOUT any JavaScript. We have written a custom error handler that deals with runtime HTML template errors, if any, which improves the otherwise tedious work when a template makes the web service crash.
Go is superb at HTTP and all web related. We still have some PHP development, but would very much like to do Go all the way, we just haven't gotten there yet.
Last, but not least, we do not use any frameworks or libraries, only the Go standard library and we love it. No matter were we put it, it just always works and is very performant.
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).
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?
Not OP, but there was an interesting article & discussion recently here: https://news.ycombinator.com/item?id=32141027
An example response could be
{
name: 'john',
nickName: 'johnny',
relatedEndpoints: ['/v2/friends', '/v2/jobs/', ...]
}
{
name: 'john',
nickName: 'johnny',
apiSpec: '/v2/open-api-spec'
}If your application needs documentation, i.e. a spec or similar, also referred to by some as a "profile", in order for the client to use your resources beyond the initial root URI, then that is not REST!
An API, no matter how you twist or turn it, can never be REST. REST are truly only for manual human consumption, not machines. That is why it is so weird everyone is calling their APIs for REST.
If an API response included all the possible actions and information that one takes as a follow up to a previous call, how is that any different from providing the equivalent forms and links to additional information on a web page rendered by a browser?
It certainly seems possible to pigeonhole an API into a RESTful architecture but I understand why based on the article, APIs aren't often considered RESTful.
But it seems they can be. I see this as a proof by contradiction.
I, today, can navigate directly to posts by a friend of mine on a social media site. Auto logged in, not having to enter any form data etc. That's my starting point both in a browser and via API.
I'd see their post. Alongside that post I'd see actions I can take: clicking on other friends' profiles, liking the post, commenting on the post, removing the friend etc.
Encoding all that in an API might look like this:
{
name: 'john',
userId: '12'
nickName: 'johnny',
posts: [
{ content: 'My funny comment', likes: 3, likedByUserIds: ['13', '14', '15' ], postId: 333 },
{ ... }
]
relatedEndpoints: [
'/users/12/friends/', : {}
'/users/13', : {}
'/users/14', : {}
'/users/15', : {}
'/like/333, : {}
'/unlike/333', : {}
'/remove-friend/12', : {}
'/comment/333/' : { commentText: '' }
...
]
}
* No consulting of external documentation is needed, all the information is right there. *
I can explore another user's profile (people with user ids of 13, 14, and 15), I can like and unlike this post with the `/like/` and `/unlike` routes, I can remove this person from my friends list etc.
Including such information makes this response no different than what I can do via browsing the page - all my interactions with the API are directly driven by their responses - not by consuming outside documentation.
If all possible actions and their routes were included on route supported by my API, why would this not be RESTful?
At the end of the day - this to me is a distinction without a difference. Whether this documentation is defined as part of the response or stored in an OpenAPI spec, the end result is the same - I can easily wire things up together to accomplish my goals.
This is where SDKs become more useful.
SDKs are fully documented, require no external information for them to be used, contain everything possible that can be done as methods etc.
If I get a `User` class back from an SDK - I can then invoke all the methods on that user like - getFriends, getPostById, etc etc.
If I call a `getFriendById(12)` method I'd expect a `Friend` instance rather than a more generic `User` instance which should have a `removeFriend` method but no `addFriend` method. That appears equally as RESTful as a website with actions that can be taken.
When I do that in the case you provide, I would not know anything about how to use those resources. Without any prior knowledge, I don't know what "users" are, or what a "like" is or an "unlike". In order for me to use this resource, I need documentation. Even if you provide the documentation in the response to the request, and I have to read that first, then it is NOT REST.
By the very nature of an API, it can never be REST.
The idea of REST has evolved beyond the initial definition to include a broader and far more impactful meaning. The abstraction of UI over data. The important piece is the data.
I could make an entire website, entry point and all that only returned json and included the links for actions users could take and other pages they could visit. Whether I use a browser to see that or my terminal with a cURL makes no difference.
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.
However, if you ask people that switched away from Go, then you will see responses that also match that expectation.
So it really is down to your preference.
Today, I would go with Rust instead because of personal preferences. But if my code base has to be shared with not very experienced developers, perhaps Golang again.
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.
That said, being able to use pprof to debug and the single binary deployment makes life really easy.
Should be gofiber.io
Which generators do you use to transform the OpenAPI spec?
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.