I’m wondering if anyone here know if anyone is working on forums software like this discourse forum but purely made in Go (well, besides the necessary html/css/javascript)? I’ve found some basic ones made coming from Asia, but either it’s too basic, or not active. Like this one: https://github.com/jemygraw/wetalk
Besides Go being a fantastic language to write this in, I found discourse being a pain to install. Not to mention the hardware requirements needed.
Maybe I should just start writing it myself. I hesitate, because I was thinking someone must have started something like this already. Can’t find it though.
Forum software can be a surprisingly big endeavor: authorization, authentication, uploads (local? S3?), moderation tools, user profiles, etc. Also note that Discourse’s front end (in Ember) is probably just as complex as its Rails backend. Any Go forum that elected to use (e.g.) React or Vue.js would have almost as much non-Go code, and a simpler server-side rendered Go app would have a lot of template logic.
Discourse’ Docker deployment is meant to simplify things (arguably), but most of the deployment complexity (even with Go) will be setting up the DB, a session store (Redis), backups, and documenting it all.
Well, to do it in Go, you could just start with MongoDB, SQLite, hell, why not use something Go native such as https://github.com/boltdb/bolt or https://github.com/HouzuoGuo/tiedot . And then use Gorilla Toolkit and other auth libs to get going with the basics for the backend. Then use Bootstrap or Foundation for frontend. No need to get fancy with React or vue.js. And then use websockets for messages between server and client.
This would be made in such way it’s dead easy to build and run.
Of course—there’s no need to build it as an SPA, but I mentioned that as
you mentioned Discourse, and Discourse being an SPA is what makes it fairly
slick.
(just don’t underestimate the work: it’s much more than just plugging
together Gorilla pieces. authz will be a pain!)
Thinking out loud here: how hard would it be to port Discourse to Go? The hard work is already done (frontend) and knowing its lineage, I dare guess that the design of its REST interface is good. The porting effort would concentrate around the backend. The motivation for wanting to do something like this is that Discourse’s backend has (for what it does) pretty high resource requirements and it’s relatively hard to scale. Go doesn’t directly help with the later but it might help with the former. Right now it’s a monolithic Rails application, so most of the porting effort would be around providing a replacement for ActiveRecord. AR is likely responsible for most of the resource requirements and does a ton of on-the-fly code generation. The other big chunk of the effort would go to the template system (haven’t looked to see if it’s using ERB or something else).
That actually sounds like a good idea at some point in the future.
I don’t know how Discourse does its server side rendering (it could be in Ruby for now), but Ember is coming up with fastboot which is a Node.js based server side rendering solution. It is expected later in the 2.x line.
Once that comes through, you would need to write ZERO rendering code in Go. Knock yourself out with lots of Gin for the APIs instead!
You need to write the authentication and various service APIs. There would be a need to write an adaptor for Ember Data (if Discourse uses it) and write a long polling server for the realtime features.
Postgres and Redis could be kept as-is and you can have them serve the same functionality they currently do.
I certainly don’t think its backend is trivial to implement but it should be a nice exercise for someone who knows both Rails and Go.
Looking at the code, right now there’s a few simple ERB templates and a lot of Ember. It’s using Babel, so it’s actually a lot of ES6, but I guess that doesn’t make a difference in what you said.
So, what you are saying is that server-side rendering is offloaded to the node.js server (proxied from a net/http server?) and all the database accesses, etc could be done in Go. Is that correct?
It’s using quite a few gems, but after a very quick glance I didn’t spot anything that isn’t already available for Go in one way or the other. It’s using a combination of PostgreSQL and Redis. The model code is sizable and there’s also a good bunch of controller code.
I think eventually Discourse would themselves become one of the biggest customers of ember fastboot as it would help reduce the size of their core (unless they do something crazy with their templates which cannot be easily ported over).
I really look forward to fastboot becoming GA. I’m sure a lot of us would want to get our hands dirty and try porting Discourse for fun, profit and glory.
Sad story there though, as the Microcosm company had to shut down. They had interest, but ran out of money… so who knows what will happen with that codebase now…
It’s on Github, so it doesn’t seem to be going anywhere. It could be like a head start over starting to port tens of thousands of lines of Ruby, while being compatible with the undocumented, evolving, “organically grown” REST API that the Discourse client side code expects.
(I’ve been following the Discourse development since a couple of years as I’m a user, and I’m not as impressed by the underlying practices and philosophies as some others here seem to be.)
Could you point me to blogs and/or articles that discuss Discourse’s API design ?
I haven’t followed its development much but it so happens that every new discussion forum around a software or a framework is powered by it and I find the UI extremely usable on both desktop and mobile.
There’s quite a few of them and the roughly 50/50 mix of underscores vs dashes in the naming doesn’t speak to me of a cohesive design. This thread is the closest thing to documentation: https://meta.discourse.org/t/discourse-api-documentation/22706
Note that that forum is also their documentation site and bug tracker. That means, among other things, that bugs considered fixed are closed against further comments… If they were deemed invalid or duplicate they are often simply deleted.
How is this going? Seems there were some updates made 2 months ago here: https://github.com/beego/wetalk which makes me happy to see there is some activity…
