Sonatribe technical bits and pieces

The sonatribe project makes use of a broad range of technology from PHP to Microsoft Azure and a lot in between. We host the main site on Ubuntu but the backend is hosted on Azure and makes use of ServiceStack to build the REST API. The main components of this project are:

  • PHP UI - running on an Azure Ubuntu VM
  • ServiceStack REST API - running on an Azure Windows VM
  • RavenDB database
  • EXTJS admin application
  • 2 x Azure worker roles used to process event and artist information
  • Azure ServiceBus
  • Azure Cache
  • Azure CDN
  • SignalR backed chat server
  • Xamarin iOS app
  • Xamarin Android app
  • Facebook canvas
Sonatribe has always been developed in our (stu, chris and myself) spare time - so no wonder it's taken ~3 years to develop and get the alpha out the door! The initial build of sonatribe (the site is currently on it's third rebuild!) used a CQRS backend and although I maintain this is the best architecture for a project like sonatribe, the complexity in the development/test cycle slowed progress too much, for such a small team trying to get a working "something" out the door, I had to make the hard decision to refactor the code and simplify it. 

Both the main website  (PHP UI) and the Android & iOS apps use the same API for authentication and data. This is a great design as it means all of the business logic stays in one place. And when you're building a system that relies on multi-axis permissions/roles with a range of business logic and views over the data - this is a big advantage. 

The Extjs admin app allows us to import data from clashfinder. The data coming from that JSON is very basic and only specifies the act name, stage and time of the set. In order to build upon that data to be able to provide spotify playlists, artist bio's and images etc we have an import pipeline which also allows us to update that data (quite complex as the clashfinder data has no Id information). Importing information for each act is quite a long running process as we gather as much information as we can about each artist, we download images relevant to each artist and generate renditions for use in the site. Because of this long running process the import process follows the following flow (ignoring clashfinder updates - that's another story!):
  • Initial import fired from admin app
  • The REST service picks up the import ID and pulls the data from clashfinder
  • The JSON is deserialized into POCO
  • A RavenDb bulk insert operation is started
  • The locations (stages) are pulled out of the data and are added to our database
  • For each of the artist sets we create a new listing event - a simple document which specifies the act name, stage, start and end
  • The bulk insert is committed to the DB - this process can take ~ 1 sec for a large festival with ~2000 acts and ~190 stages
  • For each listing event that was created we push a message onto the Azure ServiceBus
  • The worker process at the end of this queue picks up each message and processes it asynchronously.
  • We check to see if we can find any information about the act by using their name - we check spotify, last.fm, music brainz, wikipedia etc
  • If we can find the artist we download their spotify track Ids, artist bio, images etc and create a new artist in our DB linking all of these assets.
  • The artist is added to the listing event and saved
  • If we can't find the artist by the act name alone we try to break the name down - searching for substrings - perhaps the act is a collaboration.
  • For each artist we find in the act name we add them to the listing event and save it away
The admin site has it's own schedule designer using bryntum scheduler which we can use to create and edit lineups. The preferred method atm is clashfinder imports due to the communal collaboration that goes into creating them.

Using Xamarin to develop the Android and iOS apps means we can share a lot of the code base between the apps as well as make use of SignalR to provide chat functionality. Servicestack also provides a great PCL client - it's a no brainer. The apps are currently in the early stages of development - at the moment you can log in, view festivals and their lineups. We aim to have very basic implementations out in the app stores before Glasto. The apps will be free :)

We've recently released the 1st alpha of sonatribe (http://alpha.sonatribe.com) and while there are a few rough edges we're very pleased with the result. The platform differs from anything out there at the moment because of the social aspect of the site as well as the fact that we will be offering native Android and iOS apps. While the alpha is a very bare bones (and in some places quite clumsy) implementation, we have a great platform to build on. This year our aim is to stabilize the platform, introduce the mobile apps and react to feedback. Our next big undertaking is tackling conversations, to build on the social aspect of the site. We're planning on swerving the traditional "forum software" implementation and intend to build a conversation platform from the ground up based on the usage of our demographic - something we can grow and improve upon and will be suitable for the next 10 years - not extinct 10 years ago. We've always found forums to be too 1990's and we've always said Facebook waters down the semantics too much for something like this (the whole reason sonatribe exists). 

We've got a great set of features and a lot of work has gone into getting to where we are, we're listening to user feedback and looking forward to the next set of great features. There's a hell of a lot left to do though!

w://

Comments

Post a Comment