Same approach but flat structure?

[pegeraw]

Hello! Do You think it’s ok to organize small to medium size project with the same approach as you described but flat structure?
Below simplified example
For example:

userapp

cmd

userapphttp

main.go

userappzmq

main.go

user.go
mongo.go
mongo_user.go
postgres_user.go
postgres.go
mem_user.go
mem.go
http.go
zmq.go

There are http server and zmq server.
User can be stored in mongo, postgres and app memory.
User file in root contains user struct with json, bson, and sql tags. Contains also map type for updates and interface describing behavior with user type.
http contains handlers, functions to help maintain work with http and server struct etc. Same for zmq.
Mongo_user implements functions for user interface.
Mongo contains functions to maintain work with mongo like connection initialization etc.
Same for other storage layers

Is it good idea if there is about 5-10k sloc in project?

What would You do when for example mongo and Postgres needs slightly different fields types, let’s say user Id will be different type for mongo and postgres. Should I put two user types in user.go file and two interfaces? One for Postgres and memory and one for mongo?
Or should I try to make user type more universal to be able to implement users interface in any storage layer?
The other idea is to create custom type for user in mongo file and translate it into user type while returning or accepting user?

I hope I described my problem as clear as possible 😅

[benbjohnson]

Hi @pegeraw, good questions.

Is it good idea if there is about 5-10k sloc in project?

I think a flat package structure is generally fine for small projects (e.g. <10KLOC). The main benefit for splitting out subpackages is isolation and that's not as critical when you don't have much code to isolate from each other.

What would You do when for example mongo and Postgres needs slightly different fields types, let’s say user Id will be different type for mongo and postgres. Should I put two user types in user.go file and two interfaces? One for Postgres and memory and one for mongo?

If your data layers need different different input types then I would create unexported types for each one (e.g. pgUser, mongoUser) have then translate those to a common User type. That way all your other code can rely on a common representation of a user.

There are http server and zmq server.

You can probably even go one step further and move your main package into the root if everything is flat anyway—unless you actually need 2 separate binaries.

[pegeraw]

Big thanks for such a quick answer!
There are plans for more domain types so I'm gonna split this project into layers packages I guess. If I understand correctly these not exported types should be declared within described packages and I can declare function on struct toUser() for example and use it in exported function like this (error handling etc skipped for clarity):

func (u *UserService) FindUser(id string) userapp.User {
    var temp mongoUser
    temp := u.findUser(id)
    user := temp.toUser()
    return user
}

It looks like a good idea for me.

You can probably even go one step further and move your main package into the root if everything is flat anyway—unless you actually need 2 separate binaries.

And there is a tricky thing for me too. I need two binaries because zmq and HTTP will be run on separate machines. What Would You do if HTTP layer and ZMQ layers needs more than one implementations of user service? For example mongo and postgres side by side. Should HTTP layer depends on two user services or it's good moment to declare another interface composing this two services together?

[benbjohnson]

Yes, you'll need a toUser() & fromUser() (or encode/decode) functions to translate between the two types.

And there is a tricky thing for me too. I need two binaries because zmq and HTTP will be run on separate machines.

I think you could still have the same binary and simply add a flag as to whether it runs as http or zmq. That's assuming the setup of the rest of the app is similar.

What Would You do if HTTP layer and ZMQ layers needs more than one implementations of user service?

If you need to use both implementations then I'd try to name them based on why they are different. For example, maybe one is for internal users and the other for external. Then I'd name the fields on the HTTP handler as InternalUserService & ExternalUserService.

You could have a UserService implementation that combines the two as well. Maybe MultiUserService? That could attempt to search one user service first and then fall back on the other if it fails. It depends on how you are using the two services in your application.

[pegeraw]

This is really helpful :) it’s more clear for me now. I think I know how my next steps will look like. Just one more question. Do You think it’s ok to manage multiple domain types in one service? Simple example: Ticket, User, Event under ReservationService. I think It can be useful for simple cases when one type need 2-3 functions. To be consistent there should be declared one interface per type and extra interface which combine the others together and will be implemented later. Or it’s ok to declare just this extra service without declaring the others for simplicity?
There are just a few articles about project structures in Go and a lot of them seems to be wrong and looks like old Java projects. Lot of them declares interfaces in place of implementation instead of usage place.
This wtf project seems really natural and helped me a lot with growing my apps.

[pegeraw]

@benbjohnson I was thinking about my last question and I've made a conclusion that combining interfaces into one bigger interface is more clear than one interface with all functions for multiple domain types even if I will only implement this big interface across app. I'm still curious what's your opinion about this topic.

[benbjohnson]

I would personally separate out the interfaces. I find that really large interfaces can be cumbersome and it's easy enough to combine interfaces together into a larger interface. 👍