Recently I have to build a JSON API to wrap the connection to persistence layer in order to be able to change (or add) DBMS later and define more structured logic (authentication, selective caching, …). I didn’t know which DBMS to use but I had to start develop the other components which relay on this persistence layer.

To avoid delay while choosing DBMS setup we decided to build a prototype using Rails and MySQL in order to start defining API’s methods. Rails is really useful when you had to create a MVC application but includes too much stuff if you only need to build an API. This is why usually we use Sinatra.

This time we tried Rails::API,  a subset of a normal Rails application. It’s a bit faster and lightweight and you can use your existing Rails app.

To use it you only need to add gem to Gemfile:

gem 'rails-api'

change the ancestor of ApplicationController

class ApplicationController < ActionController::API
# [...]
end

and comment out the protect_from_forgery call if you are using it.

Everything seems to be ok. Created four models, a couple of controllers with usual REST action and everything is done: my prototype is up and running.

Unfortunately there are some new Rails feature that aren’t well supported by this gem. The most important is the wrap_parameters support IMHO. The ActionController::ParamsWrapper should automatically make a copy of request’s parameters into an hash named as the element you are sending.

For example, if you send to /users:

{"name": "Andrea"}

controller should receive:

{"name" => "Andrea", "user" => {"name" => "Andrea"}}

It is very convenient if you use standard ActiveRecord-based scaffold but Rails::API doesn’t support well this initializer: https://github.com/rails-api/rails-api/issues/33. You have to setup it manually.

Into each controller you must define how to wrap params:

class UsersController < ApplicationController
wrap_parameters :person, include: [:name], format: :json
# [...]
end

Is the only issue i found but took me a lot of time to be solved. I choose Rails because is easy and I can build a prototype in a flash but I think is still to early to use it to build an API, maybe Rails 4. At the moment I still prefer to use Sinatra.

Thanks to @olinicola, he built the prototype and found the solution to the issue.

ActiveRecord is an incredibly powerful tool but the Rails Guides doesn’t cover every possible situation and the ActiveRecord’s official documentation is huge. Find something you are looking for can be hard. If you have to do something strange and you have no time to search you have to hope someone had got the same problem and posted it on StackOverflow or on its own blog.

Recently I have to modelize a relation where a resource belongs to an entity and contemporary is related to N other entities.

The One-to-Many relation is easy: use belongs_to and has_many. The other part is harder because you need to use a connection table (HABTM doesn’t work) and you need to rename relation because its name is already taken.

You can use a connection table using through attribute:

has_many :connection_table
has_many :items, through: :connection_table

and rename a has_many through relation using source attribute:

has_many :related_items, through: :connection_table, source: :items

Problem solved:

class Resource < ActiveRecord::Base
belongs_to :entity
has_many :connections
has_many :related_entities,
through: :connections, source: :entity
end

 

class Entity < ActiveRecord::Base
has_many :resources
has_many :connections
has_many :related_resources,
through: :connections, source: :resource
end

 

class Connection < ActiveRecord::Base
belongs_to :entity
belongs_to :resource
end

Thanks to @olinicola for the advises 🙂

If you run a commercial webapp, probably you have to track access.

CloudFlare helps you to manage more connection but hides from you many informations about the client. If you try to log the IP address you always get the CloudFlare’s ones.

Common headers which nginx uses to forward original IP (X-Forwarded-For and X-Real-IP) contain the CloudFlare’s IP. The correct header where to look is HTTP_CF_CONNECTING_IP.

1
2
/* PHP */
$_SERVER['HTTP_CF_CONNECTING_IP']
1
2
# Rack
request.headers["HTTP_CF_CONNECTING_IP"]

I’m a developer and I want to start a blog. There are many different engine I can chose: Jekill, Tumblr, Posterous and counting. I choose WordPress because it’s more user friendly IMHO. The problem is: self-hosted or managed?

As usual every choice has pros and cons.

If you choose a self-hosted solution you have to pay for it. Most of times developers can access to a friend’s VPS and deploy there but this require you to setup the environment (nginx, php-fpm, MySQL and so on) and keep everything up to date to avoid intrusions.

If you chose the managed solution you have to pay. WordPress.com offers a free plan but includes advertising and use of plugins is forbidden. The premium plan is better but is 99$ a year.

I tried both solutions. I deployed a version of WordPress on a VPS (thanks @dani_viga). Then you had to install nginx, install php-fpm, configure virtual host, fight against configuration problems, fight against permissions problems, fight against incompatible plugins and finally your new self-hosted WordPress blog is online (and you have a big headache). I’m a developer, not a Sysadmin. I don’t like to refine configuration, keep everything up to date. I just want something easier.

So I tried WordPress.com because I couldn’t find another provider with a free plan. Beautiful site, great wizard for setup blog, everything is up and running in five minutes. I start to write my first post but i didn’t like the syntax highlighter. There is no way to change it. I want to include a custom social streamer. There is no way to do it. I want to customize my template. There is no way to do it… I closed my account. I’m a developer: i don’t like stuff I can’t edit.

One minute before giving up I decided to try one last solution: Heroku. The Cedar stack supports PHP. I searched for a WordPress version ready to deploy on Heroku and I found this. It uses PostgreSQL and, after five minutes of setup, works like a glance. The only problem is the file upload but I solved using the WPRO Plugin (WordPress Read-Only) to upload file directly to Amazon S3.

Now my blog runs in the clouds 🙂