Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
Layered Design for Ruby on Rails Applications
Layered Design for Ruby on Rails Applications

Layered Design for Ruby on Rails Applications: Discover practical design patterns for maintainable web applications

eBook
₹799.99 ₹2978.99
Paperback
₹3723.99
Subscription
Free Trial
Renews at ₹800p/m

What do you get with a Packt Subscription?

Free for first 7 days. ₹800 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing
Table of content icon View table of contents Preview book icon Preview Book

Layered Design for Ruby on Rails Applications

Rails as a Web Application Framework

Ruby on Rails is one of the most popular tools to build web applications, which is a huge class of software. In this chapter, we will talk about what makes this class different from other programs. First, we will learn about the HTTP request-response model and how it can naturally lead to a layered architecture. We will see which layers and HTTP components Ruby on Rails includes out of the box. Then, we will discuss the off-request processing layer, background jobs, and the persistence layer (databases).

In this chapter, we will cover the following topics:

  • The journey of a click through Rails abstraction layers
  • Beyond requests – background and scheduled tasks
  • The heart of a web application – the database

By the end of this chapter, you’ll have a better understanding of the core web application principles and how they affect Rails application design. You will learn about the main Rails components and how they build up the basic abstraction layers of the application.

These fundamental ideas will help you to identify and extract abstractions that better fit natural web application flows, thus leading to less conceptual overhead and a better developer experience.

Technical requirements

In this chapter and all chapters of this book, the code given in code blocks is designed to be executed on Ruby 3.2 and, where applicable, using Rails 7. Many of the code examples will work on earlier versions of the aforementioned software.

You will find the code files on GitHub at https://github.com/PacktPublishing/Layered-Design-for-Ruby-on-Rails-Applications/tree/main/Chapter01.

The journey of a click through Rails abstraction layers

The primary goal of any web application is to serve web requests, where web implies communicating over the internet and request refers to data that must be processed and acknowledged by a server.

A simple task such as clicking on a link and opening a web page in a browser, which we perform hundreds of times every day, consists of dozens of steps, from resolving the IP address of a target service to displaying the response to the user.

In the modern world, every request passes through multiple intermediate servers (proxies, load balancers, content delivery networks (CDNs), and so on). For this chapter, the following simplified diagram will be enough to visualize the journey of a click in the context of a Rails app.

Figure 1.1 – A simplified diagram of a journey of the click (the Rails version)

Figure 1.1 – A simplified diagram of a journey of the click (the Rails version)

The Rails part of this journey starts in a so-called web server – for example, Puma (https://github.com/puma/puma). It takes care of handling connections, transforming HTTP requests into a Ruby-friendly format, calling our Rails application, and sending the result back over the HTTP connection.

Communication models

Web applications can use other communication models, and not only the request-response one. Streaming and asynchronous (for example, WebSocket) models are not rare guests in modern Rails applications, especially after the addition of Hotwire (https://hotwired.dev/) to the stack. However, they usually play a secondary role, and most applications are still designed with the request-response model in mind. That’s why we only consider this model in this book.

Next, we will take a deeper look at the right part of the diagram in Figure 1.1. Getting to know the basics of request processing in Rails will help us to think in abstraction layers when designing our application. But first, we need to explain why layered architecture makes sense to web applications at all.

From web requests to abstraction layers

The life cycle of a web application consists of the bootstrap phase (configuration and initialization) and the serving phase. The bootstrap phase includes loading the application code, and initializing and configuring the framework components – that is, everything we need to do before accepting the first web request – before we enter the serving phase.

In the serving phase, the application acts as an executor, performing many independent units of work – handling web requests. Independent here means that every request is self-contained, and the way we process it (from a code point of view) doesn’t depend on previous or concurrent requests. This means that requests do not share a lot of state. In Ruby terms, when processing a request, we create many disposable objects, whose lifetimes are bound by the request’s lifetime.

How does this affect our application design? Since requests are independent, the serving phase could be seen as a conveyor-belt assembly line – we put request data (raw material) on the belt, pass it through multiple workstations, and get the response box at the end.

A natural reflection of this idea in application design would be the extraction of abstraction layers (workstations) and chaining them together to build a processing line. This process could also be called layering. Just like how assembly lines increase production efficiency in real life, architecture patterns improve software quality. In this book, we will discuss the layered architecture pattern, which is generic enough to fit many applications, especially Ruby on Rails ones.

What are the properties of a good abstraction layer? We will try to find the answer to this question throughout the book using examples; however, we can list some basic properties right away:

  • An abstraction should have a single responsibility. However, the responsibilities themselves can be broad but should not overlap (thus, following the separation of concerns principle).
  • Layers should be loosely coupled and have no circular or reverse dependencies. If we draw the request processing flow from top to bottom, the inter-layer connectors should never go up, and we should try to minimize the number of connections between layers. A physical assembly line is an example of perfect layering – every workstation (layer) has, at most, one workstation above and, at most, one below.
  • Abstractions should not leak their internals. The main idea of extracting an abstraction is to separate an interface from the implementation. Extracting a common interface can be a challenging task by itself, but it always pays off in the long term.
  • It should be possible to test abstractions in isolation. This item is usually a result of all the preceding, but it makes sense to pay attention to it explicitly, since thinking about testability can help us to come up with a better interface.

From a developer’s perspective, a good abstraction layer provides a clear interface to solve a common problem and is easy to refactor, debug, and test. A clear interface can be translated as one with the least possible conceptual overhead or just one that is simple.

Designing simple abstractions is a difficult task; that’s why you may hear that introducing abstractions makes working with the code base more complicated. The goal of this book is to teach you how to avoid this pitfall and learn how to design good abstractions.

How many abstraction layers are nice to have? The short answer is, it depends.

Let’s continue our assembly line analogy. The number of workstations grows as the assembly process becomes more sophisticated. We can also split existing stages into multiple new ones to make the process more efficient, and to assemble faster. Similarly, the number of abstraction layers increases with the evolution of a project’s business logic and the code base growth.

In real life, the efficiency metric is speed; in software development, it is also speed – the speed of shipping new features. This metric depends on many factors, many of which are not related to how we write our code. From the code perspective, the main factor is maintainability – how easy it is to add new features and introduce changes to the existing ones (including fixing bugs).

Applying software design patterns and extracting abstraction layers are the two main tools to keep maintainability high. Does it mean the more abstractions we have the more maintainable our code is?

Surely not. No one builds a car assembly line consisting of thousands of workstations by the number of individual nuts and screws, right? So, should we software engineers avoid introducing new abstractions just for the sake of introducing new abstractions? Of course not!

Overengineering is not a made-up problem; it does exist. Adding a new abstraction should be evaluated. We will learn some techniques when we start discussing particular abstraction layers later in this book. Now, let’s move on to Rails and see what the framework offers us out of the box in terms of abstraction layers.

A basic Rails application comes with just three abstractions – controllers, models, and views. (You are invited to decide whether they fit our definition of good or not by yourself.) Such a small number allows us to start building things faster and focus on a product, instead of spending time to please the framework (as it would be if had a dozen different layers). This is the Rails way.

In this book, we will learn how to extend the Rails way – how to gradually introduce new abstraction layers without losing the focus on product development. First, we need to learn more about the Rails way itself. Let’s take a look at some of the components that make up this approach with regard to web requests.

Rack

The component responsible for HTTP-to-Ruby (and vice versa) translation is called Rack (https://github.com/rack/rack). More precisely, it’s an interface describing two fundamental abstractions – request and response.

Rack is the contract between a web server (for example, Puma or Unicorn) and a Ruby application. It can be described using the following source:

request_env = { "HTTP_HOST" => "www.example.com", …}
response = application.call(request_env)
status, headers, body_iterator = *response

Let’s examine each line of the preceding code:

  • The first one defines an HTTP request represented as a Hash. This Hash is called the request environment and contains HTTP headers and Rack-specific fields (such as rack.input to access the request body). This API and naming convention came from the old days of CGI web servers, which passed request data via environment variables.

Common Gateway Interface

Common Gateway Interface (CGI) is the first attempt to standardize the communication interface between web servers and applications. A CGI-compliant program must read request headers from env variables and the request body from STDIN and write the response to STDOUT. A CGI web server runs a new instance of the program for every request – an unaffordable luxury for today’s Rails applications. The FastCGI (https://fastcgi-archives.github.io/) protocol was developed to resolve this situation.

  • The second line calls a Rack-compatible application, which is anything that responds to #call. That’s the only required method.
  • The final line describes the structure of the return value. It is an array, consisting of three elements – a status code (integer), HTTP response headers (Hash), and an enumerable body (that is, anything that responds to #each and yields string values). Why is body not just a string? Using enumerables allows us to implement streaming responses, which could help us reduce memory allocation.

The simplest possible Rack application is just a Lambda returning a predefined response tuple. You can run it using the rackup command like this (note that the rackup gem must be installed):

$ rackup -s webrick --builder 'run ->(env) { [200, {}, ["Hello, Rack!"]] }'
[2022-07-25 11:15:44] INFO  WEBrick 1.7.0
[2022-07-25 11:15:44] INFO  WEBrick::HTTPServer#start: pid=85016 port=9292

Try to open a browser at http://localhost:9292 – you will see "Hello, Rack!" on a blank screen.

Rails on Rack

Where is the Rack’s #call method in a Rails application? Look at the config.ru file at the root of your Rails project. It’s a Rack configuration file, which describes how to run a Rack-compatible application (.ru stands for rack-up). You will see something like this:

require_relative "config/environment"
run Rails.application

Rails.application is a singleton instance of the Rails application, its web entry-point.

Now that we know where the Rails part of the click journey begins, let’s try to learn more about it.

The best way to see the amount of work a Rails app does while performing a unit of work is to trace all Ruby method calls during a single request-response cycle. For that, we can use the trace_location gem.

What a gem – trace_location

The trace_location (https://github.com/yhirano55/trace_location) gem is a curious developer’s little helper. Its main purpose is to learn what’s happening behind the scenes of simple APIs provided by libraries and frameworks. You will be surprised how complex the internals of the things you take for granted (say, user.save in Active Record) can be.

Designing simple APIs that solve complex problems shows true mastery of software development. Under the hood, this gem uses Ruby’s TracePoint API (https://rubyapi.org/3.2/o/tracepoint) – a powerful runtime introspection tool.

The fastest way to emulate web request handling is to open a Rails console (rails c) and run the following snippet:

request =
  Rack::MockRequest.env_for('http://localhost:3000')
TraceLocation.trace(format: :log) do
  Rails.application.call(request)
end

Look at the generated log file. Even for a new Rails application, the output would contain thousands of lines – serving a GET request in Rails is not a trivial task.

So, the number of Ruby methods invoked during an HTTP request is huge. What about the number of created Ruby objects? We can measure it using the built-in Ruby tools. In a Rails console, type the following:

was_alloc = GC.stat[:total_allocated_objects]
Rails.application.call(request)
new_alloc = GC.stat[:total_allocated_objects]
puts "Total allocations: #{new_alloc – was_alloc}"

For an action rendering nothing (head :ok), I get about 3,000 objects when running the preceding snippet. We can think of this number as a lower bound for Rails applications.

What do these numbers mean for us? The goal of this book is to demonstrate how we can leverage abstraction layers to keep our code base in a healthy state. At the same time, we shouldn’t forget about potential performance implications. Adding an abstraction layer results in adding more method calls and object allocations, but this overhead is negligible compared to what we already have. In Rails, abstractions do not make code slower (humans do).

Let’s run our tracer again and only include #call methods this time:

TraceLocation.trace(format: :log, methods: [:call]) do
  Rails.application.call(request)
end

This time, we only have a few hundred lines logged:

[Tracing events] C: Call, R: Return
C /usr/local/lib/ruby/gems/3.1.0/gems/railties-7.0.3.1/lib/rails/engine.rb:528 [Rails::Engine#call]
  C /usr/local/lib/ruby/gems/3.1.0/gems/actionpack-7.0.3.1/lib/action_dispatch/middleware/host_authorization.rb:130 [ActionDispatch::HostAuthorization#call]
    C /usr/local/lib/ruby/gems/3.1.0/gems/rack-2.2.4/lib/rack/sendfile.rb:109 [Rack::Sendfile#call]
      C /usr/local/lib/ruby/gems/3.1.0/gems/actionpack-7.0.3.1/lib/action_dispatch/middleware/static.rb:22 [ActionDispatch::Static#call]
         // more lines here
      R /usr/local/lib/ruby/gems/3.1.0/gems/actionpack-7.0.3.1/lib/action_dispatch/middleware/static.rb:24 [ActionDispatch::Static#call]
    R /usr/local/lib/ruby/gems/3.1.0/gems/rack-2.2.4/lib/rack/sendfile.rb:140 [Rack::Sendfile#call]
  R /usr/local/lib/ruby/gems/3.1.0/gems/actionpack-7.0.3.1/lib/action_dispatch/middleware/host_authorization.rb:131 [ActionDispatch::HostAuthorization#call]
R /usr/local/lib/ruby/gems/3.1.0/gems/railties-7.0.3.1/lib/rails/engine.rb:531 [Rails::Engine#call]

Each method is put twice in the log – first, when we enter it, and the second time when we return from it. Note that the #call methods are nested into each other; this is another important feature of Rack in action — middleware.

Pattern – middleware

Middleware is a component that wraps a core unit (function) execution and can inspect and modify input and output data without changing its interface. Middleware is usually chained, so each one invokes the next one, and only the last one in the chain executes the core logic. The chaining aims to keep middleware small and single-purpose. A typical use case for middleware is adding logging, instrumentation, or authentication (which short-circuits the chain execution). The pattern is popular in the Ruby community, and aside from Rack, it is used by Sidekiq, Faraday, AnyCable, and so on. In the non-Ruby world, the most popular example would be Express.js.

The following diagram shows how a middleware stack wraps the core functionality by intercepting inputs and enhancing outputs:

Figure 1.2 – The middleware pattern diagram

Figure 1.2 – The middleware pattern diagram

Rack is a modular framework, which allows you to extend basic request-handling functionality by injecting middleware. Middleware intercepts HTTP requests to perform some additional, usually utilitarian, logic – enhancing a Rack env object, adding additional response headers (for example, X-Runtime or CORS-related), logging the request execution, performing security checks, and so on.

Rails includes more than 20 middlewares by default. You can see the middleware stack by running the bin/rails middleware command:

$ bin/rails middleware
use ActionDispatch::HostAuthorization
use Rack::Sendfile
use ActionDispatch::Static
use ActionDispatch::Executor
use ActionDispatch::ServerTiming
use Rack::Runtime
... more ...
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use Rack::TempfileReaper
run MyProject::Application.routes

Rails gives you full control of the middleware chain – you can add, remove, or rearrange middleware. The middleware stack can be called the HTTP pre-/post-processing layer. It should treat the application as a black box and know nothing about its business logic. A Rack middleware stack should not enhance the application web interface but act as a mediator between the outer world and the Rails application.

Rails routing

At the end of the preceding middleware list, there is a run command with Application.routes passed. The routes object (an instance of the ActionDispatch::Routing::RouteSet class) is a Rack application that uses the routes.rb file to match the request to a particular resolver – a controller-action pair or yet another Rack application.

Here is an example of the routing config with both controllers and applications:

Rails.application.routes.draw do
  # Define a resource backed by PostsController
  resources :posts, only: %i[show]
  # redirect() generates a Redirect Rack app instance
  get "docs/:article",
      to: redirect("/wiki/%{article}")
  # You can pass a lambda, too
  get "/_health", to: -> _env {
    [200, { "content-type" => "text/html" }, ["I'm alive"]]
  }
  # Proxy all matching requests to a Rack app
  mount ActionCable.server, at: "/cable"
end

This is the routing layer of a Rails application. All the preceding Rack resolvers can be implemented as Rack middleware; why did we put them into the routing layer? Redirects are a part of the application functionality, as well as WebSockets (Action Cable).

However, the health check endpoint can be seen as a property of a Rack app, and if it doesn’t use the application’s internal state to generate a response (as in our example), it can be moved to the middleware layer.

Similar to choosing between Rack and routes, we can have a routes versus controllers debate. With regards to the preceding example, we can ask, why not use controllers for redirects?

C for controller

Controllers comprise the next layer through which a web request passes. This is the first abstraction layer on our way. A controller is a concept that generalizes and standardizes the way we process inbound requests. In theory, controllers can be used not only for HTTP requests but also for any kind of request (since the controller is just a code abstraction).

In practice, however, that’s very unlikely – implementation-wise, controllers are highly coupled with HTTP/Rack. There is even an API to turn a controller’s action into a Rack app:

Rails.application.routes.draw do
  # The same as: resources :posts, only: %i[index]
  get "/posts", to: PostsController.action(:index)
end

MVC

Model–view–controller is one of the oldest architectural patterns, which was developed in the 1970s for GUI applications development. The pattern implies that a system consists of three components – Model, View, and Controller. Controller handles user actions and operates on Model; Model, in turn, updates View, which results in a UI update for the user. Although Rails is usually called an MVC framework, its data flow differs from the original one – Controller is responsible for updating View, and View can easily access and even modify Model.

The controller layer’s responsibility is to translate web requests into business actions or operations and trigger UI updates. This is an example of single responsibility, which consists of many smaller responsibilities – an actor (a user or an API client) authentication and authorization, requesting parameters validation, and so on. The same is true for every inbound abstraction layer, such as Action Cable channels or Action Mailbox mailboxes.

Coming back to the routing example and the redirects question, we can now answer it – since there is no business action behind the redirection logic, putting it into a controller is an abstraction misuse.

We will talk about controllers in detail in the following chapters.

Now, we have an idea of a click’s journey through a Rails application. However, not everything in Rails happens within a request-response cycle; our click has likely triggered some actions to be executed in the background.

Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Understand Rails' architectural patterns along with its advantages and disadvantages
  • Organize business logic in Rails apps when the default approach is insufficient
  • Introduce new abstractions to address design problems
  • Purchase of the print or Kindle book includes a free PDF eBook

Description

The Ruby on Rails framework boosts productivity by leveraging the convention-over-configuration principle and model-view-controller (MVC) pattern, enabling developers to build features efficiently. This initial simplicity often leads to complexity, making a well-structured codebase difficult to maintain. Written by a seasoned software engineer and award-winning contributor to many other open-source projects, including Ruby on Rails and Ruby, this book will help you keep your code maintainable while working on a Rails app. You’ll get to grips with the framework’s capabilities and principles to harness the full potential of Rails, and tackle many common design problems by discovering useful patterns and abstraction layers. By implementing abstraction and dividing the application into manageable modules, you’ll be able to concentrate on specific parts of the app development without getting overwhelmed by the entire codebase. This also encourages code reuse, simplifying the process of adding new features and enhancing the application's capabilities. Additionally, you’ll explore further steps in scaling Rails codebase, such as service extractions. By the end of this book, you’ll become a code design specialist with a deep understanding of the Rails framework principles.

Who is this book for?

This book is for Rails application developers looking to efficiently manage the growing complexity of their projects. Whether you've recently launched your first Rails minimum viable product or are struggling to progress with a sizable monolithic application, this book is here to help. A deep understanding of core Rails principles is a must. Prior experience in building web apps using the Rails framework will help you understand and apply the concepts in the book in a better way.

What you will learn

  • Get to grips with Rails' core components and its request/response cycle
  • See how Rails' convention-over-configuration principle affects development
  • Explore patterns for software flexibility, extensibility, and testability in Rails
  • Identify and address Rails' anti-patterns for cleaner code
  • Implement design patterns for handling bloated models and messy views
  • Expand from mailers to multi-channel notification deliveries
  • Introduce different authorization models and layers to your codebase
  • Take a class-based approach to configuration in Rails

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Aug 30, 2023
Length: 298 pages
Edition : 1st
Language : English
ISBN-13 : 9781801813785
Category :
Languages :

What do you get with a Packt Subscription?

Free for first 7 days. ₹800 p/m after that. Cancel any time!
Product feature icon Unlimited ad-free access to the largest independent learning library in tech. Access this title and thousands more!
Product feature icon 50+ new titles added per month, including many first-to-market concepts and exclusive early access to books as they are being written.
Product feature icon Innovative learning tools, including AI book assistants, code context explainers, and text-to-speech.
Product feature icon Thousands of reference materials covering every tech concept you need to stay up to date.
Subscribe now
View plans & pricing

Product Details

Publication date : Aug 30, 2023
Length: 298 pages
Edition : 1st
Language : English
ISBN-13 : 9781801813785
Category :
Languages :

Packt Subscriptions

See our plans and pricing
Modal Close icon
₹800 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
₹4500 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just ₹400 each
Feature tick icon Exclusive print discounts
₹5000 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just ₹400 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total 11,172.97
Polished Ruby Programming
₹4096.99
Layered Design for Ruby on Rails Applications
₹3723.99
React 18 Design Patterns and Best Practices
₹3351.99
Total 11,172.97 Stars icon

Table of Contents

19 Chapters
Part 1: Exploring Rails and Its Abstractions Chevron down icon Chevron up icon
Chapter 1: Rails as a Web Application Framework Chevron down icon Chevron up icon
Chapter 2: Active Models and Records Chevron down icon Chevron up icon
Chapter 3: More Adapters, Less Implementations Chevron down icon Chevron up icon
Chapter 4: Rails Anti-Patterns? Chevron down icon Chevron up icon
Chapter 5: When Rails Abstractions Are Not Enough Chevron down icon Chevron up icon
Part 2: Extracting Layers from Models Chevron down icon Chevron up icon
Chapter 6: Data Layer Abstractions Chevron down icon Chevron up icon
Chapter 7: Handling User Input outside of Models Chevron down icon Chevron up icon
Chapter 8: Pulling Out the Representation Layer Chevron down icon Chevron up icon
Part 3: Essential Layers for Rails Applications Chevron down icon Chevron up icon
Chapter 9: Authorization Models and Layers Chevron down icon Chevron up icon
Chapter 10: Crafting the Notifications Layer Chevron down icon Chevron up icon
Chapter 11: Better Abstractions for HTML Views Chevron down icon Chevron up icon
Chapter 12: Configuration as a First-Class Application Citizen Chevron down icon Chevron up icon
Chapter 13: Cross-Layers and Off-Layers Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon
Gems and Patterns Chevron down icon Chevron up icon
Other Books You May Enjoy Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Full star icon Full star icon Full star icon Full star icon Half star icon 4.7
(16 Ratings)
5 star 87.5%
4 star 6.3%
3 star 0%
2 star 0%
1 star 6.3%
Filter icon Filter
Top Reviews

Filter reviews by




Simon Bennett Jul 29, 2024
Full star icon Full star icon Full star icon Full star icon Full star icon 5
Feefo Verified review Feefo
Mike Goggin Sep 12, 2023
Full star icon Full star icon Full star icon Full star icon Full star icon 5
This book is mostly geared towards intermediate to senior-level Rails engineers, but more junior-level folks can still benefit from the information contained therein.The first several chapters are an overview of how Rails works which are essential for any engineer who wants to get the most out of Rails. The rest of the book are a collection of different design patterns that someone could employ to make an existing application easy to reason about.I wouldn't recommend starting with these advanced design patterns or else you run the risk of over-engineering and introducing too much complexity unnecessarily, but if you've got an existing app that's starting to look a little crufty, these patterns can help you to abstract away the cruft in more convention-y way.The content of the book is great. It's easy to read and follow. A bit dry at times (but what technical resource isn't dry?).
Amazon Verified review Amazon
Jeremy Smith Aug 31, 2023
Full star icon Full star icon Full star icon Full star icon Full star icon 5
I loved this book, and found it very timely given the many questions and opinions I've seen in the community over the past couple years, about how to grow Rails applications beyond what the framework gives you out-of-the-box.As an overarching concept, Vladimir lays out a compelling vision for an "Extended Rails Way" that first guides us on how to use the baked-in abstractions well, and then helps us imagine how we could extract new abstraction layers that really feel like they could be Rails.The book helped me see how I could turn design patterns into new, cohesive abstractions that rhyme with Rails, creating more harmonious codebases with reduced cognitive burden.Vladimir provides clear perspective and helpful recommendations around some of Rails' most contentious features, including callbacks and concerns.Throughout the book, there's a repeated pattern of showing less-than-ideal examples, and then reasoning our way into one or more improved solutions. I found observing his thinking here to be really informative and helpful.I was impressed by how comprehensive the book is, covering all the topics you'd expect, like Active Record and Active Storage, plus those you might not expect, like filter objects, notifications, view components, and even configuration and logging.Long story short, this is now one of two Rails books I'll be recommending that all Rails devs read.
Amazon Verified review Amazon
Niharika Oct 11, 2023
Full star icon Full star icon Full star icon Full star icon Full star icon 5
This Ruby on Rails ebook is a fantastic resource for mid-level developers with a foundational understanding of Ruby and Rails. It delves deep into essential topics like anti-patterns, the Rails framework, abstraction, and authorization. The explanations are clear and practical, making it easy to grasp complex concepts. With real-world examples and hands-on guidance, this book empowers developers to take their skills to the next level, helping them build more efficient and secure applications. If you're looking to strengthen your expertise in Ruby on Rails, this ebook is a valuable companion on your journey toward becoming a more proficient developer.
Amazon Verified review Amazon
Brittany J. Martin Aug 30, 2023
Full star icon Full star icon Full star icon Full star icon Full star icon 5
I've been a huge fan of Vladimir's content from his conference talks and from his work at Evil Martians. "Layered Design for Ruby on Rails Applications" is a game-changer for Rails developers. With clear explanations and practical examples, it takes you from the basics of layered architecture to advanced implementation. The hands-on approach, code snippets, and best practices make it incredibly valuable. Not just theory, it tackles real-world challenges and provides insights into refactoring. This book not only teaches layered design but also transforms how you approach clean and maintainable code. For anyone serious about enhancing their Ruby on Rails skills, this book is an indispensable resource.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is included in a Packt subscription? Chevron down icon Chevron up icon

A subscription provides you with full access to view all Packt and licnesed content online, this includes exclusive access to Early Access titles. Depending on the tier chosen you can also earn credits and discounts to use for owning content

How can I cancel my subscription? Chevron down icon Chevron up icon

To cancel your subscription with us simply go to the account page - found in the top right of the page or at https://subscription.packtpub.com/my-account/subscription - From here you will see the ‘cancel subscription’ button in the grey box with your subscription information in.

What are credits? Chevron down icon Chevron up icon

Credits can be earned from reading 40 section of any title within the payment cycle - a month starting from the day of subscription payment. You also earn a Credit every month if you subscribe to our annual or 18 month plans. Credits can be used to buy books DRM free, the same way that you would pay for a book. Your credits can be found in the subscription homepage - subscription.packtpub.com - clicking on ‘the my’ library dropdown and selecting ‘credits’.

What happens if an Early Access Course is cancelled? Chevron down icon Chevron up icon

Projects are rarely cancelled, but sometimes it's unavoidable. If an Early Access course is cancelled or excessively delayed, you can exchange your purchase for another course. For further details, please contact us here.

Where can I send feedback about an Early Access title? Chevron down icon Chevron up icon

If you have any feedback about the product you're reading, or Early Access in general, then please fill out a contact form here and we'll make sure the feedback gets to the right team. 

Can I download the code files for Early Access titles? Chevron down icon Chevron up icon

We try to ensure that all books in Early Access have code available to use, download, and fork on GitHub. This helps us be more agile in the development of the book, and helps keep the often changing code base of new versions and new technologies as up to date as possible. Unfortunately, however, there will be rare cases when it is not possible for us to have downloadable code samples available until publication.

When we publish the book, the code files will also be available to download from the Packt website.

How accurate is the publication date? Chevron down icon Chevron up icon

The publication date is as accurate as we can be at any point in the project. Unfortunately, delays can happen. Often those delays are out of our control, such as changes to the technology code base or delays in the tech release. We do our best to give you an accurate estimate of the publication date at any given time, and as more chapters are delivered, the more accurate the delivery date will become.

How will I know when new chapters are ready? Chevron down icon Chevron up icon

We'll let you know every time there has been an update to a course that you've bought in Early Access. You'll get an email to let you know there has been a new chapter, or a change to a previous chapter. The new chapters are automatically added to your account, so you can also check back there any time you're ready and download or read them online.

I am a Packt subscriber, do I get Early Access? Chevron down icon Chevron up icon

Yes, all Early Access content is fully available through your subscription. You will need to have a paid for or active trial subscription in order to access all titles.

How is Early Access delivered? Chevron down icon Chevron up icon

Early Access is currently only available as a PDF or through our online reader. As we make changes or add new chapters, the files in your Packt account will be updated so you can download them again or view them online immediately.

How do I buy Early Access content? Chevron down icon Chevron up icon

Early Access is a way of us getting our content to you quicker, but the method of buying the Early Access course is still the same. Just find the course you want to buy, go through the check-out steps, and you’ll get a confirmation email from us with information and a link to the relevant Early Access courses.

What is Early Access? Chevron down icon Chevron up icon

Keeping up to date with the latest technology is difficult; new versions, new frameworks, new techniques. This feature gives you a head-start to our content, as it's being created. With Early Access you'll receive each chapter as it's written, and get regular updates throughout the product's development, as well as the final course as soon as it's ready.We created Early Access as a means of giving you the information you need, as soon as it's available. As we go through the process of developing a course, 99% of it can be ready but we can't publish until that last 1% falls in to place. Early Access helps to unlock the potential of our content early, to help you start your learning when you need it most. You not only get access to every chapter as it's delivered, edited, and updated, but you'll also get the finalized, DRM-free product to download in any format you want when it's published. As a member of Packt, you'll also be eligible for our exclusive offers, including a free course every day, and discounts on new and popular titles.