Pliny for Rails developers

The biggest difference for developers coming from Rails to keep in mind is that Pliny is for APIs only, and as such it won't help with forms, views, sessions, etc. Our approach to these is to rely on a Javascript framework like Ember.

When it comes to the back-end, Pliny incorporates a lot of the patterns that came with Rails – with a few differences:

• Models: Have the same function and work similarly, although using Sequel::Model instead of ActiveRecord.
• Controllers: They're called "Endpoints" in Pliny, and are implemented with Sinatra.
• Migrations: Again very similar, but using Sequel.
• Testing: Pliny uses RSpec.

Pliny also adds a few concepts that might be new to Rails developers:

• Mediators: Simple classes used to keep endpoints and models lean.
• Config: Helpers to do env-based configuration as opposed to database.yml and others.
• RequestStore: Helper to share important request data across models, endpoints and mediators.

And is more strict than Rails in a few areas:

• The database is Postgres. Pliny gets a lot of leverage by enforcing the database system, from performance tweaks to monitoring hooks.
• The only API format supported is JSON.
• Versioning happens in HTTP headers.

Further reading:

• HTTP API Design Guide