I'm currently writing a forum, I've been doing that for a few months now. You know how people have a plushi next to the they can talk to in order to develop ideas, this is my plushi.
And while writing I've been thinking of all the great forum software PHP has, vbulletin, phpbb to name the most prominent. They have a plugin system. They also have a lifecycle. And then there is Drupal which is essentially a customizable content platform. A plugin in Go can be both a literal plugin ( https://golang.org/pkg/plugin/ ) but also an interface that describes a "CMS plugin". e.g. type CMSplugin interface { Register() UnRegister() // ... } Drupal has lifecycle hooks e.g. https://api.drupal.org/api/drupal/includes%21module.inc/group/hooks/7.x I'm not looking to clone Drupal, but take it more of as it being an inspiration. I remember around 2000 modular C++ design was all the rage. But what about Go? It has all the tools. What would lifecycles be...? Does this design principle even apply to a restful service since there is also the rendering part. So one would have to create an "isomorphic" toolset. Web assembly with Go apparently doesn't have the performance needed, from one blog post I've read. But I guess I have to do my own research first, as always ;) The intro to web assembly is really nice. However syscall/js is experimental without a stable api. But even the renderer could be a module... I don't know where to start. I feel like I'm trying to mix tomatos with bananas. Any input/feedback or ideas at all would be appreciated. ... some notes A traditional webpage has request computation/processing response request hits middleware where the context carries values then finally reach a handler that does usually get data from a database based on the request parameters, then render a response, be it a html page or json output. So we have ProcessRequest LoadDataFromDatabase SaveDataToDatabase RenderOutput Only in our case the middleware is a plugin. So we have following lifecycle hooks BeforeProcessRequest ProcessRequest AfterProcessRequest BeforeLoadDataFromDatabase LoadDataFromDatabase AfterLoadDataFromDatabase BeforeSaveDataToDatabase SaveDataToDatabase AfterSaveDataToDatabase BeforeRenderOutput RenderOutput AfterRenderOutput So everything is a plugin But there is more to be considered. Routes/Routing. And how do I know which plugin works for which handler? So I'm guessing there need to be core plugins and handler plugins. Core plugins.. I load my configuration from environment vars, from a config file, from input params. I connect to a database and pass this to either repositories or the handler struct as a member. I set up a logger I set up routes that map to handlers I run it But, what if I want to use different DBs... then I can define those in the configuration So the configuration needs a certain layout BeforeLoadPlugins LoadPlugins AfterLoadPlugins BeforeLoadConfiguration LoadConfiguration AfterLoadConfiguration BeforeConnectToDatabases ConnectToDatabases AfterConnectToDatabases BeforeSetupLogger SetupLogger AfterSetupLogger BeforeSetupRoutes SetupRoutes AfterSetupRoutes BeforeRun Run AfterRun What about making it event based? EventHandler... a struct with a channel of a struct type Event struct { Name string Callback func(params ...interface{}) } type EventHandler struct { EventC <-chan Event } Sounds like a plan -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
