Rails app for Angularjs, building the rails league application: part 1

Part 1 of a tutorial that connects AngularJS to a Rails backend. This post focuses on creating a base Rails server application that our AngularJS front end will later connect to, it assumes that you are familiar with Rails already and have all the rails dependencies installed.  The next post is Installing ng-boilerplate, and serving up via Rails.  You can also find the index of the posts in the tutorial.

There is a newer, rails 4 and newer angularJS, version of this tutorial.  It is also more complete and has a nicer UI that doesn’t use modal windows, which is probably a better choice for anyone starting fresh today.  The first page in that tutorial is here, and the index here.

Angularjs and rails: looking at integration

I’m looking to learn angularjs, based on the recommendation of an acquaintance.  I’ve read a fair bit about it, particularly from the angularjs home page.  It looks like a very powerful way to build a single-page web app, and has a bunch of benefits.  It also seems to have impenetrable documentation, and to be a little immature still.  Finally, the integration with rails is less than clear.

So, a challenge then.  Over the next wee while, I’ll be spending some of my free time trying to make something sensible out of this.  The first decision I’m making is how I’m going to tie rails and angularjs together, at least for the sample application.

Rails, MYSQL and clustered primary keys

Rails by default creates every table with a primary key of ‘id’.  This is a sequence generated key that is globally unique.  There are benefits for insert performance, but depending on your usage model query performance can be impacted by this scheme.

Consider the case of an application, a (the stereotypical) blog that has posts and comments.  Imagine that this is a reasonably high volume blog, so we have lots of posts, and lots of comments, and the nature of the blog is that old posts attract comments over time.

Datatables and rails, server side or not?

When using datatables one of the big questions is whether to go with server-side processing or client-side processing.

With client-side processing all the data is retrieved in one go, and held in memory on the browser.  Paging and filtering are done locally in the browser.

With server-side processing the data is retrieved in pages.  A subset of data (typically a page) is returned to the browser, when the user pages down, changes the sort order or changes the filter criteria, a request is made to the server for a new page of data.

We’ve spent a bit of time thinking about which we would want for the application, and this post goes through the pros and cons as I see them.

Rails and datatables, lazy loading and using a single controller

Datatables are a fantastic way of displaying your data in a table, with lots of formatting and processing options. Datatables is open source code, and turn up all over the web. You can find the current release at datatables.net, an example of a datatable in operation is on that front page.

Whilst datatables are very cool, integrating them into Rails isn’t quite as easy as you might want. I’ve been following the instructions on the railscast on the topic, which is also predictably well written and clear, and gets you started well. Having said that, it has some elements that don’t quite fit what I wanted for my framework:

1. It does either client side datatables, with the data sourced from re-processing your index page, or server-side datatables, but nothing in-between.  This has some performance impacts (discussed in a later post)
2. It doesn’t use some of the additional elements I wanted, such as column re-ordering and editing in place
3. It doesn’t use the filter classes, which I’d also like to use
4. The way it integrated into the controller didn’t suit my view of how it should look (although noting I’m not exactly a ruby expert, what I think is elegant might not fit other people’s view of the same)

So this post covers the way that I integrated datatables into my framework, drawing heavily from other resources on the web as I go.

Rails, datatables, performance and eager loading, joins and includes

I’ve been working on integrating Rails and datatables, following a range of very good tutorials on the web, the best of which I think is the railscast on the topic.

An area of discussion has been whether to go with server-side or client-side processing. In a separate post I’ll talk about that, but for now we’re going client-side. That means that we need Rails configured to push a reasonable number of rows (say 1,000-10,000) down to the browser reasonably quickly. This post discusses some work I’ve done to try to achieve that, with a sample table + 5 joins to subsidiary tables, I’ve moved from 14s to 1.4s, which I think is a worthwhile improvement.

Ruby: single quotes and double quotes

Another random thing that I noticed and/or remembered as I was writing some more code.  Single quotes v’s double quotes in ruby on rails.  You’ll note that your controllers all generate with single quote strings, such as:

    format.html { redirect_to @account, notice: 'Account was successfully updated.' }

But double quote strings also work.  I was sort of interchanging them, until I remembered the difference.  A single quote string is a literal – it’s always used exactly as is.  A double quote string does pattern matching, so you can write something like:

    format.html { redirect_to @account, notice: 'Account was successfully updated for account #{@account.Name}.' }

Which substitutes in the account name within the string.  Because the double quote form needs to check to see if there’s variable substitution in there, it’s a little slower than the single quote form if you don’t actually have any variables in there.  So the rule is: use single quotes if your string is static, use double quotes if it has variables or other funkiness in it.

 

Ruby on Rails: Starting

My better half is about to start working on an application.  So I’ve been rehashing some work I did a couple of years back with Ruby on Rails – I built an automated watering system that pulled down weather forecasts and observations from the web, and calculated the amount of watering to do based on temperature, evaporation, recent rainfall and forecast rainfall.  I was pretty happy with it, as it reduced my water usage, which is useful when you’re using tank water and your tanks aren’t too big.

Anyway, the hardware controller I had for the valves eventually died, and I went back to a standard watering system largely in the interests of “decluttering” my life – one less thing to maintain.

I’ve been looking at that work and writing some sample apps in Ruby so I can remember how to do it.  I’m going to be posting some thoughts on Ruby, and information that I’ve gleaned.