DEV Community: Harsh patel

Introducing the new Community Dashboard on TailView.work

Harsh patel — Sun, 09 Nov 2025 11:55:03 +0000

We just shipped a brand‑new Community Dashboard on TailView.work—purpose‑built for Rails developers who want a fast, modern, and accessible social surface without pulling in a front‑end megaframework. It’s powered by Tailwind CSS, Hotwire (Turbo + Stimulus), and real‑time updates via ActionCable.

TL;DR

Built with Rails 7+, Tailwind, Turbo, Stimulus, and ActionCable
Real‑time feed: new posts appear instantly without page refresh
Clean, focused UI with native <dialog> and <details> for accessibility
Thoughtful UX: keyboard‑first, high‑contrast states, reduced JS complexity
Production‑ready patterns you can copy into your app

Why this dashboard?

Rails teams told us they needed:

A real‑time, low‑friction place to share what they’re shipping
Zero‑build, no‑webpack front‑end they can actually maintain
An interface that feels modern but stays accessible and fast

So we designed a dashboard that feels native to Rails: no client‑side routing, no hydration ceremony—just HTML over the wire and subtle animation where it helps.

What’s new

Real‑time feed
- New discussions prepend instantly via Turbo Streams
- Lightweight “highlight on arrival” animation for context
Smart filtering & topics
- Filter by latest activity, most appreciated, most discussed, or relevance
- Topic browsing with native <details> for predictable keyboard behavior
Composer that doesn’t fight you
- Native <dialog> for the modal, so ESC, focus trapping, and backdrop “just work”
- Clear copy and labels; field states and errors are visible and friendly
Presence panel
- See who’s currently active—live, with gentle motion and minimal noise

UI/UX decisions that matter

Use the platform: native <dialog> and <details> replace heavy JS and improve accessibility out of the box.
Motion with meaning: we highlight just‑arrived items and keep transitions short and subtle.
High‑signal affordances: “Share”, “New discussion”, and filters are prominent; destructive actions are de‑emphasized.
Mobile‑sane by default: chips for topics, condensed headers, and large tap targets.

The stack (and why)

Tailwind CSS: utility‑first, consistent spacing/typography, tokens you can reason about.
Turbo Streams: real‑time, server‑rendered HTML—no client state to sync.
Stimulus: sprinkle‑sized behavior; controllers are tiny and composable.
ActionCable: stable, framework‑native websockets.

A few patterns you can reuse

Render and stream updates (server → clients):

# app/services/community/feed_broadcaster.rb
Turbo::StreamsChannel.broadcast_prepend_to(
  "community_feed",
  target: "community_discussions",
  partial: "community/discussion",
  locals: { discussion: discussion, highlight: true }
)

Turbo Streams subscription in your view:

<%= turbo_stream_from "community_feed" %>
<ul id="community_discussions">
  <%= render partial: "community/discussion", collection: @discussions %>
</ul>

A tiny Stimulus controller for “copy share link”:

// app/javascript/controllers/share_link_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static targets = ["tooltip"]
  static values = { url: String, timeout: Number }

  copy(e) {
    e.preventDefault()
    navigator.clipboard?.writeText(this.urlValue)
      .then(() => this.show())
      .catch(() => this.fallback())
  }

  fallback() {
    const ta = document.createElement("textarea")
    ta.value = this.urlValue
    ta.style.position = "fixed"; ta.style.left = "-9999px"
    document.body.appendChild(ta); ta.select()
    document.execCommand("copy"); document.body.removeChild(ta)
    this.show()
  }

  show() {
    this.tooltipTarget.classList.remove("opacity-0")
    this.tooltipTarget.classList.add("opacity-100")
    clearTimeout(this.t); this.t = setTimeout(() => {
      this.tooltipTarget.classList.add("opacity-0")
      this.tooltipTarget.classList.remove("opacity-100")
    }, this.timeoutValue || 2000)
  }
}

Composer with a native dialog:

<dialog data-controller="community-composer-modal"
        data-community-composer-modal-target="dialog"
        class="fixed inset-0 m-auto h-fit w-full max-w-3xl rounded-3xl bg-white p-0 shadow-2xl backdrop:bg-gray-900/70">
  <%= render "community/composer", communities: @communities, topic: @topic %>
</dialog>

Try it, copy it, ship it

The Community Dashboard is live on TailView.work. If you’re building Rails apps with Tailwind and Hotwire, you can lift the patterns directly: streams for real‑time UI, native HTML for modals/accordions, and Stimulus for tiny, testable interactions.

Questions or suggestions? Start a discussion on the new dashboard and show us what you’re shipping.

TailView UI: Open-Source Rails Components with Hotwire Magic 🚀

Harsh patel — Tue, 04 Nov 2025 03:51:59 +0000

TailView UI: Building Beautiful Rails Apps Without the JavaScript Fatigue

TL;DR

I built TailView UI - an open-source collection of 20+ production-ready UI components for Rails developers. It's built with Rails 8, Hotwire (Stimulus + Turbo), and Tailwind CSS. No React, no Vue, just pure Rails magic. Copy, paste, and ship beautiful UIs faster.

The Problem: Rails Developers Deserve Better UI Tools

As Rails developers, we've all been there:

Spending hours recreating the same buttons, modals, and forms
Fighting with React/Vue just to add a dropdown menu
Googling "Rails modal with Stimulus" for the 10th time
Copying half-baked examples from Stack Overflow that barely work

Meanwhile, the React ecosystem has dozens of component libraries. But what about us Rails developers who believe in the power of server-rendered HTML and progressive enhancement?

Enter TailView UI: Components Built the Rails Way

After months of building the same components repeatedly across different projects, I decided to create something for the Rails community. TailView UI is what I wished existed when I started my Rails journey.

What Makes TailView Different?

# Traditional approach
- Install React/Vue
- Setup Webpack
- Configure build pipeline
- Learn new syntax
- Debug state management
- 😭

# TailView approach
- Copy component code
- Paste into your Rails app
- It just works™
- 🎉

🛠️ The Tech Stack: Modern Rails at Its Best

Rails 8.0.2

Using the latest Rails features including:

ViewComponent for encapsulated, testable components
Built-in Stimulus for interactivity
Turbo for SPA-like navigation without the complexity

Hotwire (The Secret Sauce)

36 Stimulus controllers for rich interactions
Turbo Frames & Streams for seamless updates
Zero JavaScript frameworks needed

Tailwind CSS

Utility-first styling
Responsive by default
Dark mode ready (coming soon!)

📦 What's Inside: 20+ Production-Ready Components

Layout Components

Navigation bars - Responsive with mobile menu
Sidebars - Collapsible with state persistence
Breadcrumbs - Dynamic with Turbo support
Cards - Multiple variants and styles

Interactive Components

<!-- Example: Modal with Stimulus -->
<div data-controller="modal">
  <button data-action="click->modal#open">
    Open Modal
  </button>

  <div data-modal-target="container" class="hidden">
    <!-- Your modal content -->
  </div>
</div>

Modals - Accessible with keyboard support
Drawers - Slide-in panels from any direction
Popovers - Smart positioning with Popper.js alternative
Tooltips - Hover/focus triggered
Dropdowns - Click-outside detection

Forms & Inputs

Form validations - Real-time with Stimulus
Datepickers - No jQuery required!
Select boxes - Searchable with Stimulus
File uploads - Drag & drop with preview
Toggle switches - Accessible and animated

Data Display

# Clean, reusable table components
<%= render TableComponent.new(
  headers: ['Name', 'Email', 'Status'],
  rows: @users,
  sortable: true,
  filterable: true
) %>

Tables - Sortable, filterable, paginated
Charts - SVG-based, no Chart.js needed
Progress bars - Animated with Stimulus
Badges - Status indicators
Alerts - Dismissible with animations

Feedback Components

Toasts - Stack-able notifications
Loading states - Skeleton screens
Empty states - Beautiful placeholders
Error pages - Customizable 404/500

🚀 Hotwire Magic: The Power of Stimulus

One of the coolest parts of TailView is how we leverage Stimulus for interactivity. Here's a real example from the star rating component:

// app/javascript/controllers/rating_controller.js
import { Controller } from "@hotwired/stimulus"

export default class extends Controller {
  static targets = ["star"]
  static values = { rating: Number }

  connect() {
    this.updateStars()
  }

  select(event) {
    this.ratingValue = parseInt(event.currentTarget.dataset.value)
    this.updateStars()
    this.dispatch("rated", { detail: { rating: this.ratingValue } })
  }

  hover(event) {
    const rating = parseInt(event.currentTarget.dataset.value)
    this.highlightStars(rating)
  }

  reset() {
    this.updateStars()
  }

  updateStars() {
    this.starTargets.forEach((star, index) => {
      star.classList.toggle("filled", index < this.ratingValue)
    })
  }

  highlightStars(rating) {
    this.starTargets.forEach((star, index) => {
      star.classList.toggle("hover", index < rating)
    })
  }
}

This gives you a fully interactive star rating component with:

Click to rate
Hover preview
Keyboard navigation
Custom events for Rails integration

📊 Performance Benefits: Why Monoliths Win

Let's talk numbers. Here's what TailView achieves compared to a typical React SPA:

Metric	React SPA	TailView (Rails + Hotwire)	Improvement
Initial Bundle Size	350kb+	45kb	87% smaller
Time to Interactive	3.2s	0.8s	75% faster
Memory Usage	50MB+	12MB	76% less
Build Time	45s	3s	93% faster
Dependencies	1000+	<50	95% fewer

🎨 Accessibility & Best Practices

Every component in TailView follows:

WCAG 2.1 AA compliance - Keyboard navigation, screen reader support
Semantic HTML - Proper heading hierarchy, ARIA labels
Progressive enhancement - Works without JavaScript
Mobile-first responsive - Looks great on all devices

<!-- Example: Accessible Modal -->
<div role="dialog" 
     aria-modal="true"
     aria-labelledby="modal-title"
     data-controller="modal">
  <h2 id="modal-title">Modal Title</h2>
  <!-- Keyboard trap, focus management included -->
</div>

🚦 Getting Started: It's Ridiculously Simple

1. Visit TailView

Go to tailview.work

2. Browse Components

Find the component you need from our collection

3. Copy the Code

Each component shows the complete implementation:

HTML/ERB markup
Stimulus controller (if needed)
Tailwind classes

4. Paste & Customize

Drop it into your Rails app and customize the styling

That's it! No npm install, no configuration, no build step.

🤝 Contributing: Join the Rails Renaissance

TailView is open-source and needs YOUR help to grow! Here's how you can contribute:

Report Issues

Found a bug? Accessibility issue? Let us know!

Submit Components

Built a cool component with Hotwire? Share it with the community!

Improve Documentation

Help other developers by improving examples and guides

Spread the Word

Star the repo, share with your team, write about your experience

💭 Lessons Learned Building TailView

1. Hotwire is Production-Ready

After building 36 Stimulus controllers and dozens of Turbo interactions, I can confidently say Hotwire can replace 90% of React use cases.

2. Simplicity Scales

Our most complex component (data table with sorting, filtering, and pagination) is just 150 lines of Ruby and 50 lines of JavaScript. Try doing that with React!

3. The Rails Community is Amazing

The feedback and contributions from the Rails community have been incredible. This is why I'm making TailView open-source.

Get Started Today

👉 Visit: tailview.work
👉 GitHub: Tailview Github

Let's Connect!

Have questions? Want to contribute? Building something cool with TailView?

Drop a comment below 👇
Open an issue on GitHub

FAQ

Q: Is TailView really free?
A: Yes! The core components will always be open-source and free. Premium themes may be added in the future.

Q: Do I need to know Stimulus?
A: Not at all! Components work out of the box. The Stimulus code is there if you want to customize.

Q: Works with Rails 6/7?
A: Yes! While built with Rails 8, components work with Rails 6.1+ (with Hotwire installed).

Q: Can I use without Tailwind?
A: The components use Tailwind classes, but you can extract the styles to regular CSS if needed.

Q: How do I request a component?
A: Open an issue on GitHub or comment below with your component ideas!

If you found this helpful, please ❤️ and 🦄 this post! Let's make Rails UI development fun again!

#rails #rubyonrails #hotwire #stimulus #turbo #tailwindcss #opensource #webdev #ui #components

Modern Rails Rendering Techniques: Choosing Between Turbo Drive, Frames, Streams and Morph

Harsh patel — Tue, 13 May 2025 10:49:19 +0000

In the evolving landscape of Ruby on Rails development, creating responsive, dynamic user interfaces without heavy JavaScript frameworks has become increasingly accessible. With the introduction of Hotwire (HTML Over The Wire) and subsequent innovations like Turbo Drive, Frames, Streams, and the newer Turbo Morph, developers now have multiple options for building interactive applications.

But which technique should you choose for your project? When should you use one over another? This guide will help you navigate these choices with practical examples.

Understanding the Fundamentals
Turbo Drive: The Foundation
Turbo Frames: Targeted Updates
Turbo Streams: Real-time Updates
Turbo Morph: Fine-grained DOM Updates
Decision Framework: When to Use What
Real-world Example: Building a Comment System
Performance Considerations
Interactive Tutorial

Understanding the Fundamentals

Before diving into specific techniques, let's understand the core philosophy: all these approaches aim to make web applications feel faster and more responsive by avoiding full page refreshes while keeping the development model server-centric.

Turbo Drive: The Foundation

What it is: Turbo Drive (formerly Turbolinks) accelerates navigation by converting traditional link clicks and form submissions into AJAX requests, replacing only the <body> of the page and merging the <head>.

When to use Turbo Drive:

For traditional multi-page applications where you want improved navigation speed
When you need minimal changes to existing code
As a foundation for other Turbo features

Example:

# No special code needed! Turbo Drive works automatically with:
<%= link_to "View Product", product_path(@product) %>

# For forms:
<%= form_with model: @product do |form| %>
  <%= form.text_field :name %>
  <%= form.submit %>
<% end %>

With Turbo Drive, these standard Rails elements now deliver a smoother user experience without writing any JavaScript.

Live Demo:

Try clicking navigation links in this application - notice how the page transitions feel instant and there's no full page refresh.

Turbo Frames: Targeted Updates

What it is: Turbo Frames allow you to define independent sections of your page that can be updated independently of the rest of the content.

When to use Turbo Frames:

When you need to update a specific section of the page
For creating reusable components that load their own content
To implement master-detail interfaces
For forms that shouldn't navigate away from the current page

Example:

<%# app/views/products/index.html.erb %>
<h1>Products</h1>

<%= turbo_frame_tag "product_list" do %>
  <div class="products">
    <%= render @products %>
  </div>
<% end %>

<%= turbo_frame_tag "product_detail" %>

<%# app/views/products/_product.html.erb %>
<div class="product">
  <%= link_to product.name, product, data: { turbo_frame: "product_detail" } %>
</div>

<%# app/views/products/show.html.erb %>
<%= turbo_frame_tag "product_detail" do %>
  <div class="product-detail">
    <h2><%= @product.name %></h2>
    <p><%= @product.description %></p>
    <p>Price: $<%= @product.price %></p>
  </div>
<% end %>

Live Demo:

Click on a product in the list, and only the detail panel updates, creating a smooth, app-like experience.

Turbo Streams: Real-time Updates

What it is: Turbo Streams allow the server to send HTML fragments that can add, replace, update, or remove elements on the page, often used with ActionCable for real-time updates.

When to use Turbo Streams:

For real-time features like chat, notifications, or collaborative editing
When you need to update multiple parts of the page simultaneously
For optimistic UI updates with form submissions

Example:

# app/controllers/comments_controller.rb
def create
  @comment = @post.comments.create!(comment_params)

  respond_to do |format|
    format.html { redirect_to @post }
    format.turbo_stream
  end
end

<%# app/views/comments/create.turbo_stream.erb %>
<turbo-stream action="append" target="comments">
  <%= render partial: "comments/comment", locals: { comment: @comment } %>
</turbo-stream>

<turbo-stream action="update" target="new_comment">
  <%= render partial: "comments/form", locals: { post: @post, comment: Comment.new } %>
</turbo-stream>

For real-time updates via ActionCable:

# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post

  after_create_commit -> { broadcast_append_to post }
end

<%# app/views/posts/show.html.erb %>
<%= turbo_stream_from @post %>

<div id="comments">
  <%= render @post.comments %>
</div>

Live Demo:

Try adding a comment below. Notice how it appears instantly without a page refresh, and if another user adds a comment, it will appear in real-time.

Turbo Morph: Fine-grained DOM Updates

What it is: The newest addition to the Turbo family, Turbo Morph provides more efficient DOM updates by diffing the current and new HTML to apply only the necessary changes.

When to use Turbo Morph:

For complex UI updates where standard Turbo frames or streams might be inefficient
When preserving UI state during updates is critical
For optimized rendering of large lists or complex components

Example:

<%# app/views/dashboard/show.html.erb %>
<%= turbo_frame_tag "dashboard", morph: true do %>
  <div class="dashboard">
    <div class="metrics">
      <%= render "metrics", data: @metrics %>
    </div>
    <div class="recent-activity">
      <%= render "activities", activities: @activities %>
    </div>
  </div>
<% end %>

<%= link_to "Refresh", dashboard_path, data: { turbo_frame: "dashboard" } %>

In your controller:

# app/controllers/dashboard_controller.rb
def show
  @metrics = current_user.metrics
  @activities = current_user.recent_activities(25)
end

Live Demo:

Click the "Refresh" button to update the dashboard. Notice how elements maintain their state (like scroll position or form inputs) even as the content changes.

Decision Framework: When to Use What

Here's a simple decision framework for choosing the right technique:

Start with Turbo Drive as your baseline - it works automatically and improves navigation
Use Turbo Frames when:
- You need to update only a specific part of the page
- You want to create master-detail interfaces
- You're building isolated components
Use Turbo Streams when:
- You need real-time updates
- You're updating multiple parts of the page at once
- You're handling form submissions with complex responses
Consider Turbo Morph when:
- You're updating complex UI with many elements
- You need to preserve DOM state during updates
- You're working with large lists or tables

Real-world Example: Building a Comment System

Let's see how these technologies work together in a real-world example: a blog post with comments.

<%# app/views/posts/show.html.erb %>
<article class="post">
  <h1><%= @post.title %></h1>
  <div class="content">
    <%= @post.content %>
  </div>

  <h2>Comments (<span id="comment-count"><%= @post.comments.count %></span>)</h2>

  <%= turbo_stream_from @post, :comments %>

  <div id="comments" class="comments">
    <%= render @post.comments %>
  </div>

  <%= turbo_frame_tag "new_comment" do %>
    <%= render "comments/form", post: @post, comment: Comment.new %>
  <% end %>
</article>

<%# app/views/comments/_form.html.erb %>
<%= form_with model: [post, comment], data: { controller: "reset-form" } do |form| %>
  <%= form.text_area :content, placeholder: "Add a comment..." %>
  <%= form.submit "Post" %>
<% end %>

# app/controllers/comments_controller.rb
class CommentsController < ApplicationController
  before_action :set_post

  def create
    @comment = @post.comments.build(comment_params)
    @comment.user = current_user

    respond_to do |format|
      if @comment.save
        format.turbo_stream
      else
        format.turbo_stream { 
          render turbo_stream: turbo_stream.replace(
            "new_comment", 
            partial: "comments/form", 
            locals: { post: @post, comment: @comment }
          )
        }
      end
    end
  end

  private

  def set_post
    @post = Post.find(params[:post_id])
  end

  def comment_params
    params.require(:comment).permit(:content)
  end
end

<%# app/views/comments/create.turbo_stream.erb %>
<turbo-stream action="append" target="comments">
  <%= render "comments/comment", comment: @comment %>
</turbo-stream>

<turbo-stream action="update" target="comment-count">
  <%= @post.comments.count %>
</turbo-stream>

<turbo-stream action="replace" target="new_comment">
  <%= render "comments/form", post: @post, comment: Comment.new %>
</turbo-stream>

# app/models/comment.rb
class Comment < ApplicationRecord
  belongs_to :post
  belongs_to :user

  broadcasts_to ->(comment) { [comment.post, :comments] }, inserts_by: :append
end

In this example:

Turbo Drive handles navigation to the post page
Turbo Frame manages the comment form submission
Turbo Streams handle real-time updates when new comments are added
The comment count updates in real-time

Performance Considerations

While these tools make building interactive applications easier, there are some performance considerations:

Server Load: More frequent updates mean more server requests. Consider caching and pagination for high-traffic features.
DOM Size: Large pages with many Turbo Frames can become memory-intensive. Use Turbo Morph for more efficient updates on complex pages.
WebSocket Connections: For Turbo Streams with ActionCable, be mindful of connection limits in production environments.
Progressive Enhancement: Always ensure your application works without JavaScript as a fallback.

Interactive Tutorial

Let's build a simple task manager to see these techniques in action:

Create a new Rails application:

rails new taskmanager --css=tailwind
cd taskmanager
rails g scaffold Task name:string description:text completed:boolean
rails db:migrate

Update your routes:

# config/routes.rb
Rails.application.routes.draw do
  resources :tasks do
    member do
      patch :toggle
    end
  end
  root "tasks#index"
end

Update the controller:

# app/controllers/tasks_controller.rb
def toggle
  @task = Task.find(params[:id])
  @task.update(completed: !@task.completed)

  respond_to do |format|
    format.html { redirect_to tasks_path }
    format.turbo_stream
  end
end

Create the toggle view:

<%# app/views/tasks/toggle.turbo_stream.erb %>
<turbo-stream action="replace" target="<%= dom_id(@task) %>">
  <%= render partial: "task", locals: { task: @task } %>
</turbo-stream>

<turbo-stream action="update" target="task-count">
  <%= Task.count %> tasks, <%= Task.where(completed: true).count %> completed
</turbo-stream>

Update the task partial:

<%# app/views/tasks/_task.html.erb %>
<%= turbo_frame_tag dom_id(task) do %>
  <div class="task <%= task.completed? ? 'completed' : '' %>">
    <div class="flex items-center p-4 border-b">
      <%= link_to toggle_task_path(task), 
                  data: { turbo_method: :patch },
                  class: "mr-2" do %>
        <div class="w-6 h-6 border-2 rounded-full flex items-center justify-center <%= task.completed? ? 'bg-green-500 border-green-600' : 'border-gray-400' %>">
          <% if task.completed? %>
            <svg xmlns="http://www.w3.org/2000/svg" class="h-4 w-4 text-white" fill="none" viewBox="0 0 24 24" stroke="currentColor">
              <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="M5 13l4 4L19 7" />
            </svg>
          <% end %>
        </div>
      <% end %>

      <div class="<%= task.completed? ? 'line-through text-gray-500' : '' %>">
        <h3 class="font-medium"><%= task.name %></h3>
        <p class="text-sm text-gray-600"><%= task.description %></p>
      </div>

      <div class="ml-auto">
        <%= link_to "Edit", edit_task_path(task), class: "text-blue-500" %>
      </div>
    </div>
  </div>
<% end %>

Update the index view:

<%# app/views/tasks/index.html.erb %>
<div class="container mx-auto p-4">
  <h1 class="text-2xl font-bold mb-4">Task Manager</h1>

  <div id="task-count" class="mb-4">
    <%= Task.count %> tasks, <%= Task.where(completed: true).count %> completed
  </div>

  <div id="tasks">
    <%= render @tasks %>
  </div>

  <%= turbo_frame_tag "new_task", src: new_task_path, loading: "lazy" %>

  <div class="mt-4">
    <%= link_to "New Task", new_task_path, class: "px-4 py-2 bg-blue-500 text-white rounded", data: { turbo_frame: "new_task" } %>
  </div>
</div>

Update the new task form:

<%# app/views/tasks/new.html.erb %>
<%= turbo_frame_tag "new_task" do %>
  <div class="bg-gray-100 p-4 rounded mb-4">
    <h2 class="text-xl font-semibold mb-2">New Task</h2>
    <%= render "form", task: @task %>

    <div class="mt-2">
      <%= link_to "Cancel", "#", class: "text-gray-500", data: { 
        controller: "turbo",
        action: "click->turbo#frameRemove" 
      } %>
    </div>
  </div>
<% end %>

In this interactive example:

Turbo Drive handles navigation
Turbo Frames manage the task toggling and the new task form
Turbo Streams update the task count in real-time

Conclusion

The modern Rails stack gives developers powerful tools to create dynamic, responsive applications without relying on heavy JavaScript frameworks. By understanding when to use Turbo Drive, Frames, Streams, and Morph, you can build highly interactive experiences while maintaining the simplicity and productivity that makes Rails great.

Remember these key takeaways:

Start simple with Turbo Drive, then add complexity as needed
Choose the right tool for each interactive element in your application
Combine techniques for the best user experience
Consider performance implications for high-traffic applications

With these tools in your arsenal, you can build modern, responsive web applications that feel fast and reactive while maintaining the Rails philosophy of server-rendered HTML-first development.

What are you building with these techniques? Share your projects and challenges in the comments below!

Essential Security Best Practices for Ruby on Rails

Harsh patel — Tue, 25 Feb 2025 13:46:25 +0000

By Harsh Patel, Cyber security Enthusiast & Senior Ruby on Rails Dev

Ruby on Rails has empowered countless developers to build web applications rapidly and elegantly. However, with great power comes great responsibility. In today’s threat landscape, securing your Rails application isn’t optional—it’s an absolute necessity. In this comprehensive guide, I’ll walk you through essential security best practices that every Rails developer, from intermediate to advanced, should understand and implement immediately to protect their applications against common vulnerabilities and emerging threats.

Introduction and Context
Key Security Best Practices in Ruby on Rails
1. Protection Against SQL Injection
2. Mitigation of Cross-Site Scripting (XSS)
3. Secure Management of Secrets, Credentials, and Sensitive Configuration Data
4. Proper Session Management and Secure Cookies
5. Cross-Site Request Forgery (CSRF) Protection Strategies
6. Secure File Uploads and Handling Attachments
7. Robust Authentication and Authorization
8. Continuous Security Monitoring and Auditing
Additional Gems, Libraries, and Tools
Security Best Practices Checklist
Conclusion

Introduction and Context

In the world of web development, security is a cornerstone of sustainable and trustworthy software. With Rails’ “convention over configuration” philosophy, many security features are built-in—but this does not mean you can afford to be complacent. Web applications are constantly targeted by attackers exploiting weaknesses such as:

SQL Injection: Malicious queries that manipulate your database.
Cross-Site Scripting (XSS): Injection of malicious scripts into webpages.
Session Hijacking: Stealing or manipulating session data.
Cross-Site Request Forgery (CSRF): Unauthorized commands transmitted from a user that the web application trusts.
Insecure File Uploads: Exploiting file attachments to execute arbitrary code.
Exposure of Sensitive Data: Leaking secrets and configuration details.

For a production-grade Rails application, a proactive, layered security approach is essential. The following best practices cover common vulnerabilities and provide actionable code examples and explanations that you can integrate into your projects immediately.

Key Security Best Practices in Ruby on Rails

1. Protection Against SQL Injection

Definition:

SQL Injection occurs when user input is improperly sanitized, allowing attackers to modify SQL queries. This can lead to data theft, data loss, or unauthorized administrative actions.

How Vulnerabilities Arise:

Using string interpolation to build SQL queries:

# Vulnerable code example:
name = params[:name]
@projects = Project.where("name LIKE '#{name}'")

Best Practice Implementation:

Use ActiveRecord’s parameterized queries and built-in sanitization methods to prevent SQL injection.

# Secure code example:
@projects = Project.where("name LIKE ?", "%#{ActiveRecord::Base.sanitize_sql_like(params[:name])}%")

Explanation:

Parameterized queries automatically escape dangerous characters.
sanitize_sql_like is particularly useful when using wildcards, ensuring that special SQL characters are handled safely.

2. Mitigation of Cross-Site Scripting (XSS)

Definition:

XSS vulnerabilities occur when attackers inject malicious JavaScript or HTML into your web pages, potentially stealing user data or executing unauthorized actions in the user’s browser.

How Vulnerabilities Arise:

Directly outputting user input without proper sanitization:

<!-- Vulnerable ERB template example: -->
<%= raw @product.description %>

Best Practice Implementation:

Leverage Rails’ automatic HTML escaping and use sanitization helpers when you need to allow limited HTML.

<!-- Secure ERB template example: -->
<%= @product.description %>

If you must allow HTML:

# Using sanitize helper to allow specific tags:
allowed_tags = %w[b i u p br]
@safe_content = sanitize(params[:content], tags: allowed_tags)

Explanation:

Rails auto-escapes by default to prevent XSS.
The sanitize helper can be used to whitelist safe HTML tags when user-generated content is required.

3. Secure Management of Secrets, Credentials, and Sensitive Configuration Data

Definition:

Storing sensitive information such as API keys, database credentials, and secret tokens in plaintext or source control exposes your application to severe risks.

How Vulnerabilities Arise:

Including secrets directly in configuration files:

# Bad practice: config/secrets.yml containing plain-text credentials
production:
  secret_key_base: "super_secret_key"

Best Practice Implementation:

Utilize Rails’ encrypted credentials and environment variables to store sensitive data securely.

# To edit credentials in Rails 6+:
EDITOR="vim" rails credentials:edit

Within the encrypted credentials file, store secrets securely:

# config/credentials.yml.enc (example content)
aws:
  access_key_id: your_access_key_id
  secret_access_key: your_secret_access_key
secret_key_base: your_production_secret_key

And access them in your application:

# Accessing credentials securely:
Rails.application.credentials.aws[:access_key_id]
Rails.application.credentials.secret_key_base

Explanation:

Rails encrypted credentials ensure that sensitive data remains encrypted at rest and is only accessible with the master key, which should never be committed to source control.
Environment variables and tools like dotenv-rails can further manage configuration outside your codebase.

4. Proper Session Management and Secure Cookies

Definition:

Sessions track user state across requests, but improperly managed sessions can lead to hijacking or replay attacks.

How Vulnerabilities Arise:

Using default cookie settings without security enhancements:

# Default session store (potential risk):
YourApp::Application.config.session_store :cookie_store, key: '_your_app_session'

Best Practice Implementation:

Enhance session security by using server-side session stores and setting secure cookie options.

ActiveRecord Session Store:

# In Gemfile:
gem 'activerecord-session_store'

# Generate migration and migrate:
rails generate active_record:session_migration
rails db:migrate

# Configure session store:
YourApp::Application.config.session_store :active_record_store, key: '_your_app_session'

Cookie Security Enhancements:

# config/environments/production.rb:
Rails.application.configure do
  config.force_ssl = true  # Force HTTPS
  config.session_store :cookie_store, key: '_your_app_session', secure: Rails.env.production?, httponly: true, same_site: :lax
end

Explanation:

Server-side session stores reduce exposure as session data is kept on the server.
Secure cookie flags (secure, httponly, and same_site) ensure cookies are only sent over HTTPS, not accessible via JavaScript, and provide cross-site request protections.

5. Cross-Site Request Forgery (CSRF) Protection Strategies

Definition:

CSRF attacks trick authenticated users into submitting unwanted actions on web applications without their consent.

How Vulnerabilities Arise:

An attacker may craft a malicious request that leverages a user’s authenticated session.

Best Practice Implementation:

Rails includes built-in CSRF protection. Ensure it is enabled and properly configured in your controllers.

# In ApplicationController:
class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception  # Raises an exception if CSRF token verification fails
end

Example Form with CSRF Token:

<%= form_with model: @project do |form| %>
  <%= form.label :name %>
  <%= form.text_field :name %>
  <%= form.submit "Save" %>
<% end %>

Explanation:

protect_from_forgery automatically inserts an authenticity token into forms, which Rails verifies on submission.
This built-in mechanism defends against CSRF by ensuring that form submissions originate from trusted sources.

6. Secure File Uploads and Handling Attachments

Definition:

File uploads can be exploited to execute arbitrary code if not properly validated, potentially leading to server compromise.

How Vulnerabilities Arise:

Accepting file uploads without validating file types, sizes, or scanning for malware:

# Vulnerable approach: blindly saving uploaded files
def upload
  File.open(Rails.root.join('public', 'uploads', params[:file].original_filename), 'wb') do |file|
    file.write(params[:file].read)
  end
end

Best Practice Implementation:

Use well-maintained libraries such as ActiveStorage or Shrine to handle file uploads securely.

ActiveStorage Example:

Setup ActiveStorage:

rails active_storage:install
rails db:migrate

Attach Files to Models:

class User < ApplicationRecord
  has_one_attached :avatar
end

Controller Example with Validation:

class UsersController < ApplicationController
  def update
    @user = current_user
    if params[:user][:avatar]
      # Validate file type and size here (e.g., using custom validations or ActiveStorage validations)
      @user.avatar.attach(params[:user][:avatar])
    end
    if @user.save
      redirect_to @user, notice: 'Profile updated successfully.'
    else
      render :edit
    end
  end
end

Explanation:

ActiveStorage abstracts file handling securely by storing files externally (e.g., Amazon S3, Google Cloud Storage) and providing validations.
Always validate file type and size before accepting uploads.

7. Robust Authentication and Authorization

Definition:

Ensuring that users are who they claim to be (authentication) and that they have permissions to access certain resources (authorization) is fundamental to application security.

How Vulnerabilities Arise:

Weak authentication mechanisms or misconfigured access control can lead to unauthorized access.

Best Practice Implementation:

Leverage industry-standard gems like Devise for authentication and Pundit or Cancancan for authorization.

Devise Installation and Setup:

# In Gemfile:
gem 'devise'

# Install Devise:
rails generate devise:install
rails generate devise User
rails db:migrate

Route Protection Example:

Rails.application.routes.draw do
  authenticate :user do
    resources :projects  # Only authenticated users can access these routes
  end
  devise_for :users
  root to: 'home#index'
end

Pundit for Authorization Example:

Install Pundit:

# In Gemfile:
gem 'pundit'

Include in ApplicationController:

class ApplicationController < ActionController::Base
  include Pundit
  # Rescue from unauthorized access
  rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized

  private

  def user_not_authorized
    flash[:alert] = "You are not authorized to perform this action."
    redirect_to(request.referrer || root_path)
  end
end

Define a Policy:

# app/policies/project_policy.rb
class ProjectPolicy < ApplicationPolicy
  def update?
    user.admin? || record.owner == user
  end
end

Explanation:

Devise provides secure authentication flows.
Pundit (or Cancancan) enables granular control over resource access, ensuring that users only perform actions for which they have explicit permission.

8. Continuous Security Monitoring and Auditing

Definition:

Security is not a one-time task. Continuous monitoring, auditing, and automated security testing help identify vulnerabilities early and ensure ongoing protection.

How Vulnerabilities Arise:

Without regular audits, even secure applications can accumulate vulnerabilities over time due to outdated dependencies or evolving threats.

Best Practice Implementation:

Static Analysis Tools:

Use tools like Brakeman to scan your codebase for common vulnerabilities.
Dependency Auditing:

Utilize bundler-audit to monitor for vulnerabilities in your Gemfile.lock.
Security Headers:

Use the secure_headers gem to ensure that HTTP security headers are correctly configured.

Detailed Overview: Brakeman

Brakeman is a static analysis tool designed specifically for Rails applications. It scans your source code without executing it, identifying common security vulnerabilities such as SQL injection, XSS, and unsafe mass assignment.

Installation and Usage

Install Brakeman:

gem install brakeman

Run Brakeman in your Rails project:

brakeman

This command analyzes your code and outputs a report of potential vulnerabilities.

Integrate with CI/CD: You can add Brakeman to your CI pipeline (e.g., in a GitHub Actions workflow) to ensure continuous monitoring:

# .github/workflows/security.yml
name: Security Scan

on: [push, pull_request]

jobs:
  brakeman:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.0'
      - name: Install dependencies
        run: bundle install --jobs 4 --retry 3
      - name: Run Brakeman
        run: bundle exec brakeman -q -o brakeman-report.json

Explanation:

Brakeman helps you identify vulnerabilities early in development.
Regular scans ensure that new vulnerabilities introduced by code changes are caught before deployment.

Detailed Overview: bundler-audit

bundler-audit checks your Gemfile.lock for gems with known vulnerabilities. It compares your dependencies against a database of advisories and alerts you if any are found.

Installation and Usage

Install bundler-audit:

gem install bundler-audit

Run bundler-audit in your Rails project:

bundler-audit check --update

This command will:

Update the advisory database.
Scan your Gemfile.lock for known vulnerabilities.
Print a report with recommendations on how to update or patch the affected gems.

Integrate with CI/CD: For continuous monitoring, include bundler-audit in your CI pipeline:

# .github/workflows/dependency_audit.yml
name: Dependency Audit

on: [push, pull_request]

jobs:
  bundler_audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.0'
      - name: Install dependencies
        run: bundle install --jobs 4 --retry 3
      - name: Run bundler-audit
        run: bundle exec bundler-audit check --update

Explanation:

bundler-audit ensures your project dependencies remain secure by flagging outdated or vulnerable gems.
Integration with your CI pipeline automates the process and keeps you informed of any new vulnerabilities.

Example of Secure Headers Configuration:

# Gemfile:
gem 'secure_headers'

# config/initializers/secure_headers.rb:
SecureHeaders::Configuration.default do |config|
  config.hsts = "max-age=31536000; includeSubdomains"
  config.x_frame_options = "SAMEORIGIN"
  config.x_content_type_options = "nosniff"
  config.x_xss_protection = "1; mode=block"
  config.csp = {
    default_src: %w('self'),
    script_src: %w('self' https: 'unsafe-inline'),
    style_src: %w('self' https: 'unsafe-inline'),
    img_src: %w('self' data:),
    object_src: %w('none')
  }
end

Explanation:

Regular security scans and dependency audits help you stay ahead of potential vulnerabilities.
Automated tools integrated into your CI/CD pipeline can provide continuous feedback on the security posture of your application.

Additional Gems, Libraries, and Tools

Enhance your Rails security posture with these recommended tools:

Brakeman:

A static analysis tool designed specifically for Rails, Brakeman scans your codebase for vulnerabilities without executing your application.

Official Documentation
bundler-audit:

This gem checks your Gemfile.lock for known vulnerabilities in your dependencies, helping you maintain an up-to-date and secure set of gems.

Official Documentation
secure_headers:

A gem that simplifies the management of HTTP security headers, reducing risks from clickjacking, MIME-sniffing, and XSS attacks.

GitHub Repository
Pundit:

A lightweight authorization library that enforces access control on a per-model basis, ensuring that only permitted users can perform specific actions.

Official Documentation
ActiveStorage:

Rails’ built-in solution for file uploads, designed with security and scalability in mind.

Rails Guides on ActiveStorage

Security Best Practices Checklist

Before deploying or auditing your Rails application, ensure you have implemented the following:

SQL Injection:
- Use parameterized queries and ActiveRecord methods.
- Avoid raw SQL concatenation.
XSS Mitigation:
- Rely on Rails’ auto-escaping features.
- Use sanitization helpers (e.g., sanitize, h) where necessary.
Secrets & Credentials Management:
- Store sensitive data in Rails encrypted credentials or environment variables.
- Never hard-code secrets in your source code.
Session Management:
- Configure secure session stores (consider ActiveRecord store).
- Enforce secure, httponly, and same_site cookie flags.
CSRF Protection:
- Enable protect_from_forgery in ApplicationController.
- Ensure authenticity tokens are present in forms.
Secure File Uploads:
- Use ActiveStorage or Shrine for file handling.
- Validate file types, sizes, and scan for potential threats.
Authentication & Authorization:
- Implement Devise for authentication.
- Use Pundit or Cancancan for resource authorization.
Continuous Monitoring & Auditing:
- Integrate Brakeman and bundler-audit into your CI/CD pipeline.
- Regularly review and update security headers using secure_headers.

Conclusion

Securing your Ruby on Rails application is a continuous, multi-layered process that requires diligence, the right tools, and a proactive mindset. By implementing these best practices—from defending against SQL injection and XSS to managing sessions securely and safeguarding your secrets—you not only protect your users’ data but also enhance your application’s reliability and trustworthiness.

Remember, security isn’t a one-time checkbox; it’s an ongoing commitment. Stay informed of the latest security developments, regularly audit your codebase, and continuously integrate modern security practices into your development workflow. Your future self—and your users—will thank you.

Integrating Google OAuth2 with Devise for a Ruby on Rails Application

Harsh patel — Sun, 21 May 2023 05:08:31 +0000

As a Ruby on Rails developer, there often comes a time when you're required to implement authentication mechanisms in your application. Devise is one of the most popular authentication solutions within the Rails ecosystem. When combined with Google OAuth2, it enables an effortless sign-in experience for the users. In this article, I'm going to walk you through a step-by-step guide on how to set up Google OAuth2 with Devise on a Rails application, also incorporating exception handling to make your app robust and reliable.

Step 1: Setting up Google API

Our journey begins with creating a new project in the Google API Console. After creating the project, we'll need to enable the Google+ API (an essential part of the Google OAuth2 authentication process). Post this; you can create OAuth client ID credentials for your web application. Remember to add your callback URL as an Authorized redirect URI. For development, this usually takes the form http://localhost:3000/users/auth/google_oauth2/callback. Google provides a Client ID and Client Secret, which we will use later in the Rails application configuration.

Step 2: Configuring the Rails Application

The next step is to adapt your Rails application to the Google OAuth system. Start by adding the omniauth-google-oauth2 and dotenv-rails gems to your Gemfile. The latter helps to manage your environment variables effectively.

gem 'devise'
gem 'omniauth-google-oauth2'
gem 'dotenv-rails', groups: [:development, :test]

After running bundle install to install these gems, create a .env file in the root of your Rails application. This is where we store the Google Client ID and Client Secret that we obtained earlier.

GOOGLE_CLIENT_ID=your_client_id
GOOGLE_CLIENT_SECRET=your_client_secret

These environment variables are essential for your Rails application to communicate with the Google OAuth2 server. To integrate them, insert the following code into

config/initializers/devise.rb:

config.omniauth :google_oauth2, ENV['GOOGLE_CLIENT_ID'], ENV['GOOGLE_CLIENT_SECRET'], {}

Next, we need to make sure our User model is omniauthable and can handle the callback data. To achieve this, update app/models/user.rb:

class User < ApplicationRecord
  devise :database_authenticatable, :registerable, :omniauthable, omniauth_providers: %i[google_oauth2]

  def self.from_omniauth(access_token)
    data = access_token.info
    user = User.where(email: data['email']).first

    # Uncomment the section below if you want users to be created if they don't exist
    unless user
        user = User.create(
           email: data['email'],
           password: Devise.friendly_token[0,20]
        )
    end
    user
  end
end

Furthermore, we need to specify the callback in config/routes.rb:

devise_for :users, controllers: { omniauth_callbacks: 'users/omniauth_callbacks' }

Finally, let's create the OmniauthCallbacksControllerin app/controllers/users/omniauth_callbacks_controller.rb, which will handle the authentication data returned by the Google OAuth2 server:

class Users::OmniauthCallbacksController < Devise::OmniauthCallbacksController
  def google_oauth2
      @user = User.from_omniauth(request.env['omniauth.auth'])

      if @user.persisted?
        sign_in_and_redirect @user
      else
        session['devise.google_data'] = request.env['omniauth.auth'].except(:extra) # Removing extra as it can overflow some session stores
        redirect_to new_user_registration_url, alert: @user.errors.full_messages.join("\n")
      end
  end
end

Step 3: Exception Handling

Last but not least, we must not overlook the importance of exception handling. Robust applications need to handle failures gracefully. For this purpose, we'll set up an OmniAuth exception handler.

In config/initializers/omniauth.rb:

OmniAuth.config.on_failure = proc do |env|
  "Users::OmniauthCallbacksController".constantize.action(:failure).call(env)
end

And then add the failure method to OmniauthCallbacksController:

def failure
  flash[:error] = 'There was an error while trying to authenticate you...'
  redirect_to new_user_session_path
end

Remember to restart your Rails server whenever you make changes to the initializers.

And voila! You've just set up your Rails application with Google OAuth2 using Devise, providing your users with an easy and secure way to sign in with their Google accounts. Happy coding!

Basic Understanding of Webhooks with examples

Harsh patel — Sun, 19 Mar 2023 06:40:31 +0000

Webhooks are a way for an external service to notify your application about events that occur in the service. In other words, it's a way for your application to receive real-time notifications of events happening outside of your application.

In the context of Ruby on Rails, webhooks are commonly used to integrate with third-party services such as Stripe, PayPal, and others. These services use webhooks to send notifications to your application about events such as successful payments, failed payments, new subscribers, and other events.

By using webhooks in your Ruby on Rails application, you can automate processes that would otherwise require manual intervention, such as updating a user's account status or sending notifications to users. This can improve the user experience and streamline your application's workflow.

Webhooks can be implemented using a variety of protocols such as HTTP, HTTPS, and others. In Ruby on Rails, webhooks are typically implemented using controller actions that receive and process webhook requests, and background jobs to perform the actual work of handling the webhook events.

Overall, webhooks provide a powerful way to integrate your Ruby on Rails application with third-party services and automate processes in your application.

Handling webhooks efficiently and with proper error handling in a Ruby on Rails application is important to ensure that your application can handle large volumes of webhook requests and recover from any errors that may occur. In this example, we'll use the popular payment processing service Stripe to demonstrate how to handle webhooks efficiently and with proper error handling in a Ruby on Rails application.

Setup
The first step is to install the Stripe gem and configure it in your Rails application. You can do this by adding the following code to your Gemfile:
gem 'stripe'

Then, run bundle install to install the gem and generate a config/initializers/stripe.rb file to configure the Stripe API keys:

Rails.configuration.stripe = {
  publishable_key: ENV['STRIPE_PUBLISHABLE_KEY'],
  secret_key: ENV['STRIPE_SECRET_KEY']
}
Stripe.api_key = Rails.configuration.stripe[:secret_key]

Create a Webhooks Controller
Next, you'll need to create a controller to handle webhook requests. You can create a new WebhooksController with the following command:
rails generate controller webhooks

In the webhooks_controller.rb file, define a new method to handle webhook requests:

class WebhooksController < ApplicationController
  skip_before_action :verify_authenticity_token

  def receive
    event = Stripe::Event.construct_from(params.to_unsafe_h)

    # Handle the event
    begin
      case event.type
      when 'payment_intent.succeeded'
        handle_payment_succeeded(event.data.object)
      when 'payment_intent.payment_failed'
        handle_payment_failed(event.data.object)
      else
        raise "Unhandled event type: #{event.type}"
      end
    rescue StandardError => e
      render json: { error: e.message }, status: :unprocessable_entity
    end

    render json: { message: 'Webhook received successfully' }, status: :ok
  end

  private

    def handle_payment_succeeded(payment_intent)
        # Find the user associated with the payment
        user = User.find_by(stripe_customer_id: payment_intent.customer)

        # Check if the payment covers any outstanding invoices
        invoices = user.invoices.unpaid
        invoices.each do |invoice|
            if invoice.amount_due <= payment_intent.amount_received
            invoice.update(status: 'paid', paid_at: Time.now)
            payment_intent.amount_received -= invoice.amount_due
            end
        end

        # Create a new payment record
        payment = Payment.create(
            user: user,
            amount: payment_intent.amount_received,
            payment_method: payment_intent.payment_method,
            payment_intent_id: payment_intent.id,
            status: payment_intent.status,
            paid_at: payment_intent.created
        )

        # Send a confirmation email to the user
        UserMailer.payment_received(user, payment).deliver_later
        rescue => e
         Rails.logger.error("Error handling payment failed webhook: #{e}")
    end

    def handle_payment_failed(payment_intent)
        # Find the user associated with the payment
        user = User.find_by(stripe_customer_id: payment_intent.customer)

        # Handle any unpaid invoices
        invoices = user.invoices.unpaid
        invoices.each do |invoice|
            invoice.update(status: 'failed', failed_at: Time.now)
        end

        # Create a new payment record
        payment = Payment.create(
            user: user,
            amount: payment_intent.amount_received,
            payment_method: payment_intent.payment_method,
            payment_intent_id: payment_intent.id,
            status: payment_intent.status,
            failed_at: payment_intent.created
        )

        # Send a notification email to the user
        UserMailer.payment_failed(user, payment).deliver_later
        rescue => e
         Rails.logger.error("Error handling payment failed webhook: #{e}")
    end
end

we first find the user associated with the payment by looking up their Stripe customer ID. We then check if the payment covers any outstanding invoices by iterating over the user's unpaid invoices and updating their status to "paid" if the payment amount is sufficient.

We then create a new Payment record in our database with information from the payment_intent object, including the user, payment amount, payment method, payment intent ID, and payment status. We also set the paid_at timestamp to the time the payment was created.

Then we find the user associated with the payment by looking up their Stripe customer ID. We then handle any unpaid invoices by iterating over the user's unpaid invoices and updating their status to "failed" with the update method.

We then create a new Payment record in our database with information from the payment_intent object, including the user, payment amount, payment method, payment intent ID, and payment status. We also set the failed_at timestamp to the time the payment was created.

Finally, we send a notification email to the user using a UserMailer object and the deliver_later method to send the email asynchronously.

Configure Webhooks in Stripe
Now that your application is set up to handle webhook requests, you need to configure your Stripe account to send webhook requests to your application. Log in to your Stripe dashboard and navigate to the "Webhooks" tab.

Click the "Add Endpoint" button and enter the URL for your webhook controller action (e.g. https://example.com/webhooks/receive). You can leave the other fields at their default values.

Finally, select the events you want to receive and click the "Add Endpoint" button. Stripe will now send webhook requests to your application whenever the selected events occur.

Testing
To test your webhook handling, you can use the Stripe CLI to simulate events. Install the Stripe CLI and run the following command: stripe trigger payment_intent.succeeded

This will simulate a payment_intent.succeeded event and send a webhook request to your application. Check your application logs to confirm that the webhook was received and handled successfully.

You can also simulate a failed payment by running:
stripe trigger payment_intent.payment_failed

This will simulate a payment_intent.payment_failed event and send a webhook request to your application. Again, check your application logs to confirm that the webhook was received and handled successfully.

If any errors occur during webhook handling, check your logs for error messages and make sure that your error handling code is working correctly.

It's also a good idea to test your webhook handling with a variety of scenarios, including successful and failed payments, network errors, and unexpected events.

And that's it! You now have a robust and efficient webhook handling system in your Ruby on Rails application. With proper error handling and testing, your application can handle large volumes of webhook requests and recover from any errors that may occur.

Introduction of Rails Engine with basic example.

Harsh patel — Sat, 25 Feb 2023 11:46:11 +0000

What is RailsEngine?

A Rails engine is a self-contained piece of functionality that can be added to an existing Rails application, or used as the foundation for a new Rails application. Essentially, it's a miniature Rails application that can be packaged and reused across multiple projects.

Rails engines provide a modular way to organize and reuse code in a Rails application. They allow you to encapsulate related functionality (such as authentication, payments, or notifications) in a separate namespace, with its own models, views, controllers, routes, and assets.

An engine can include all the same features as a regular Rails application, including generators, migrations, tests, and configuration options. It can also have its own dependencies, such as gems or other engines.

Rails engines are typically developed as separate gems that can be installed and managed using Bundler. This makes it easy to share engines across multiple projects or with the wider community.

Here are the steps to create a Rails engine with error handling:

Open your terminal and navigate to the directory where you want to create your engine.

Run the following command to create a new Rails engine:
rails plugin new my_engine --mountable

This will create a new directory called my_engine with the basic structure of a Rails engine.

Open the my_engine.gemspec file and update the metadata to reflect the details of your engine, such as its name, version, and description.

Open the lib/my_engine/engine.rb file and add any required dependencies or configuration options.

Create a sample method in lib/my_engine/my_engine.rb that raises an error:

module MyEngine
  class MyEngine
    def self.my_method
      raise StandardError, "An error occurred in My Engine"
    end
  end
end

Create a sample controller in app/controllers/my_engine/my_controller.rb that calls the my_method method:

module MyEngine
  class MyController < ApplicationController
    def index
      begin
        MyEngine.my_method
      rescue StandardError => e
        render plain: "Error: #{e.message}"
      end
    end
  end
end

This controller defines an index action that calls the my_method method and handles any exceptions that are raised.

Create a sample view in app/views/my_engine/my/index.html.erb:

<h1>Welcome to My Engine</h1>
<p>This is a sample view in My Engine.</p>

Update the config/routes.rb file to define a route for your engine:

MyEngine::Engine.routes.draw do
  root to: "my#index"
end

Finally, mount your engine into a Rails application by adding the following line to the config/routes.rb file:
mount MyEngine::Engine, at: "/my_engine"

That's it! You've now created a simple Rails engine with error handling. When you navigate to the root path of your engine (/my_engine), you should see the error message that was raised by the my_method method.

To call an engine method in a Rails application, you can simply require the engine and call its methods as you would with any other Ruby class. For example, you could add the following code to a controller in your Rails application:

require "my_engine"

class MyController < ApplicationController
  def index
    MyEngine::MyEngine.my_method
  end
end

This code requires the my_engine gem and calls the my_method method on the MyEngine class. Any errors that are raised by the method will be handled by the controller's exception handling code, as shown in the previous example.

Rails engines are a powerful tool for building modular and reusable code in a Rails application, and can help developers to build more maintainable and scalable applications. They can be used to encapsulate related functionality in a separate namespace, or to develop standalone applications that can be mounted into a larger Rails application. With error handling, you can ensure that your engine provides robust and reliable functionality to its users.

Here's an example of how to create a Rails engine with notification and payment functionality.

Open your terminal and navigate to the directory where you want to create your engine.

Run the following command to create a new Rails engine:
rails plugin new my_engine --mountable

This will create a new directory called my_engine with the basic structure of a Rails engine.

Open the my_engine.gemspec file and update the metadata to reflect the details of your engine, such as its name, version, and description.

Open the lib/my_engine/engine.rb file and add any required dependencies or configuration options.

Create a Notification model in app/models/my_engine/notification.rb:

module MyEngine
  class Notification < ApplicationRecord
    validates :message, presence: true
    enum status: { unread: 0, read: 1 }
  end
end

This model defines a Notification class with a message attribute and a status enum.

Create a Payment model in app/models/my_engine/payment.rb:

module MyEngine
  class Payment < ApplicationRecord
    validates :amount, presence: true, numericality: true
    validates :currency, presence: true, inclusion: { in: %w[USD EUR GBP] }
    enum status: { pending: 0, paid: 1, failed: 2 }
  end
end

This model defines a Payment class with an amount, currency, and status attribute.

Create a NotificationsController in app/controllers/my_engine/notifications_controller.rb:

module MyEngine
  class NotificationsController < ApplicationController
    def index
      @notifications = Notification.all
    end

    def mark_as_read
      @notification = Notification.find(params[:id])
      @notification.update(status: :read)
      redirect_to my_engine_notifications_path
    end
  end
end

This controller defines an index action that retrieves all notifications and a mark_as_read action that updates a notification's status to "read".

Create a PaymentsController in app/controllers/my_engine/payments_controller.rb:

module MyEngine
  class PaymentsController < ApplicationController
    def new
      @payment = Payment.new
    end

    def create
      @payment = Payment.new(payment_params)
      if @payment.save
        redirect_to my_engine_payments_path, notice: "Payment created successfully."
      else
        render :new
      end
    end

    private

    def payment_params
      params.require(:payment).permit(:amount, :currency)
    end
  end
end

This controller defines a new action that creates a new payment and a create action that saves the payment to the database. It also includes a payment_params method to sanitize the payment parameters.

Create views for the NotificationsController in app/views/my_engine/notifications/:

index.html.erb:

<h1>Notifications</h1>
<table>
  <thead>
    <tr>
      <th>Message</th>
      <th>Status</th>
      <th>Actions</th>
    </tr>
  </thead>
  <tbody>
    <% @notifications.each do |notification| %>
      <tr>
        <td><%= notification.message %></td>
         <td><%= notification.status.capitalize %></td>
         <td><%= link_to "Mark as Read", my_engine_mark_as_read_notification_path(notification), method: :put %></td>
       </tr>
     <% end %>
   </tbody>
 </table>

mark_as_read.html.erb

<p>Notification has been marked as read.</p>
<%= link_to "Back to Notifications", my_engine_notifications_path %>

Create views for the PaymentsController in app/views/my_engine/payments/:
new.html.erb:

<h1>New Payment</h1>
<%= form_with(model: @payment, url: my_engine_payments_path) do |f| %>
  <% if @payment.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@payment.errors.count, "error") %> prohibited this payment from being saved:</h2>
      <ul>
        <% @payment.errors.full_messages.each do |message| %>
          <li><%= message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div>
    <%= f.label :amount %>
    <%= f.text_field :amount %>
  </div>
  <div>
    <%= f.label :currency %>
    <%= f.select :currency, options_for_select([["USD", "USD"], ["EUR", "EUR"], ["GBP", "GBP"]]) %>
  </div>
  <div>
    <%= f.submit "Create Payment" %>
  </div>
<% end %>

index.html.erb:

<h1>Payments</h1>
<% flash.each do |type, message| %>
  <div class="<%= type %>"><%= message %></div>
<% end %>
<table>
  <thead>
    <tr>
      <th>Amount</th>
      <th>Currency</th>
      <th>Status</th>
    </tr>
  </thead>
  <tbody>
    <% @payments.each do |payment| %>
      <tr>
        <td><%= payment.amount %></td>
        <td><%= payment.currency %></td>
        <td><%= payment.status.capitalize %></td>
      </tr>
    <% end %>
  </tbody>
</table>
<%= link_to "New Payment", my_engine_new_payment_path %>

Finally, add routes for the NotificationsController and PaymentsController in config/routes.rb:

Rails.application.routes.draw do
  mount MyEngine::Engine => "/my_engine"

  namespace :my_engine do
    resources :notifications do
      put :mark_as_read, on: :member
    end

    resources :payments, only: [:new, :create, :index]
  end
end

This will mount the engine at the /my_engine URL and define routes for the NotificationsController and PaymentsController.

With these steps, you now have a functional Rails engine with notification and payment functionality. To call these engine methods in a Rails app, you can mount the engine in the config/routes.rb file of your app and use the generated engine routes to access the engine's controllers and models. For example:

Rails.application.routes.draw do
  mount MyEngine::Engine => "/my_engine"

  get "/notifications", to: "my_engine/notifications#index"
  post "/notifications/mark_as_read/:id", to: "my_engine/notifications#mark_as_read", as: :mark_as_read_notification
  get "/payments/new", to: "my_engine/payments#new"
  post "/payments", to: "my_engine/payments#create"
  get "/payments", to: "my_engine/payments#index"
end

This will allow you to access the notifications and payments functionality provided by the engine in your Rails app by visiting the appropriate URLs. For example, you can create a link to the MyEngine notifications page using the following code in one of your views:
<%= link_to "My Notifications", my_engine_notifications_path %>

This will create a link to the notifications index page provided by the engine, which you can style and modify as desired to fit your app's design.

To call the notification and payment functionality provided by the Rails engine in a Rails application, you can use the routes and helper methods generated by the engine.

Here's an example of how you could use these helper methods in a view to display a list of notifications and a link to the payment page:

<!-- app/views/my_app/index.html.erb -->
<h1>Welcome to My App</h1>

<h2>Notifications</h2>
<ul>
  <% MyEngine::Notification.all.each do |notification| %>
    <li>
      <%= notification.message %>
      <% unless notification.read %>
        <%= link_to "Mark as read", mark_as_read_notification_path(notification) %>
      <% end %>
    </li>
  <% end %>
</ul>

<h2>Payments</h2>
<%= link_to "Make a payment", my_engine_payments_path %>

In this example, we're using the MyEngine::Notification model provided by the engine to display a list of notifications, along with a link to mark each notification as read. We're also using the mark_as_read_notification_path helper method provided by the engine to generate the appropriate URL for marking a notification as read.

Finally, we're using the my_engine_payments_path helper method provided by the engine to generate a link to the payment page. When the user clicks this link, they'll be taken to the payment page provided by the engine, where they can make a payment using the payment functionality provided by the engine.

Overall, integrating a Rails engine into a Rails application is similar to using any other external library or gem in a Rails app. By using the routes and helper methods provided by the engine, you can easily access the functionality provided by the engine and integrate it into your application as needed.

How to use Docker with Ruby on Rails applications.

Harsh patel — Sat, 18 Feb 2023 05:15:00 +0000

What is docker? and how to use it with ruby on rails applications? and benefits of using docker.

Docker is a platform for building, shipping, and running applications in containers. A container is a lightweight, standalone, and executable package of software that includes everything needed to run an application, including code, runtime, libraries, system tools, and settings. Docker makes it easy to package an application and all its dependencies into a single container, which can then be deployed to any environment that supports Docker.

Docker provides a way to package and distribute your application as a container, which makes it easier to manage dependencies, ensure consistent environments across different servers, and simplify deployment.

**Here are some of the benefits of using Docker with Ruby on Rails applications:

Consistent development environments: By using Docker to create a container that contains all the necessary dependencies and tools for your application, you can ensure that all developers are working in the same environment. This can help prevent issues caused by differences in operating systems or installed software.

Easier deployment: Docker allows you to package your application and its dependencies into a single container, which can then be deployed to any server that supports Docker. This makes it easier to move your application between development, staging, and production environments.

Improved scalability: Docker containers can be easily replicated and scaled horizontally, allowing you to handle more traffic by spinning up additional containers as needed. This can help improve the performance and reliability of your application.

Simplified maintenance: With Docker, you can isolate your application and its dependencies from the host system, which makes it easier to maintain and update your application without affecting other applications running on the same server.

Overall, using Docker with Ruby on Rails applications can help simplify development, deployment, and maintenance, while improving the performance and scalability of your application.

Here's a step-by-step example of how to use Docker with a Ruby on Rails application, Sidekiq, Redis, and PostgreSQL:

Step 1: Install Docker
Before you can use Docker, you need to install it on your system. You can download and install Docker from the official website.

Step 2: Create a new Rails application
Assuming you already have Ruby installed on your system, you can create a new Rails application with the following command:
$ rails new myapp

Step 3: Add Sidekiq to your application
To use Sidekiq with your Rails application, you need to add the sidekiq gem to your Gemfile and run bundle install. You should also generate a config/sidekiq.yml file with the following command:
$ bundle exec sidekiq --config config/sidekiq.yml

Step 4: Add Redis to your application
To use Redis with Sidekiq, you need to add the redis gem to your Gemfile and run bundle install. You should also configure Redis in your config/sidekiq.yml file.

Step 5: Add PostgreSQL to your application
To use PostgreSQL with your Rails application, you need to add the pg gem to your Gemfile and run bundle install. You should also update your config/database.yml file to use PostgreSQL.

Step 6: Create a Dockerfile
Create a new file called Dockerfile in the root of your Rails application directory. This file will define the Docker image for your application. Here's an example Dockerfile for a Rails application with Sidekiq, Redis, and PostgreSQL:

# Use an official Ruby runtime as a parent image
FROM ruby:3.0.3

# Set the working directory
WORKDIR /app

# Install dependencies
RUN apt-get update && \
    apt-get install -y \
    build-essential \
    nodejs \
    postgresql-client && \
    rm -rf /var/lib/apt/lists/*

# Install gems
COPY Gemfile Gemfile.lock ./
RUN gem install bundler && \
    bundle install --jobs 4

# Copy the application code
COPY . .

# Expose ports
EXPOSE 3000

# Set the entrypoint command
CMD ["rails", "server", "-b", "0.0.0.0"]

Step 7: Create a docker-compose.yml file
Create a new file called docker-compose.yml in the root of your Rails application directory. This file will define the Docker services for your application. Here's an example docker-compose.yml file for a Rails application with Sidekiq, Redis, and PostgreSQL:

version: "3"
services:
  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp_development
  redis:
    image: redis:6.0

Step 8: Build and start the Docker containers
To build and start the Docker containers for your application, run the following command in the root of your Rails application directory:
$ docker-compose up --build

This will build the Docker images and start the containers for your application, Sidekiq, Redis, and PostgreSQL.

Step 9: Access your application
Once the Docker containers are up and running, you should be able to access your Rails application in your web browser at http://localhost:3000. You should also be able to access the Sidekiq web interface athttp://localhost:3000/sidekiq.

Step 10: Stop and remove the Docker containers
When you're finished working with your application, you can stop and remove the Docker containers with the following command in the root of your Rails application directory:
$ docker-compose stop

This will stop and remove the Docker containers for your application, Sidekiq, Redis, and PostgreSQL.

That's it! You've now used Docker to run a Ruby on Rails application with Sidekiq, Redis, and PostgreSQL. With Docker, you can easily package and run your application in any environment, making it easy to deploy and scale your application as needed.

How to do it with production?

Here's an example of how to deploy your Ruby on Rails application to a production environment using Docker and Docker Compose:

Step 1: Build your Docker image

First, you need to build your Docker image for your Rails application. In the root of your Rails application directory, run the following command:
$ docker build -t myapp .

This will build a Docker image named myapp based on the Dockerfile in your Rails application directory.

Step 2: Push your Docker image to a registry

Next, you need to push your Docker image to a registry so that it can be deployed to your production environment. You can use a public registry like Docker Hub or a private registry like Amazon ECR or Google Container Registry.

To push your Docker image to Docker Hub, first create an account if you don't have one already. Then, tag your Docker image with your Docker Hub username and the name of your image repository:

$ docker tag myapp your-dockerhub-username/myapp:latest

Finally, push your Docker image to Docker Hub:
$ docker push your-dockerhub-username/myapp:latest

Step 3: Create a production Docker Compose file

Create a new file called docker-compose.prod.yml in the root of your Rails application directory. This file will define the Docker services for your production environment. Here's an example docker-compose.prod.yml file for a Rails application with Sidekiq, Redis, and PostgreSQL:

version: "3"
services:
  web:
    image: your-dockerhub-username/myapp:latest
    environment:
      RAILS_ENV: production
      DATABASE_URL: "postgres://postgres:password@db/myapp_production"
      REDIS_URL: "redis://redis:6379/0"
    ports:
      - "80:3000"
    depends_on:
      - db
      - redis
    restart: always
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
      POSTGRES_DB: myapp_production
    volumes:
      - db_data:/var/lib/postgresql/data
    restart: always
  redis:
    image: redis:6.0
    restart: always
volumes:
  db_data:

Note that the image property for the web service is set to the name of your Docker image on Docker Hub. The environment properties set environment variables that your Rails application will use to connect to PostgreSQL and Redis. The ports property maps port 80 on the host to port 3000 in the container. The depends_on property specifies that the web service depends on the db and redis services. The restart property specifies that the services should be restarted if they fail.

Step 4: Deploy your application to a server

To deploy your Rails application to a server, you'll need to install Docker and Docker Compose on the server.

Once Docker and Docker Compose are installed, copy your docker-compose.prod.yml file to the server and run the following command in the directory where the file is located:

$ docker-compose -f docker-compose.prod.yml up -d
This will start the Docker containers for your Rails application, Sidekiq, Redis, and PostgreSQL in the background.

Step 5: Access your application

Once the Docker containers are up and running, you should be able to access your Rails application in your web browser at http://your-server-ip-address. You should also be able to access the Sidekiq web interface at http://your-server-ip-address/sidekiq

Step 6: Update your application

To update your application, you'll need to build a new Docker image for your updated code and push it to your Docker registry. Then, on the server, you can pull the new image and start a new container using the following commands:

$ docker pull your-dockerhub-username/myapp:latest
$ docker-compose -f docker-compose.prod.yml up -d

This will pull the new Docker image and start a new container for your application, while leaving your database and Redis data intact.

Step 7: Monitor your application

To monitor your Rails application in production, you can use a tool like New Relic or Scout. These tools provide real-time monitoring and alerting for your application, so you can quickly identify and fix any issues that arise.

Step 8: Scale your application

To scale your Rails application in production, you can use Docker Compose to run multiple containers of your Rails application behind a load balancer. Here's an example docker-compose.prod.yml file for running multiple containers of your Rails application:

version: "3"
services:
  web:
    image: your-dockerhub-username/myapp:latest
    environment:
      RAILS_ENV: production
      DATABASE_URL: "postgres://postgres:password@db/myapp_production"
      REDIS_URL: "redis://redis:6379/0"
    ports:
      - "80:3000"
    depends_on:
      - db
      - redis
    deploy:
      replicas: 3
      restart_policy:
        condition: on-failure
      update_config:
        parallelism: 2
        delay: 10s
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M
  db:
    image: postgres:12
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
      POSTGRES_DB: myapp_production
    volumes:
      - db_data:/var/lib/postgresql/data
  redis:
    image: redis:6.0
volumes:
  db_data:

Note that the web service has a deploy property that specifies that it should be run with 3 replicas. The update_config property specifies that updates should be rolled out with a maximum parallelism of 2 and a delay of 10 seconds between updates. The resources property sets resource limits and reservations for the containers.

With this configuration, you can use a load balancer like Nginx or HAProxy to distribute traffic across the multiple containers of your Rails application.

Configure a reverse proxy like Nginx or Apache to route incoming HTTP requests to the Docker container running your Rails application. You can configure the reverse proxy to listen on port 80 or 443 and forward requests to port 3000, which is the default port for Rails applications. You can also configure SSL/TLS encryption for secure connections. Here is an example of an Nginx configuration file for a Rails application:

upstream myapp {
  server localhost:3000;
}

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://myapp;
    proxy_set_header Host $host
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Thanks,
Harsh

What is a ruby gem, how is it made, and what are the pros and cons with an example.

Harsh patel — Thu, 09 Feb 2023 17:09:59 +0000

Ruby gems

RubyGems is a package manager for the Ruby programming language. It provides a standard format for distributing Ruby libraries (known as "gems") and a way to easily install, manage and update these gems in a Ruby application.

A gem is a self-contained package of code, assets, and documentation that can be used in a Ruby application. Gems typically provide additional functionality that is not part of the core Ruby language, such as libraries for connecting to databases, handling HTTP requests, and so on.

RubyGems makes it easy to find, install, and manage gems in a Ruby application. You simply specify the gems that your application depends on in a file called the Gemfile, and then use the bundle install command to download and install all the gems specified in the file. The bundle install command also resolves any dependencies between gems and ensures that the correct version of each gem is installed.

RubyGems also provides a way to share gems with others. You can publish a gem to the RubyGems.org repository, where other developers can easily find and install it in their applications.

RubyGems is an essential tool for many Ruby developers, as it allows them to quickly and easily add new functionality to their applications. It's also a great way for Ruby developers to share their code and contribute to the Ruby community.

Here is an example of a Gemfile:

source 'https://rubygems.org'

gem 'rails', '~> 6.0.0'
gem 'sqlite3'
gem 'bcrypt', '~> 3.1.7'

In this example, the source line specifies the default source for gems, which is RubyGems.org. The gem lines specify the gems that the application depends on, along with version constraints.

Pros of using Rails gems in SAAS (Software as a Service) applications:

Reusability: Rails gems are pre-built components that you can reuse in multiple applications. This saves time and effort, as you don't have to build everything from scratch.
Quality assurance: Most popular Rails gems are well tested and maintained, so you can be confident that they will work as expected in your application.
Community support: There is a large community of developers who contribute to and support Rails gems, so you can often find solutions to common problems or get help with integration.
Improved functionality: Rails gems can provide additional functionality that is not part of the core Rails framework. This can help you add new features to your application faster and with less effort.

Cons of using Rails gems in SAAS applications:

Dependency management: Using gems can lead to complex dependencies between different components of your application, which can make it difficult to upgrade or manage your application.
Security: Some gems may have vulnerabilities or security risks, which can compromise the security of your application. It's important to regularly check for updates and to use trusted gems.
Performance: Using too many gems or gems with poor performance can slow down your application and affect its overall performance. It's important to choose gems carefully and to monitor the performance of your application regularly.
Compatibility: Some gems may not be compatible with your application or with other gems that you're using, which can cause problems. It's important to test and verify that all the gems you're using work together as expected.

In conclusion, using Rails gems can be a powerful way to enhance the functionality of your SAAS application, but it's important to be mindful of the potential drawbacks and to use gems responsibly.

Example

Here is a step-by-step guide on how to create a gem in Ruby on Rails based and install it in a Rails application:

Create a new directory for your gem: mkdir photo_upload_gem
Navigate to the newly created directory: cd photo_upload_gem
Initialize a new gem: bundle gem photo_upload_gem
Fill in the required information, such as the name, summary, and description of your gem.
Open the gemspec file: open photo_upload_gem.gemspec
Add the following code to include the necessary dependencies:

# photo_upload_gem.gemspec

Gem::Specification.new do |s|
  # ...
  s.add_dependency 'paperclip'
end

Create a generator for your gem: touch lib/generators/photo_upload_gem/install_generator.rb
Add the following code to the generator to create the necessary files:

# lib/generators/photo_upload_gem/install_generator.rb

class PhotoUploadGem::InstallGenerator < Rails::Generators::Base
  source_root File.expand_path("../templates", __FILE__)

  def create_model
    template 'photo.rb', 'app/models/photo.rb'
  end

  def create_controller
    template 'photos_controller.rb', 'app/controllers/photos_controller.rb'
  end

  def create_view
    template 'new.html.erb', 'app/views/photos/new.html.erb'
  end

  def add_routes
    route 'resources :photos, only: [:new, :create]'
  end
end

Create the templates for the model, controller, and view:mkdir lib/generators/photo_upload_gem/templates
Add the following code to the photo.rb template:

# lib/generators/photo_upload_gem/templates/photo.rb

class Photo < ActiveRecord::Base
  has_attached_file :attachment
  validates_attachment_content_type :attachment, content_type: /\Aimage\/.*\Z/
end

Add the following code to the photos_controller.rb template:

# lib/generators/photo_upload_gem/templates/photos_controller.rb

class PhotosController < ApplicationController
  def new
    @photo = Photo.new
  end

  def create
    @photo = Photo.new(photo_params)
    if @photo.save
      redirect_to root_path, notice: 'Photo was successfully uploaded.'
    else
      render :new
    end
  end

  private

  def photo_params
    params.require(:photo).permit(:attachment)
  end
end

Add the following code to the new.html.erb template:

<!-- lib/generators/photo_upload_gem/templates/new.html.erb -->

<%= form_for @photo, html: { multipart: true } do |f| %>
  <%= f.file_field :attachment %>
  <%= f.submit %>
<% end %>

Build the gem: bundle build photo_upload_gem
Test the gem locally by installing it in a test application: cd path/to/test/app && bundle install
Add the following code to the Gemfile of your test application:

# Gemfile

gem 'photo_upload_gem', path: 'path/to/photo_upload_gem'

Run the generator to create the necessary files:rails generate photo_upload_gem:install
Migrate the database to create the necessary tables: rake db:migrate
Visit http://localhost:3000/photos/new to test the photo upload feature.

Accounting App Example

Creating a gem and using it in a Rails application is a great way to encapsulate and reuse code across multiple projects. Here's a step-by-step guide to creating a gem for an accounting application and using it in a Rails application:

Generate the gem skeleton

Open your terminal and navigate to the directory where you want to create your gem
Run the following command to create the gem skeleton: $ bundle gem my_accounting_app

This will create a directory named my_accounting_app with the basic structure of a Ruby gem.

Define the accounting methods

In the lib directory, create a file named my_accounting_app.rb. This is where you'll define the methods for your accounting application.
For example, you can create a method to calculate the total amount of an invoice:

module MyAccountingApp
  def self.total_amount(amount, tax)
    amount + (amount * tax)
  end
end

Write the gemspec

In the root directory of your gem, you'll find a file named my_accounting_app.gemspec. This is where you'll specify the metadata for your gem, such as its name, version, author, and description.
Update the gemspec file with the following information:

# my_accounting_app.gemspec
Gem::Specification.new do |spec|
  spec.name        = "my_accounting_app"
  spec.version     = "0.1.0"
  spec.authors     = ["Your Name"]
  spec.email       = ["your_email@example.com"]
  spec.summary     = "A gem for accounting applications"
  spec.description = "A gem that provides methods for accounting applications"
  spec.files       = Dir["lib/**/*.rb"]
  spec.require_paths = ["lib"]
end

Build the gem

In the root directory of your gem, run the following command to build the gem:
$ gem build my_accounting_app.gemspec
This will create a .gem file in the root directory of your gem, which you can use to install the gem.

Use the accounting methods in your Rails application

Create a new Rails application: $ rails new my_rails_app
Add the following line to the Gemfile of your Rails application:

gem "my_accounting_app", path: "/path/to/my_accounting_app"

Replace /path/to/my_accounting_app with the actual path to your gem.
Run the following command to install the gem in your Rails application: $ bundle install

Use the accounting methods in your Rails application

class InvoicesController < ApplicationController
  def show
    amount = params[:amount].to_f
    tax = params[:tax].to_f
    @total_amount = MyAccountingApp.total_amount(amount, tax)
  end
end

This code creates an instance variable @total_amount that holds the result of calling MyAccountingApp.total_amount with amount and tax from the URL parameters.
You'll also need to add a route to map URLs to the InvoicesController:

Rails.application.routes.draw do
  get "/invoices/show", to: "invoices#show"
end

You can use the total_amount method in your view to display the calculated amount:

<h1>Invoice</h1>
<p>Amount: <%= params[:amount] %></p>
<p>Tax: <%= params[:tax] %></p>
<p>Total amount: <%= @total_amount %></p>

This view displays the amount and tax from the URL parameters and the calculated total amount from the controller.
You'll need to create a file app/views/invoices/show.html.erb with the above content.

$ rails s

Navigate to http://localhost:3000/invoices/show?amount=100&tax=0.1 in your web browser to see the calculated total amount

Publish your gem to RubyGems

If you want to make your gem available to others, you can publish it to RubyGems.org.
First, you'll need to create an account on RubyGems.org.
Then, run the following command to publish your gem: $ gem push my_accounting_app-0.1.0.gem
Replace my_accounting_app-0.1.0.gem with the actual name of your gem file.

That's it! You've successfully created a gem for an accounting application and used it in a Rails application. By encapsulating the accounting logic in a gem, you can reuse it across multiple projects and share it with others.

Set up a basic multi-tenant architecture in Rails without gem - 2

Harsh patel — Fri, 03 Feb 2023 12:56:14 +0000

Please go through this article
Multi tenancy with Apartment Gem

A simple multi-tenancy architecture in Rails without using the apartment gem can be implemented using a subdomain-based approach. Here's an outline of the steps:

Set up your Rails app with subdomains routing:

# config/routes.rb
Rails.application.routes.draw do
  constraints(subdomain: /.+/) do
    resources :tenants, only: [:show]
    resources :posts, only: [:index, :show]
    root to: 'tenants#show'
  end
  root to: 'home#index'
end

Create a Tenant model to store information about each tenant:

# app/models/tenant.rb
class Tenant < ApplicationRecord
  validates :subdomain, presence: true, uniqueness: true
  has_many :posts
end

Create a middleware to set the current tenant based on the subdomain:

# app/middleware/current_tenant.rb
class CurrentTenant
  def initialize(app)
    @app = app
  end

  def call(env)
    tenant = Tenant.find_by(subdomain: request.subdomain)
    if tenant
      RequestStore.store[:tenant] = tenant
      @app.call(env)
    else
      [404, { 'Content-Type' => 'text/plain' }, ['Tenant not found.']]
    end
  end

  private

  def request
    @request ||= Rack::Request.new(env)
  end
end

Use the middleware in your Rails app:

# config/application.rb
config.middleware.use CurrentTenant

Scope your models to the current tenant:

# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :tenant

  default_scope -> { where(tenant_id: RequestStore[:tenant].id) }
end

Use the tenant data in your controllers and views:

# app/controllers/tenants_controller.rb
class TenantsController < ApplicationController
  def show
    @tenant = RequestStore[:tenant]
  end
end

# app/views/tenants/show.html.erb
<h1><%= @tenant.name %></h1>
<%= link_to 'Posts', posts_path %>

This implementation provides a basic setup for a multi-tenancy architecture in Rails, with the tenant information being set based on the subdomain, and the models being scoped to the current tenant. You can further add error handling and security measures as required.

Example Request: GET http://tenant1.example.com/posts

Example Response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
...

<h1>Tenant 1</h1>
<a href="/posts">Posts</a>

2nd Example

class Tenant < ApplicationRecord
  has_many :users
end

class User < ApplicationRecord
  belongs_to :tenant
end

class TenantMiddleware
  def initialize(app)
    @app = app
  end

  def call(env)
    tenant = Tenant.find_by(subdomain: request.subdomain)
    if tenant
      Current.tenant = tenant
    else
      raise ActiveRecord::RecordNotFound
    end

    @app.call(env)
  end
end

Add a scope to your User model:

class User < ApplicationRecord
  belongs_to :tenant
  default_scope -> { where(tenant: Current.tenant) }
end

Configure your database connection:

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
  establish_connection(ENV.fetch("#{Rails.env}_DATABASE_URL"))
end

class Tenant < ApplicationRecord
  establish_connection("#{Rails.env}_tenant_#{id}")
  has_many :users
end

class User < ApplicationRecord
  belongs_to :tenant
  default_scope -> { where(tenant: Current.tenant) }
end

Now, the application will automatically switch database connections based on the subdomain in the request URL. This way, each tenant will have their own isolated data.

Example request-response:

Request:
GET http://tenant1.example.com/users

Response -:

[
  {
    "id": 1,
    "name": "User 1",
    "email": "user1@example.com"
  },
  {
    "id": 2,
    "name": "User 2",
    "email": "user2@example.com"
  }
]

3rd Example

First, you'll need to create a model to represent the tenant. For example:

class Tenant < ApplicationRecord
  has_many :photos

  validates :name, presence: true, uniqueness: true
end

Next, you'll need to create a model to represent the photos that are uploaded by each tenant. For example:

class Photo < ApplicationRecord
  belongs_to :tenant

  has_one_attached :image

  validates :image, presence: true
end

You'll need to create a mechanism to set the tenant context for each request. One way to do this is to use a before_actionin your ApplicationController. For example:

class ApplicationController < ActionController::Base
  before_action :set_tenant

  private

  def set_tenant
    tenant = Tenant.find_by(subdomain: request.subdomain)
    Tenant.set_current_tenant(tenant)
  end
end

4.In your controller, you'll need to handle the file attachment and save it to the database. For example:

class PhotosController < ApplicationController
  def new
    @photo = Photo.new
  end

  def create
    @photo = Tenant.current_tenant.photos.new(photo_params)

    if @photo.save
      redirect_to @photo, notice: "Photo was successfully uploaded."
    else
      render :new
    end
  end

  private

  def photo_params
    params.require(:photo).permit(:image)
  end
end

In your routes, you'll need to specify the tenant_id in the URL to ensure that each photo is associated with the correct tenant. For example:

constraints subdomain: /^[\w-]+/ do
  resources :photos, only: [:new, :create]
end

Finally, you'll need to add a form field for the file attachment in your view. For example:

<%= form_with model: @photo, local: true do |form| %>
  <% if @photo.errors.any? %>
    <div id="error_explanation">
      <h2><%= pluralize(@photo.errors.count, "error") %> prohibited this photo from being saved:</h2>

      <ul>
        <% @photo.errors.full_messages.each do |message| %>
          <li><%= message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>

  <div class="field">
    <%= form.label :image %>
    <%= form.file_field :image %>
  </div>

  <div class="actions">
    <%= form.submit %>
  </div>
<% end %>

Here's an example of an HTTP request and response for uploading a photo for a tenant with subdomain "tenant1":

Request -:

POST http://tenant1.yourdomain.com/photos
Content-Type: multipart/form-data

photo[image]: (binary data for the photo image file)

Response -:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "status": "success",
  "message": "Photo was successfully uploaded."
}

Here's an example of an HTTP request and response for uploading a photo:

#Request -:

POST /tenants/1/photos
Content-Type: multipart/form-data

photo[image]: (binary data for the photo image file)

#Response -:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "status": "success",
  "message": "Photo was successfully uploaded."
}

Set up a basic multi-tenant architecture in Rails 7 - 1

Harsh patel — Mon, 30 Jan 2023 17:18:39 +0000

Basic understanding of multi tenancy in rails

Multi-tenancy in Rails refers to the capability of a single instance of a Rails application to serve multiple, isolated tenants (i.e. separate customers or organizations) using the same codebase and infrastructure. Each tenant has its own set of data, which is stored in separate databases or schemas, and they cannot access or interfere with each other's data.

A multi-tenant Rails application is typically designed to allow tenants to customize certain aspects of their instance, such as branding, themes, and feature configurations. To implement multi-tenancy in Rails, you can use a gem such as Apartment to manage multiple databases or schemas and switch between them based on the tenant identifier.

In a multi-tenant Rails application, tenants are typically identified by a unique identifier such as a subdomain or a path in the URL. The tenant identifier is used to switch to the appropriate database or schema for that tenant, and all subsequent requests for that tenant are processed using the data from that schema.

Multi-tenancy has several benefits, including cost savings, improved scalability, and enhanced security. By running multiple tenants on a single instance of an application, you can reduce the costs associated with hosting and maintaining separate instances for each tenant. Multi-tenancy also allows you to scale your application more easily, as you can add new tenants without having to provision new hardware or infrastructure. Additionally, multi-tenancy helps to improve security by isolating data between tenants, reducing the risk of data breaches and ensuring that each tenant's data is secure.

To set up a basic multi-tenant architecture in Rails 7, you can follow these steps:

Add the Apartment gem to your Gemfile:
gem 'apartment'

Run bundle install.

Create a Tenant model:
rails g model Tenant name subdomain

Add the tenant identifier column to each table:
rails g migration AddTenantIdToUsers tenant_id:integer

Configure Apartment in an initializer:

Apartment.configure do |config|
  config.excluded_models = %w[Tenant]
  config.tenant_names = lambda { Tenant.pluck(:subdomain) }
end

Use the tenant identifier to switch between schemas in your application:

class ApplicationController < ActionController::Base
  before_action :set_tenant

  private

  def set_tenant
    tenant = Tenant.find_by(subdomain: request.subdomain)
    Apartment::Tenant.switch(tenant.subdomain) if tenant
  end
end

With these steps, you have set up a basic multi-tenant architecture in Rails 7 that allows you to run multiple instances of your application, each with its own set of data, on a single codebase and infrastructure.

We can also create with Rails API

Create API endpoints for tenants:

class TenantsController < ApplicationController
  def create
    tenant = Tenant.create!(tenant_params)
    Apartment::Tenant.create(tenant.subdomain)
    render json: { message: 'Tenant created successfully' }, status: :created
  end

  private

  def tenant_params
    params.require(:tenant).permit(:name, :subdomain)
  end
end

With these steps, you have set up a basic multi-tenant architecture in a Rails API application that allows you to serve multiple tenants with a single codebase and infrastructure, each with its own set of data. The tenant identifier (subdomain) is used to switch to the appropriate database or schema for that tenant, and all subsequent requests for that tenant are processed using the data from that schema.

Create sign up and login pages for tenants

class TenantsController < ApplicationController
  def new
    @tenant = Tenant.new
  end

  def create
    tenant = Tenant.create!(tenant_params)
    Apartment::Tenant.create(tenant.subdomain)
    redirect_to root_url(subdomain: tenant.subdomain)
  end

  private

  def tenant_params
    params.require(:tenant).permit(:name, :subdomain)
  end
end

Multi-tenant architecture can be used in various applications in Rails, including:

SaaS (Software as a Service) applications: Multi-tenancy is a common design pattern for SaaS applications, as it allows you to serve multiple customers or organizations with a single instance of the application.

Marketplace applications: Multi-tenancy can be used to support multiple vendors or sellers in a marketplace, where each vendor has its own set of data and cannot access or interfere with the data of other vendors.

Enterprise applications: Multi-tenancy can be used in enterprise applications to support multiple departments or subsidiaries, each with its own data and configurations.

Educational applications: Multi-tenancy can be used in educational applications to support multiple schools or institutions, each with its own data and configurations.

Healthcare applications: Multi-tenancy can be used in healthcare applications to support multiple healthcare providers, each with its own set of data and configurations.

These are just a few examples of where multi-tenancy can be used in Rails. The key advantage of multi-tenancy is that it allows you to serve multiple customers or organizations with a single instance of the application, reducing the costs and complexity associated with maintaining separate instances for each customer.

Here is a detailed code example for a multi-tenant healthcare application in Rails:

Add the Apartment gem to your Gemfile:
gem 'apartment'

Run bundle install.

Create a Hospital model:
rails g model Hospital name

Add the tenant identifier column to each table:
rails g migration AddHospitalIdToPatients hospital_id:integer

Configure Apartment in an initializer:

Apartment.configure do |config|
  config.excluded_models = %w[Hospital]
  config.tenant_names = lambda { Hospital.pluck(:name) }
end

Use the tenant identifier to switch between schemas in your controllers:

class ApplicationController < ActionController::Base
  before_action :set_tenant

  private

  def set_tenant
    hospital = Hospital.find_by(name: request.subdomain)
    Apartment::Tenant.switch(hospital.name) if hospital
  end
end

Create sign up and login pages for hospitals:

class HospitalsController < ApplicationController
  def new
    @hospital = Hospital.new
  end

  def create
    hospital = Hospital.create!(hospital_params)
    Apartment::Tenant.create(hospital.name)
    redirect_to root_url(subdomain: hospital.name)
  end

  private

  def hospital_params
    params.require(:hospital).permit(:name)
  end
end

Create the Patients table for each new hospital that signs up:

class CreatePatients < ActiveRecord::Migration[6.0]
  def change
    create_table :patients do |t|
      t.string :first_name
      t.string :last_name
      t.string :email
      t.integer :hospital_id
      t.timestamps
    end
  end
end

Create the Appointments table for each new hospital that signs up:

class CreateAppointments < ActiveRecord::Migration[6.0]
  def change
    create_table :appointments do |t|
      t.datetime :date_time
      t.integer :patient_id
      t.integer :hospital_id
      t.timestamps
    end
  end
end

With these steps, you have set up a basic multi-tenant healthcare application in Rails that allows multiple hospitals to sign up and use the application, each with its own subdomain and data

The tenant identifier (subdomain) is used to switch to the appropriate database or schema for that hospital, and all subsequent requests for that hospital are processed using the data from that schema. When a new hospital signs up, the Patients and Appointments tables are created for that hospital within its own schema, and all data for that hospital is stored and processed within that schema.

Creating a secure API architecture in Rails with few example

Harsh patel — Wed, 25 Jan 2023 17:11:28 +0000

Creating a secure API architecture in Rails with login, logout, signup, list-users, and create-user functionality requires several steps, here is an example of how to implement each step:

Use a secure protocol: Use HTTPS for all API requests to ensure that all data is transmitted securely. To force HTTPS in Rails, you can use the following code in your application controller:

force_ssl if: :ssl_configured?

def ssl_configured?
  Rails.env.production?
end

Use JSON Web Tokens (JWT) for authentication: Use JWT to authenticate users and protect against cross-site request forgery (CSRF) attacks. You can use the jwt gem to handle JWT in Rails. Here is an example of how to generate and decode JWT tokens in a SessionsController:

class SessionsController < ApplicationController
  def create
    user = User.find_by(email: params[:email])
    if user&.authenticate(params[:password])
      token = JWT.encode({user_id: user.id}, Rails.application.secrets.secret_key_base)
      render json: {token: token}
    else
      render json: {error: 'Invalid login credentials'}, status: :unauthorized
    end
  end

  def decode
    token = request.headers['Authorization']
    decoded_token = JWT.decode(token, Rails.application.secrets.secret_key_base)[0]
    render json: {user_id: decoded_token['user_id']}
  end
end

Use bcrypt for password hashing: Use bcrypt to hash and salt user passwords to protect against password cracking attacks. To use bcrypt in Rails, you can add the bcrypt gem to your Gemfile and use the has_secure_password method in your User model:

class User < ApplicationRecord
  has_secure_password
end

Use strong parameters: Use strong parameters to prevent mass assignment vulnerabilities and ensure that only the intended attributes are updated. In your controller, you can use the permit method to specify which attributes are allowed:

def create
  user = User.new(user_params)
  if user.save
    render json: user
  else
    render json: {error: user.errors.full_messages}
  end
end

private

def user_params
  params.require(:user).permit(:name, :email, :password)
end

Use CORS: Use the Rails rack-cors gem to configure Cross-Origin Resource Sharing (CORS) and allow cross-domain requests from trusted origins. You can use the config/application.rb file to configure the rack-cors gem:

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://example.com'
    resource '*', headers: :any, methods: [:get, :post, :put, :delete]
  end
end

To use rate-limiting and IP blocking to prevent denial-of-service attacks and other malicious activity in a Rails API, you can use the rack-attack gem. Here's an example of how to configure rack-attack in a Rails API:
Add the rack-attack gem to your Gemfile and run bundle install:

# Gemfile
gem 'rack-attack'

In config/application.rb or config/environments/production.rb, configure rack-attack to use the Rack::Attack::Store::Redis store and set the throttle options:

config.middleware.use Rack::Attack
Rack::Attack.cache.store = Rack::Attack::Store::Redis.new

# Allow 10 requests per second per IP
Rack::Attack.throttle("req/ip", limit: 10, period: 1.second) do |req|
  req.ip
end

Optionally, configure rack-attack to block IPs that exceed a certain number of requests over a certain time period:

# Block IPs that make more than 100 requests per day
Rack::Attack.throttle("req/ip", limit: 100, period: 1.day) do |req|
  req.ip if req.path.include?("/api/")
end

Optionally, configure rack-attack to block IPs that exceed a certain number of requests over a certain time period:

# Block IPs that make more than 100 requests per day
Rack::Attack.throttle("req/ip", limit: 100, period: 1.day) do |req|
  req.ip if req.path.include?("/api/")
end

Optionally, configure rack-attack to block IPs that exceed a certain number of requests to a specific endpoint :

# Block IPs that make more than 10 requests per minute to a specific endpoint
Rack::Attack.throttle("req/ip/endpoint", limit: 10, period: 1.minute) do |req|
  req.ip if req.path.include?("/api/v1/users/")
end

This configuration will limit the number of requests per IP to 10 requests per second, and block IPs that exceed 100 requests per day. You can adjust the limit and period options as needed for your specific use case. It is also important to monitor the rate-limiting and IP blocking rules and adjust them as necessary to ensure that legitimate users are not affected.

Use a security scanner: Use a security scanner such as brakeman or bundler-audit to identify and fix any security vulnerabilities in your code.

Brakeman is a static analysis security vulnerability scanner for Ruby on Rails applications. It can be installed as a ruby gem and run from the command line. Here is an example of how to install and run Brakeman:

gem install brakeman
brakeman

This will run Brakeman on your Rails application and generate a report of any potential security vulnerabilities it finds.

Another option is to use bundler-audit which is a gem dependency security scanner. It can be installed as a ruby gem and run from the command line. Here is an example of how to install and run bundler-audit:

gem install bundler-audit
bundle-audit check

This will run bundle-audit on your Rails application and generate a report of any known vulnerabilities in your application's dependencies.

Both Brakeman and bundler-audit are very useful tools for identifying and fixing security vulnerabilities in your Rails API. It is important to schedule regular scans and address any vulnerabilities that may be found.

To use authorization in a Rails API, you can use a gem such as Pundit or CanCanCan. Both gems provide a simple and flexible way to handle authorization and ensure that users can only perform actions that they have been granted permission to do.

Here's an example of how to use Pundit to handle authorization in a Rails API:

Add the **pundit **gem to your Gemfile and run bundle install:

# Gemfile
gem 'pundit'

Generate a Policy class for each of your models:

rails g pundit:policy User

In the Policy class, define which actions a user is allowed to perform based on their role or permissions:

# app/policies/user_policy.rb
class UserPolicy < ApplicationPolicy
  def index?
    user.admin?
  end

  def show?
    user.admin? || user.id == record.id
  end

  def create?
    user.admin?
  end

  def update?
    user.admin? || user.id == record.id
  end

  def destroy?
    user.admin?
  end
end

In your controllers, use the **authorize **method to check if a user is authorized to perform a specific action:

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  before_action :set_user, only: [:show, :update, :destroy]

  def index
    @users = User.all
    authorize User
    render json: @users
  end

  def show
    authorize @user
    render json: @user
  end

  def create
    @user = User.new(user_params)
    authorize @user
    if @user.save
      render json: @user, status: :created, location: @user
    else
      render json: @user.errors, status: :unprocessable_entity
    end
  end

  def update
    authorize @user
    if @user.update(user_params)
      render json: @user
    else
      render json: @user.errors, status: :unprocessable_entity
    end
  end

  def destroy
    authorize @user
    @user.destroy
  end

  private

  def set_user
    @user = User.find(params[:id])
  end

  def user_params
    params.require(:user).permit(:name, :email, :password)
  end
end

Optionally, you can handle the unauthorized exception by adding the following code in application_controller.rb

rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized

private

def user_not_authorized
  render json: { error: "You are not authorized to perform this action." }, status: :unauthorized
end

CanCanCan is another gem for authorization in Rails. It allows you to define ability rules to determine what actions a user is allowed to perform. Here is an example of how to use CanCanCan to authorize a user to update a Post:

class Ability
  include CanCan::Ability

  def initialize(user)
    if user.admin?
      can :manage, :all
    else
      can :update, Post, author_id: user.id
    end
  end
end

class PostsController < ApplicationController
  load_and_authorize_resource

  def update
    if @post.update(post_params)
      render json: @post
    else
      render json: {error: @post.errors.full_messages}
    end
  end

  private

  def post_params
    params.require(:post).permit(:title, :body)
  end
end

Both Pundit and CanCanCan are great options for handling authorization in a Rails API. They both provide a flexible and powerful way to define and enforce access controls, but with different syntax. It's important to choose the one that best fits your needs and you are comfortable with.

Conducting regular security audits is an important step in ensuring that your Rails API is secure and up to date. Here are a few ways to perform regular security audits in a Rails API
Use a security scanner such as Brakeman or Bundler-audit to automatically scan your code for known vulnerabilities. These scanners can be integrated into your development process and run on a regular basis.

# Run Brakeman
brakeman

# Run bundler-audit
bundle-audit

Perform manual code reviews to check for any potential security issues that may not be detected by automated scanners. This can include reviewing code for SQL injection vulnerabilities, cross-site scripting (XSS) vulnerabilities, and other potential issues.
Review your infrastructure and configurations to ensure that they are secure and up to date. This can include checking that all servers, databases, and other components are running the latest versions and that they are configured securely.
Regularly monitor and log all API activity for auditing and security purposes. This can include monitoring for suspicious activity, such as multiple failed login attempts, and logging all requests to your API for later review.
Conduct penetration testing to simulate real-world attacks and identify vulnerabilities in your API. This can include using tools such as Metasploit to test for vulnerabilities and simulating attacks to identify any potential security issues.

Here's an example of how you might integrate Brakeman into your development process:

Add the brakeman gem to your Gemfile and run bundle install.

# Gemfile
gem 'brakeman'

Run brakeman on your application to generate a report on any potential security issues:
brakeman

Review the report generated by Brakeman and address any issues found.
Integrate Brakeman into your continuous integration process to run the scan automatically on each build.

It is also important to keep in mind that security is an ongoing process and you should always be on the lookout for new vulnerabilities and updates to the libraries you use.

Keep your app updated: Keep your Rails app and its dependencies updated to ensure that any security vulnerabilities are patched promptly

It's important to keep your Rails app and its dependencies up-to-date to ensure that any security vulnerabilities are patched promptly. You can use the bundle-outdated command to check which gems in your app are outdated. Here is an example of how to use it:
bundle outdated
This will show a list of gems that have newer versions available, and you can update them by running:
bundle update <gem_name>

It's important to keep an eye on the security releases of the gems you are using in your app, you can use a service like RubySec to get notifications of new vulnerabilities in the gems you are using.

Another important step to take is to keep your Rails version up-to-date. You can check the version of Rails you are currently using by running:
rails -v
You can update Rails by modifying the version in your Gemfile and running:
bundle update rails
and then running the necessary commands to update your application to the new version of Rails.

It's important to schedule regular updates for your app and its dependencies, and to test your app thoroughly after each update. It's also recommended to keep a backup of your app before doing any updates, in case something goes wrong.

Thanks,
Harsh Umaretiya

DEV Community: Harsh patel

Introducing the new Community Dashboard on TailView.work

TL;DR

Why this dashboard?

What’s new

UI/UX decisions that matter

The stack (and why)

A few patterns you can reuse

Try it, copy it, ship it

TailView UI: Open-Source Rails Components with Hotwire Magic 🚀

TailView UI: Building Beautiful Rails Apps Without the JavaScript Fatigue

TL;DR

The Problem: Rails Developers Deserve Better UI Tools

Enter TailView UI: Components Built the Rails Way

What Makes TailView Different?

🛠️ The Tech Stack: Modern Rails at Its Best

Rails 8.0.2

Hotwire (The Secret Sauce)

Tailwind CSS

📦 What's Inside: 20+ Production-Ready Components

Layout Components

Interactive Components

Forms & Inputs

Data Display

Feedback Components

🚀 Hotwire Magic: The Power of Stimulus

📊 Performance Benefits: Why Monoliths Win

🎨 Accessibility & Best Practices

🚦 Getting Started: It's Ridiculously Simple

1. Visit TailView

2. Browse Components

3. Copy the Code

4. Paste & Customize

🤝 Contributing: Join the Rails Renaissance

Report Issues

Submit Components

Improve Documentation

Spread the Word

💭 Lessons Learned Building TailView

1. Hotwire is Production-Ready

2. Simplicity Scales

3. The Rails Community is Amazing

Get Started Today

Let's Connect!

FAQ

Modern Rails Rendering Techniques: Choosing Between Turbo Drive, Frames, Streams and Morph

Table of Contents

Understanding the Fundamentals

Turbo Drive: The Foundation

When to use Turbo Drive:

Example:

Live Demo:

Turbo Frames: Targeted Updates

When to use Turbo Frames:

Example:

Live Demo:

Turbo Streams: Real-time Updates

When to use Turbo Streams:

Example:

Live Demo:

Turbo Morph: Fine-grained DOM Updates

When to use Turbo Morph:

Example:

Live Demo:

Decision Framework: When to Use What

Real-world Example: Building a Comment System

Performance Considerations

Interactive Tutorial

Conclusion

Essential Security Best Practices for Ruby on Rails

Table of Contents

Introduction and Context

Key Security Best Practices in Ruby on Rails

1. Protection Against SQL Injection

2. Mitigation of Cross-Site Scripting (XSS)

3. Secure Management of Secrets, Credentials, and Sensitive Configuration Data

4. Proper Session Management and Secure Cookies

5. Cross-Site Request Forgery (CSRF) Protection Strategies

6. Secure File Uploads and Handling Attachments

7. Robust Authentication and Authorization