The main idea about the generics is type safety so you won’t be getting runtime errors that might happen in case of not using them. Performance wise they have not improved and my testing will show that there is no difference. I will do the tests on golang 1.20 in two cases, once I will use type to interface and second scenario will be the same functionality using generics.
In this post I would like to outline some of my experience as a technical interviewer with candidates and what I like to ask most of the cases. This won’t be me answering some interview questions that you can find with simple Google search, even though I don’t know why most candidates won’t look for them before showing up in an technical interview. I will try to answer my own concepts though.
The task is to sync data both to application’s database and ElasticSearch Cache. Both clients sets value to database first then to ES.
Let’s get right to it. Each of these services needs to be self manageable and not depended on the other services, meaning you could deploy it on its own, expand on it own ect. If I were to make a change in one API and that results in changes in all the rest APIs and the deployment procedure involves all of the APIs to get a new version than we are not really building services we are building APIs that are connected and very much depended on each other. It can work, but it will be hard to manage both team wise and development requirements wise. When this concept was introduced the idea was that a developer is able to solve a problem: divide and conquer. We would break things into smaller pieces so we can solve them better and reuse each of those small piece anywhere so we make a change in one would be auto-reflected anywhere. That’s like basic narrative and we all know that, but making things simple is very hard.