Thoughts on Example for Splitting Out "Business Logic Layer"?

[sksmith]

Hey! First off I want to say I've recently begun migrating a project I'm working on to this project and have to say I'm loving it so far. The structure is quite clean and easy to understand, and adding new pages has been a snap!

I'm at the point now where I'm getting ready to implement some interesting business logic. In my own experience I like having that stuff stowed away in a clean package on its own - similar to the service layer in a traditional three tier architecture, or the application core in hexigonal architecture. I like this approach because it's nice having technology concerns like databases, frontends, and other integrations completely isolated away from the problem you're really trying to solve.

As the application stands now, the controllers (routers, pages) talk directly to the database using the controller struct's services container. My thinking is to perhaps remove the ORM, and Database dependencies from the services.Container struct and add new services there representing those that contain business logic. Those services in turn would have access to the ORM.

I think that for many applications additional layering like this would be overkill. If you aren't doing more than simple CRUD interactions with a database, no need for a layer that doesn't actually hold any logic. But I'm curious if you have any thoughts on this is where you would make the "cut" or if you'd have another approach.

Thanks again for putting this together, it's massively appreciated. Not only did you expose me to some great new stuff in the Go world (man... Ent is crazy cool... I'm not normally a fan of ORMs but so far I'm digging this) but it's also really nice having some grounding to work from. Well done!

P.S. My previous project was using templ for templating - while it's a neat library I'm not totally sold on it yet. I re-read the go template docs while preparing to migrate to this and haven't yet really missed templ.

[mikestefanello]

Thank you for the really great feedback - I appreciate it and am always glad to hear this has been useful for others. It was a lot of fun to put together and also exposed me to a ton of really excellent Go projects (ent still blows me away with how well it was done, also coming from someone who doesn't love ORMs); as well as non-Go projects (ie, HTMX, Alpine, Bulma, etc).

You're very welcome. This started because I didn't have a good answer to what I would use if I wanted to spin up a quick full-stack Go app with everything I needed to hit the ground running (without using some mega Go framework or heavy, separate JS frontend).

I'm personally a huge fan of hexigonal architecture. What you're describing is exactly what I would do if I were building out an app for myself. I didn't want to go down that path for this project because it's meant to be purely a starter kit at it's simplest form without making any bigger architectural decisions that could be difficult to unravel if that's not your preference. I didn't even include interfaces for all/most of the services on the container because I assume most people will be changing not only what's in the container, but how they function. It would end up being a waste of time on my part and probably somewhat more difficult for users to refactor to their liking. That's the great thing about this being a template rather than a framework - you're not locked in to anything at all. Actually, the AuthClient is sort of an example of what you're describing, though better practice would be if the ORM was more easily mockable for better/easier testing.

I wouldn't worry about looking for a proper "cut" between one way or another. I think what you described is better and will always suit you better in the long run. It also doesn't take much time at all to set things up that way. And it comes down to preference; go with what you like.

I'm also intrigued by templ and think it's a very promising project but I thought it was too early to consider bringing it in here. It's also a pretty big deviation from the standard library, and last I checked, IDE support was still lacking. Standard templates do leave quite a bit to be desired, but I think what I put together for this project makes them pretty easy to use.

If you have any more questions or want to share some code examples, etc, please feel free to re-open this or open a new issue. As you continue using this project more, definitely let me know what you think and if you have any feedback or suggestions. If you have some time, you can also let me know what you think about this refactor: #59 (I like the overall change but I think using init() to register handlers is a bit too fancy and will probably be removed).

Thanks again!

[sksmith]

I did a similar thing, though yours is much, MUCH more mature than mine hahah. Glad to hear I had the vibe of the architecture down - that's a good sign!

I think templ could be good, what I started to get frustrated with was wanting just a little more power in my view layer. It could be that I'm so accustomed to the modern JS frameworks that I'm trying to do too much at the layer. But I ended up with quite a few public functions in my template files that would do a bit more prep to then call a private templ function. That was the pattern that I ended up settling on feeling the best and I wasn't happy with that. In the end it just didn't feel as obvious a win as say HTMX does.

I'm looking at your PR now - just struggling a bit because I lack some context but I'll try to give some useful feedback!