- November 05, 2015

by Jonathan Michaux & Pierre Reliquet
Restlet’s engineering HQ moved to Nantes mid 2014. There’s a lot of hype about this French city on the border of Brittany, and we were pleasantly surprised. A number of unique music venues and bars make it a vibrant city.
Being music fans, we were let down by the lack of a complete, well-designed, listing of events with a strong focus on quality music events. So we decided to build one, and thus Partypedia was born.

The right tools for the right job
The project has become an epic integration of cutting edge tools that is summarized in the diagram below.

Let’s take a quick look at what each piece of the puzzle does.

Step 1: Data Extraction

kimonologoWe had tinkered with the Kimonolabs web scraper previously and now finally had a real use for it. This helped us bootstrap an initial data set.

Kimonolabs lets you “kimonify” a website, turning structured elements from a page into an API that you can query. It also has webhooks that push the latest version of the data somewhere. That is an awesome feature that helps build a continous and automatic data update chain (although there are still some manual steps in our process). We built one Kimono API for each of the venues that we like in Nantes.


Step 2: Data processing

webscript_logoWe wanted to tweak the data produced by Kimonolabs to generate unique IDs for events, built as a hash of a set of event properties.
We also wanted to flatten the data structure produced by kimono which contained superfluous nested structures.

We used, a simple service that receives HTTP requests, does some processing on the payload, and makes outgoing requests with the results. The language for processing is Lua, a powerful scripting language that is popular in academic and gaming communities.

The data coming out of Webscript is formatted just the way we need it to be.

Step 3: Data backend & API

apispark_sparky_flyingWebscript sends processed data to APISpark via a secure web API which feeds an Entity Store. The API is also used by the frontend app to load event data as well as comments and other good stuff. APISpark’s data browser is also handy for making final edits to data before making the final cut. The screenshot below shows the overview of the Partypedia API.

Step 4: Frontend app

The existing websites we found made the process of finding information a chore.
The goal for our web application was to provide a clear, simple and easy to use interface.
partypedia_6We spent some time thinking about what basic elements were required for a UI to respond to these objectives. We focused on being able to browse a list of events sorted by date, paginated week by week.

Out of the many existing options for a frontend framework, we chose to use AngularJS. We used Angular to build a full-stack JS application with routes and the ability to bookmark pages, which makes for easy link sharing.

partypediaWhat about UX? We decided to use one of Google’s latest tools. Material Design could be defined as a specification which aims to create a uniform UX across devices so that a developer can easily design his/her app for both a smartphone and a browser. We like to check out event listings while on the go, so the frontend had to be responsive.
We also experimented with Angular Material, the integration of Material Design within the AngularJS ecosystem. This makes it easy to reuse many components developed and tested by the Material team.

Partypedia is a prototype but is destined for great things. Don’t know what to do this weekend in Nantes? Do you love great music? Check out Partypedia, and let us know what you think!