What makes or breaks software is the balance between developer efficiency and code quality. With no previous coding experience in Ruby and a short delivery deadline, I was able to leverage the power of Ruby libraries in designing micro APIs within a span of a few weeks.
The product to be built can be said to be a representation of an accounting and billing and disputes management portal.
## What our software requirements were? - Lowest footprint possible - avoid programming nitty gritties, and focus on business logic. - Loosely coupled components - The layers of the API should be flexible to changes in data structure. - Think HTTP, not models. - Separation of concerns. More predictable change. ## 3 RESTful API layers: Presentation, Business logic and Data access. ## Why Rails wasn’t the best fit here. - Focuses on model driven applications. - Good choice when building big, monolithic web applications. - Less design control in the developer’s hand. Tries to curate the best set of technologies. ## Sinatra: A thin and lightweight framework built on top of Rack. - Follows an abstract pattern: no restrictions on organising code. Developer decides the modelling. Trade convenience for design decisions. - Supports Rack Middlewares. - Uses throw-catch to control program flow. route_eval. - Metaprogramming in Sinatra: Ease of writing and registering extensions with Sinatra. - Ease of mounting Sinatra apps inside Rails 3. ## Sequel: Flexible and powerful SQL access toolkit. - Simplicity: Prefers a simple OO design. - PG extended query protocol. - Application code is not tied to the schema. - Datasets: Fetch only when needed concept. ## Sequel vs ActiveRecord. - Complex queries handled using datasets, unlike in Active Record where Raw SQL is the only solution. - Simple queries such as bulk insert of data have better readability. ## This is why Ruby is still relevant: - Years of community contribution. - Unlike Java, where language constraints overpower business logic, Ruby is easier to grasp for beginners.