Apps backend

When I first launched my apps some years ago I started out with a simple PHP/MySql backend. I didn’t use any frameworks, only a few self-written classes for database connections. The main purpose for this backend was so that users would be able to share routes.

Every route that is created on a device is synced to the backend. The backend returns a unique id for that route and users can reuse that id should they want to use that route on another device.

I wanted to make the sharing of routes between different platforms as easy as possible, that’s why I choose this solution. It works fine: I can layout a cycling route on my iPad and if you’re on Windows Phone: no problem, just type in the number and you’ll have the same cycling route.

Laravel

Recently I’ve been making customer apps that require custom backends and I wanted to move away from the quick hack PHP solutions. I had a look at some PHP frameworks like CakePHP, Yii, Symfony and Laravel. I had no real preference, but Laravel seemed to be the up and coming one. I started experimenting and bought a few books.

I felt the learning curve was high but the more I played with it the more sense it started to make so I stuck with it. I have a few customer backends up and running now and they’re fine. They’re very easy to maintain and extend because of the app structure that is sort of forced upon you by a framework.

In September 2015 I ported the app backend to Laravel. The main goal was to get more insight in how the different apps were used. The old backend hardly had any visuals and the only real metric I had was the daily distance sum of planned routes.

Heartbeat

The new backend has a lot of visuals. I’ve used graphics to visualize the total distance of planned routes on a daily basis, for the last 14 days. I can easily switch to a longer period but so far 14 days has been a good indicator.

The screenshot above shows the distance dashboard. On top the total distance per app is shown, below that is the detail per app for the last 14 days.

What I also wanted to know was which parts of the app were used. In the screenshot above you get a glimpse of that, but I’ll come back to feature logging in a dedicated future blogpost.

The last screenshot shows how often people search for places or zipcodes in the app. Right now that’s a very simple list that groups searches and then summarizes the result. There’s no doubt that more exciting statistics can be pulled from all this data but for now capturing that data is enough.

Job done, for now

The good thing about the new backend is that I can now wrap a website around it and talk to the same data. I could easily implement a route search on the upcoming website as well if I wanted to.

You’ll see in the screenshots that the menu on the left has a lot more options that we haven’t discussed in this blogpost. I’ll come back to those in a future blogpost when I’ll discuss the network databases that are shipped with the apps and how these are reused in the backend.

Some of the options in the menu on the left are not yet implemented, but are placeholders for some things I hope to implement this year.