This post refers back to my COLOBackcountry project. The project takes advantage of the standard Rails MVC pattern to serve up some of the content, and relies on an internal API for the rest. The app basically has a few static pages (main/index, about, etc.) and show pages for the individual ski routes. The pages are rendered in the normal way and the map data are pulled in from a GeoJSON API. This gives the app a very modular character which will lend itself to breaking the app down into a service-oriented architecture in the future.

General Architecture and Design Considerations

I spent a fair bit of time thinking about the architecture for this app and getting UX input from others. In the end, I think that it lends itself to a one page javascript style, but frankly, I don't know enough javascript to feel comfortable implementing this.

On the other hand, I'm very comfortable building "normal" rails apps so I decided to focus my limited time on integrating all the other new technologies. I look forward to integrating a javascript framework for the front end in the future.

POROs

This app has only a few controllers and only a few pages. In order to separate concerns, I ended up building several POROs (Plain Old Ruby Objects) for various data processing needs such as geospatial operations.

One problem I came across was where to put these POROs. On the one hand, they are somewhat akin to models, and on the other, they are their own sort of thing and do not inherit from ActiveRecord::Base. I ended up keeping them in app/models/, but in the future would consider moving them to lib/. I turned my GPXParser into a gem, despite its measly single class.

Index/Show

I didn't deviate from the vanilla rails actions too much. One place that could have potentially used a bit of a change is the index vs show pages. If the app used more javascript and AJAX then I think that it might make sense to have only one page to view the various ski routes. As it turned out, I ended up sticking with the index/show pages because it made my GeoJSON API calls easier to handle.

API

Speaking of that API, I decided to serve up all my spatial data using a GeoJSON API. The first reason was that I had just learned about them, and with a shiny new hammer, it seemed only right to find some nails. Aside from that, I like the idea of separating out various parts of my app. If, in the future, I were interested in building out more javascript to make things more modern and slidey, then it will be easy to stick with the current API to fetch the ski routes. This also allowed me to keep my views dumber.

There were a few chalanges around serializing the ski routes into GeoJSON. My solution doesn't seem terribly elegant, but it does work well. Basically the serializer does a lot of string manipulation, iterating through each point of the polyline. It works, but I would like to figure out a cleaner method, even if that just means adding a layer of abstraction.