regalius / clean-arch Goto Github PK

because this will be example, I would like to have good example of aligned struct.

good reading :
https://dave.cheney.net/2015/10/09/padding-is-hard
https://medium.com/@felipedutratine/how-to-organize-the-go-struct-in-order-to-save-memory-c78afcf59ec2

we can add paging functionality example.

Standardize all the repo to use one paging format, example :

GetAll(ctx context.Context, pageNum int, pageSize int)
GetByFilter(ctx context.Context, filter Filter, pageNum int, pageSize int)

Bring this behavior through usecase until repository.

We can even bring this to delivery, will be different discussion but we can have 1 function for paging across functionality.

// ReadPagingInfo get paging info from request
func ReadPagingInfo(r *http.Request) (pageNumber int, pageSize int, err error) {
	page := r.FormValue("page")
	size := r.FormValue("size")

	pageNumber, err = strconv.Atoi(page)
	if err != nil {
		return 0, 0, fmt.Errorf("ReadPagingInfo failed parsing pageNumber : " + err.Error())
	}
	pageSize, err = strconv.Atoi(size)
	if err != nil {
		return 0, 0, fmt.Errorf("ReadPagingInfo failed : pageSize " + err.Error())
	}
	return
}

Let's create simple and short for variables and struct name, IMHO
Becase this struct/variable in product-recom package, when we use it we should already know what's the context (product-recom).

Maybe Options is enough

	DefaultOptions = Options{
		Limit: 5,
	}

Later when some package need this

import productRecom ../../../product-recom

productRecom.DefaultOptions

In my opinion we must as best as possible not using makefile.
https://hackernoon.com/why-not-make-db142ccb2081

But if we want to use it, better to make it as simple as possible, don't use make for any fancy stuff - it will hurt (https://github.com/wejick/mattermost-server/blob/master/Makefile).

good reading : https://sahilm.com/makefiles-for-golang/
or check what content team is doing with makefile, which concise enough

Because this will be used as example, I expect the comment style use common godoc commenting style.

No need :
https://blog.golang.org/godoc-documenting-go-code

and for my personal taste, no need to sectionize code with comment

// start model
...
// end model

Better struct naming is enough

I think product link uri generation should be on usecase. It needs several logic not related on how we store product, like web, mobile, applink generation.

In general I would say non crud operation should not be here, we should have it on usecase or repository level (I prefer on usecase level tho).

because this will be example I would suggest having clear but still concise variable naming :
lt = lessThan, gt = greaterThan?
I'm not sure what that means actually