Farzin Nasiri
Farzin Nasiri

Reputation: 730

creating top level package on gorm orm for micro services in golang

We are a startup tech company. we use Golang as are primary language for our micro services and gorm orm as our interface to connect to our PostgreSQL database.

Currently we have multiple micro services with multiple developers working on them. The problem however is that since there are many ways to do one thing in gorm, everybody did their own way of writing queries on the database. So some people used the .Table() function to do queries and some other just passed the .Model() to figure out the table itself.

So now the code is not standard and we want to have a standard way to do queries on our databases. We figured that if we could have a package like a library which provides a orm's interfaces to us to use (so that if we wanted to change the orm or don't use any we didn't have to change all the codes) in a standard manner, it solves the problem.

But We've never created such a thing, we basically have little idea how to approach the problem and if any library exists that has done such a thing or not? also we are struggling to standard way to do queries in Golang so if you could share your ides on how to develop such a system that can even have the potential to be announced public, we would thankful.

Upvotes: 0

Views: 269

Answers (2)

ifnotak
ifnotak

Reputation: 4662

We had exactly the same problem, we are using gorm for different applications and with different databases (PostgreSQL, MySQL and SQLite).

We naively decided to abstract gorm using what we called a Storage interface, this interface has more or less the basic operations that you require from any orm. It looked like this:

type Storage interface {
    Create(object interface{}) error
    Retrieve(object interface{}, queries ...Query) error
    Update(object interface{}) error
    Delete(object interface{}) error
}

At the beginning of the development, it served us very well and we could even implement this interface using a normal file and it would just work.

BUT

After a couple of months, we started to notice its limitations. There are operations that can be done in gorm that we can't do using our interface. So, obviously, we decided to extend the interface to have more functionality. Again, this bought us another couple of months until we realized: the only way to have all the functionality of gorm is to provide an interface for everything gorm provides which is not exactly why we started writing this package.

Since this interface is used everywhere, we decided as an interim solution to extend the interface and add a function that returns the gorm.DB object so that we can directly use it again.

Moral of the story, I would strongly advice against building such an interface. Use the time to help with the development of gorm's v2 which should be coming out soon according to this post.

Upvotes: 2

Dmitry Verhoturov
Dmitry Verhoturov

Reputation: 6082

I think that wrapping such a complex thing as gorm is a complex task and if you are not clear on how to approach it, you should better avoid doing that.

Generally, I would suggest first figuring out what you want to enforce and only then deciding on how do you want to do that, having clear requirements in mind. Grabbing a tool before you know what exactly you want to do is a reliable way to make things worse and not better. Here are steps you can follow:

  1. Start with documenting your code standards and pointing people to them on code reviews in case they don't comply;

  2. Automate check of whatever you can check formally into Continuous Integration pipelines (GitHub Actions, GitLabCI, TravisCI, CircleCI, and things like that);

  3. If and only if things above don't work, look into creating your own wrapper which would enforce particular style usage for developers.

    By the last step, you should have already a pretty decent understanding of what exactly is missing and then it would be much easier to figure out how to fix it.

Upvotes: 2

Related Questions