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

[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!

[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!