Database-agnostic user model in Golang

Question

I'm trying to design a database model for an API. So far, here's my attempt to do so:

I have a package called models that contains all of the models. Here, User is the database model and UserStorer is an interface that should be implemented by any store (e.g. postgres, mongodb etc.)

package models

//User represents an application user
type User struct {
    ID         int64
    Email      string
    Password   string
    FirstName  string
    MiddleName string
    LastName   string
}

...

//UserStorer represents a user store
//this can be used to store user on different
//data store
type UserStorer interface {
    List(...UserFilter) ([]User, error)
    Get(...UserFilter) (User, error)
    Create(User) error
    Update(User) error
    Delete(...UserFilter) error
}

Then I have a package called store, which contains the implementations of model stores like UserStorer

package store

import (
    "github.com/jmoiron/sqlx"

    "github.com/steven-ferrer/go-db-models/models"
)

//UserStore implements models.UserStorer
type UserStore struct {
    db *sqlx.DB
}

func (cs *UserStore) List(filters ...models.UserFilter) ([]models.User, error) {
    return nil, nil
}

func (cs *UserStore) Get(filters ...models.UserFilter) (models.User, error) {
    return models.User{}, nil
}

func (cs *UserStore) Create(User models.User) error {
    return nil
}

func (cs *UserStore) Update(User models.User) error {
    return nil
}

func (cs *UserStore) Delete(filters ...models.UserFilter) error {
    return nil
}

func NewUserStore(db *sqlx.DB) models.UserStorer {
    return &UserStore{db}
}

The question is, am I doing it right? If not, how do I improve it?

Here is the repo of the example that I used: https://github.com/steven-ferrer/go-db-models

Answer 1

I like your approach:

1. First you've defined an interface on accepting side of application. So you can fix requirements to parts responsible for storage.

2. Realisation is not tied to interface. Today you may use PostgreSQL, later you may add some sharding on application side, or even migrate to another DB. Keeping db-related logic in one place helps you do it in future.

3. Next you can cover it with tests to ensure logics won't get broken in future impovements.