mstef9

Definitely worse. Django has been developed for 18 years and has over 2,500 contributors. I'm not even sure if I'm at triple-digit hours yet. It's also a framework whereas this isn't, so you can't completely compare them. The basis of this project was to avoid mega-frameworks in favor of stitching together libraries and remaining very flexible.

What do you use if you want to build a full-stack web app in Go?

Do you have any repos with somewhat complex UIs using templ that I could check out?

Thanks. Has templ been working well for you?

Awesome work with this and Ent. I've been keeping an eye on Atlas. I've only used it through Ent so far, and it's incredibly impressive. I'm beginning to evaluate it to handle our PG migrations which we're currently doing somewhat manually with not much success.

It's not, but I've been thinking about it. I may experiment with it in a different branch of a different repo. I'm not sure if everyone would want hooks included or baked in to Pagoda, but I do think it would be a very good fit. I recently worked on and published an application example using hooks and do (for DI) to emphasize a fully modular architecture: https://github.com/mikestefanello/hooks-example. That highlights the vision I had for the overall approach with hooks, and I think it came out quite nice. I'd really like feedback on that, so if you have any, please let me know.

I did come across that project and didn't like the use of interface{}. If you think it has some functionality that could be useful in hooks, let me know.

There's two problems with using channels for something like this. You would need the listeners to be constantly running each in separate goroutines to be able to await channel messages as opposed to just registering func callbacks and invoking them when needed. And with channels, if you have N listeners, only 1 will receive each given message, whereas with hooks, you want all of the registered listeners to be invoked.

Sure. I see it making sense in most/many cases to write something like this yourself so you have full control over it. I didn't write it in hopes that it would be mass-adopted. Just had the idea and wanted to work on it and share it. Maybe it's a good starting point for the custom code you'd write in your app.

Yes, I did forget to push that. Will do now. Thanks.

Thanks - and thank you for Ent as well. I do like the middleware concept. That's what I first thought to do for these hooks since it's a similar pattern. A key difference, and one that I'm thinking about for this project, is whether or not a hook should be able to terminate execution for all other hooks (ie, returning an error or invoking the next callback). I think in Ent's case it makes sense to have it the way it is, because the only implementer of a given entity's hook is the entity's schema itself - so if it errors, the operation overall should stop. I can make either case for general purpose hooks. I didn't want them to return errors to avoid coupling and having to check and handle errors when dispatching a hook but there are cases in where I would want that. For example, for a entity/model operation (ie, user insert), it would be nice if the insert hook passed along the DB transaction, and hook listeners could execute their queries on that transaction (ie some other entity gets created when a user is created). But, you can't really do that without returning and handling hook errors.

That's a very well thought out explanation and it's completely understandable. Thanks for taking the time to elaborate.

We can quibble on whether or not a handler should return an error in Go, but then we have to decide about the semantics of dispatching a handler asynchronously which I’ll leave as an exercise for the reader.

It's a good point and one that I'm a bit stuck on right now. I had the idea to use hooks to transmit the DB transaction used to perform some operation (ie, user insert) so that the listeners could include their queries, but you'd have to not only facilitate errors being returned, you'd also want to, in this case, stop execution if any of them fails, and that sort of pattern begins to defeat the purpose of hooks quite a bit.

Thanks!

Looks like an interesting project. I'll check it out.

That looks interesting but I think it's quite different since it uses channels and always-running goroutines to listen rather than explicit callbacks. But the overall concept looks similar.

Hey. I'm a huge fan of Ent. I think it's an amazing project. Thank you for your work on it. I do know about the hooks and I have used them before. I looked at the implementation while working on this. Like you said, it does rely on code-generation and I wanted something a bit more flexible. The other slight downside of Ent's hooks is that you can only implement them in the model's schema, rather than anywhere, which is what I was aiming for.