@grimluck343: Yeah like I said before I'd love to see the return of tasks and bounties, once we have a solid structure to build on I'd love to get into stuff like that.
@wcarle: Sounds good to me! Small calls and small services go!
@finaldasa: A built in kanban board or something would be pretty great, but I would imagine that's more than @wcarle and the team want to tag on. If you aren't already using one I would highly recommend it, works great for tracking tasks.
Yeah we may be able to look into that in the future, but we don't want to get too crazy about adding new features in until we have a really solid and reliable base to work from.
As an occasional DB programmer I'll definitely be following this closely. Seeing this stuff being built is neat and hearing the thought behind particular structure implementations can be a great learning experience.
Yeah it's been a great learning experience for me too. The sheer amount of data we have in the wiki really forces you to think carefully about every decision you make.
@gravytrain: So we're building these services to be muuuuch leaner than the current wiki system. Performance is one of the first things on our mind. Every time we write an endpoint we profile the hell out of it and try to minimize database calls. We have some safeguards already in place for any IPs or services that are hammering us. We are pretty confident with our new system, but there will be some serious load testing in the future to be sure.
Currently we don't have our databases split across regions but we do have a very robust database cluster with multiple redundancy. Our big concern is the increase in the number of calls made during the course of an editing session which will increase significantly (so traffic to the master Db will increase). On the other hand each operation is tiny and atomic so it reduces processing time significantly. Db reads are heavily cached and are handled mainly by our large cluster of slave Dbs so we should be good there. We have a great Ops team that we'll work with to make sure we can handle the faster edit calls going to the back end.
@szlifier: Not just yet, we are writing the APIs in a way that will make it easy to expand them to other types of content. We're focusing on the wiki first but eventually we want to expand to other types of content.
@fattony12000: Yeah finally on that web standard shit :)
@devil240z:Yes searching is a problem right now, our first priority is to tackle the edit interface, that needs the most love. After that we want to expand our new api for better searching/filtering/etc. as well as a better browsing interface.
@mento:Yes we'll have to shut down edits for a little while as we transition, more info on that as get closer, shouldn't be for too long though.
@theampersand: Hopefully we'll be able to have more details on the backend soon, right now we're still planning and firming up the architecture. We want to have solid plans in place before talking too much about it. One thing I will mention though is that we're leaning heavily towards using REST web services and using them ourselves to build the interface, this should serve to really strengthening our API
@not_rage: Stay tuned for more info on this. I'll be posting a blog soon centering around wiki it's a big priority for us we are still discussing the scope of our work
wcarle's comments