“Which backend should I use?” is one of the most-argued questions in software — and most answers pick a single metric (usually raw speed) and declare a winner. That’s the wrong lens. The right backend depends on what you’re building, how fast you need to ship, and who you can hire. Let’s compare Ruby on Rails, Node.js, and Go across the dimensions that actually move a project.
A framework that wins a “requests per second” chart can still be the wrong choice if it takes twice as long to build features or you can’t hire for it. Engineering decisions are trade-offs across speed-to-market, running cost, hiring, and maintainability — so weigh all of them, not just the one that’s easy to measure.
Go: The clear winner on raw throughput. It’s compiled, and goroutines make concurrency cheap, so it often needs significantly less compute for the same load. Ideal for proxies, APIs at scale, and CPU-bound work.Node.js: A non-blocking event loop makes it excellent for I/O-bound, real-time workloads — chat, streaming, live dashboards — though CPU-heavy tasks block that single thread.Rails: Not built for raw benchmarks, but rarely the bottleneck for typical web apps. With background jobs and caching, it scales comfortably for the vast majority of products.This is where Rails earns its reputation. Convention over configuration means less boilerplate and fewer decisions — generators, an ORM, migrations, and a mature testing story are all built in. Node.js is fast too, but you assemble your own stack from many packages. Go is the most deliberate: explicit and verbose by design, which trades early speed for long-term clarity.
A trivial “create a user” endpoint shows the ergonomics of each:
# Rails
class UsersController < ApplicationController
def create
user = User.create!(user_params)
render json: user, status: :created
end
end
// Node.js (Express)
app.post("/users", async (req, res) => {
const user = await User.create(req.body)
res.status(201).json(user)
})
// Go (net/http)
func createUser(w http.ResponseWriter, r *http.Request) {
var u User
json.NewDecoder(r.Body).Decode(&u)
db.Create(&u)
w.WriteHeader(http.StatusCreated)
json.NewEncoder(w).Encode(u)
}
Node.js: The largest talent pool — most developers know JavaScript — but skill levels vary widely and architectures differ from team to team.Rails: A smaller but specialised pool. Because the framework is so opinionated, Rails developers tend to be productive in an unfamiliar codebase quickly, which makes hiring outcomes more predictable.Go: A smaller, more senior pool. Great engineers, but typically a higher rate and a longer search.Rails gives you a curated, batteries-included ecosystem — most of what a web app needs is one gem away. Node.js has the largest registry by far, but that breadth brings “dependency churn”: fast-moving, sometimes shallow packages. Go leans on a strong standard library and keeps dependencies minimal, which pays off in long-term stability.
Choose Rails for SaaS products, marketplaces, and business systems where feature velocity and maintainability matter most.Choose Node.js when real-time features are central, or you want to share code and people across the front and back end.Choose Go for performance-critical infrastructure — high-throughput APIs, proxies, and services where compute cost is the dominant concern.There’s no universal winner. Go wins on raw efficiency, Node.js on real-time and a shared language, and Rails on getting a feature-rich product to market — and keeping it maintainable for years. For most business-logic-heavy applications, that last quality is the one that compounds, which is why Rails remains such a strong default. Pick the tool that fits the job in front of you, not the one that tops a benchmark.
]]>Staying on an old Rails version feels safe, but it quietly piles up risk: missing security patches, a shrinking pool of developers who want to work on it, and features you simply can’t use. The good news is that upgrading is a well-trodden path — as long as you do it one major version at a time and lean on the tooling Rails gives you. Here’s a practical route from Rails 5/6 all the way to Rails 8.
Security: Only the latest few releases get patches. An unpatched app is a liability.Hiring: Strong developers want to work on a modern stack, not babysit a 2018 codebase.Cost & speed: Newer Rails and Ruby are faster and cheaper to run, and unlock features like Hotwire and the Solid trifecta.The single biggest mistake is jumping from 5 straight to 8. Each major version has its own deprecations and removals; skipping them turns a series of small, debuggable changes into one giant, cascading mess. Walk the path: 5.2 → 6.0 → 6.1 → 7.0 → 7.1 → 7.2 → 8.0.
You can’t upgrade safely without a green test suite. Run it first and note what passes — that’s your safety net for every step that follows.
bundle exec rspec # or: bin/rails test
If coverage is thin, invest here before touching anything. Tests are what tell you an upgrade broke something.
Each Rails version requires a minimum Ruby. Bump Ruby on its own, get the suite green, and deploy that — so you’re only changing one thing at a time.
# .ruby-version
3.3.6
Point the Gemfile at the next version and update just Rails and its dependencies:
# Gemfile
gem "rails", "~> 6.1.0"
bundle update rails
Then run the interactive updater, which walks you through framework default and config changes:
bin/rails app:update
Review every diff it proposes — especially files in config/initializers and config/environments.
Rails gates new behaviour behind config.load_defaults. After upgrading, keep the old defaults until the app is stable, then raise them deliberately:
# config/application.rb
config.load_defaults 6.1
The generated config/initializers/new_framework_defaults_*.rb file lets you flip individual settings on one at a time instead of all at once.
A blocked dependency can derail the whole project. Before each jump, check that your gems support the target version:
bundle outdated
Read the changelogs for anything major. Replace abandoned gems early — discovering a dead gem halfway through is the classic mid-upgrade trap.
Run the suite again, fix what broke, and watch the logs for deprecation warnings — those are next version’s removals. Repeat steps 3–6 for each version until you reach 8.0, deploying after each successful jump.
Jumping multiple majors at once — the fastest way to a mess.Upgrading with weak tests — you’ll ship regressions blind.Skipping the dependency audit — a dead gem can block you for days.Flipping all new defaults immediately — raise load_defaults only once stable.Treating it as pure tech debt — frame it as the business investment it is, and protect dedicated time for it.A Rails upgrade isn’t a heroic rewrite — it’s a disciplined loop: bump one version, run app:update, audit gems, fix deprecations, get green, deploy, repeat. Do that, and you’ll land on Rails 8 with its Solid Queue, Solid Cache, and Kamal goodies, on a codebase that’s secure, fast, and a pleasure to hire for.
Secrets management is a problem in every stack, not just Rails. SOPS (Secrets OPerationS) is a framework-agnostic tool that encrypts just the values in a YAML/JSON/ENV file, supports multiple keys and cloud KMS, and produces diffs you can actually review — so you can safely commit your secrets to git. It works with anything, but since I reach for it most often on Rails, that’s the example we’ll use here. Rails’ own encrypted credentials are a fine starting point, but they have limits: one shared key, an all-or-nothing file, and noisy diffs — exactly what SOPS fixes.
Reviewable diffs: Only values are encrypted, so keys and structure stay readable. A PR shows which secret changed, not a wall of ciphertext.Many keys: Encrypt to several recipients at once — each developer’s key, plus a CI key. Revoke one without re-sharing a master key.KMS-ready: Back it with AWS KMS, GCP KMS, Azure Key Vault, age, or PGP.Per-environment files: Keep staging and production secrets in separate, independently-encrypted files.We’ll use age for keys — it’s simpler than PGP and perfect for a small team.
brew install sops age
Generate a key pair. The public key encrypts; the private key (kept off git) decrypts.
age-keygen -o config/sops/age.key
# Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8r
A .sops.yaml at the repo root defines creation rules — which files to encrypt and to which recipients:
# .sops.yaml
creation_rules:
- path_regex: config/secrets/.*\.yml$
age: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8r
Write your secrets as plain YAML:
# config/secrets/production.yml
DATABASE_URL: postgres://user:pass@db.internal/myapp
STRIPE_SECRET_KEY: sk_live_abc123
RAILS_MASTER_KEY: 0a1b2c3d4e5f
Then encrypt it in place. SOPS rewrites the file so every value becomes ciphertext while the keys stay legible:
sops --encrypt --in-place config/secrets/production.yml
The result is safe to commit — DATABASE_URL is still visible, but its value is now ENC[AES256_GCM,data:...] plus a sops: metadata block.
The cleanest runtime approach is sops exec-env, which decrypts into the process environment and runs your command — no plaintext ever touches disk:
SOPS_AGE_KEY_FILE=config/sops/age.key \
sops exec-env config/secrets/production.yml 'bin/rails server'
Prefer to decrypt inside the app? Read and parse it in an initializer:
# config/initializers/sops.rb
secrets_file = Rails.root.join("config/secrets/#{Rails.env}.yml")
if secrets_file.exist?
decrypted = `sops --decrypt #{secrets_file}`
YAML.safe_load(decrypted).each { |key, value| ENV[key] ||= value.to_s }
end
Now ENV["STRIPE_SECRET_KEY"] is available throughout the app, just like any other environment variable.
Never edit the encrypted file by hand. sops opens the decrypted version in your editor and re-encrypts on save:
sops config/secrets/production.yml
Store the private age key as a single CI secret (e.g. SOPS_AGE_KEY), and let your pipeline decrypt at deploy time. One secret in your CI provider unlocks everything else — and that one key never lands in the repo.
SOPS turns secrets management into normal version control: encrypted files live next to your code, diffs are reviewable, and access is controlled by who holds a key. For teams that have outgrown a single shared master.key, it’s a clean, auditable upgrade — and it plays nicely with whatever Rails version you’re on.
Platforms like Heroku are convenient, but they get expensive fast — and you give up control. Kamal, the deploy tool that now ships with Rails, lets you deploy a containerised app to any server you can SSH into, with zero-downtime releases and automatic SSL. Version 2.0 made it dramatically simpler. Let’s ship a Rails app to a plain VPS.
Kamal deploys web apps as Docker containers to your own servers. It SSHes in, pulls your image, boots the new container, health-checks it, and only then routes traffic to it — so users never see a blip. You own the infrastructure, but you get a Heroku-like git push workflow.
kamal-proxy: A purpose-built reverse proxy replaces Traefik. It handles zero-downtime cutovers and automatic HTTPS via Let’s Encrypt out of the box.Easier multi-app hosting: Run several apps on one server without fighting over ports.First-class secrets: A dedicated .kamal/secrets file with helpers to pull values from your environment or a password manager.Kamal ships with Rails 8. On older apps, add it and generate the config:
gem install kamal
kamal init
This creates config/deploy.yml, a .kamal/secrets file, and a Dockerfile (Rails 7.1+ already includes a production-ready one).
config/deploy.yml is the heart of it — name the service, the image, your servers, and the registry:
service: myapp
image: yourname/myapp
servers:
web:
- 192.168.0.1
proxy:
ssl: true
host: myapp.com
registry:
username: yourname
password:
- KAMAL_REGISTRY_PASSWORD
env:
secret:
- RAILS_MASTER_KEY
clear:
RAILS_ENV: production
Setting proxy.ssl: true with a host is all it takes for kamal-proxy to provision and renew a Let’s Encrypt certificate.
In 2.0, secrets live in .kamal/secrets (never commit the resolved values). You can read them straight from the environment or a tool like 1Password:
# .kamal/secrets
KAMAL_REGISTRY_PASSWORD=$KAMAL_REGISTRY_PASSWORD
RAILS_MASTER_KEY=$(cat config/master.key)
Provision the servers (installs Docker, boots the proxy) once, then deploy:
kamal setup
After that, every release is a single command:
kamal deploy
Kamal builds the image, pushes it, pulls it on each server, runs your bin/docker-entrypoint (migrations included), health-checks the new container, and swaps traffic over with no downtime.
kamal app logs -f # tail logs
kamal console # rails console on the server
kamal rollback # revert to the previous release
kamal app exec "bin/rails db:migrate"
Kamal 2.0 hits a sweet spot: the simplicity of a PaaS with the cost and control of your own hardware. Once config/deploy.yml is set up, shipping is just kamal deploy — and automatic SSL plus zero-downtime cutovers mean you spend time building features, not babysitting servers.
You don’t always need a single-page app to build a snappy, modern UI. Hotwire — the default front-end stack that ships with Rails — lets you build reactive interfaces by sending HTML over the wire instead of JSON, keeping your logic on the server where Rails is strongest. It’s made up of three pieces: Turbo, Stimulus, and Turbo Native.
Hotwire (HTML Over The Wire) is an approach to building web apps without writing much JavaScript. Rather than serialising state to JSON and rebuilding the DOM on the client, you send the markup the browser actually needs and let the framework swap it in.
Turbo: Speeds up navigation and updates the page in fragments — no custom JS required.Stimulus: A small JavaScript framework for the bits that genuinely need behaviour.Turbo Native: Wraps your web app in a hybrid iOS/Android shell.Turbo Drive intercepts link clicks and form submissions, fetches the new page in the background, and swaps the <body> — giving you SPA-like speed with zero code. It’s on by default. When you need to opt a link out, just tell it:
<%= link_to "Download report", report_path, data: { turbo: false } %>
A Turbo Frame is a slice of the page that updates independently. Wrap content in a turbo_frame_tag, and any link or form inside it replaces only that frame on response.
<%# app/views/posts/show.html.erb %>
<%= turbo_frame_tag "post_#{@post.id}" do %>
<h2><%= @post.title %></h2>
<%= link_to "Edit", edit_post_path(@post) %>
<% end %>
When the user clicks Edit, Rails renders the edit view; Turbo extracts the matching frame and swaps it in. The rest of the page never reloads.
Turbo Streams let the server push fine-grained changes — append, prepend, replace, update, remove — to specific DOM targets. They’re perfect for things like adding a comment without a full reload.
# app/controllers/comments_controller.rb
def create
@comment = @post.comments.create!(comment_params)
respond_to do |format|
format.turbo_stream
format.html { redirect_to @post }
end
end
<%# app/views/comments/create.turbo_stream.erb %>
<%= turbo_stream.append "comments", @comment %>
<%= turbo_stream.update "comments_count", @post.comments.count %>
Pair this with broadcasts_to in your model and Action Cable, and the same stream reaches every connected user in real time:
class Comment < ApplicationRecord
belongs_to :post
broadcasts_to :post
end
Some interactions are purely client-side — a dropdown, a copy-to-clipboard button, a character counter. That’s Stimulus’s job. It connects plain HTML to small, well-named controllers.
// app/javascript/controllers/clipboard_controller.js
import { Controller } from "@hotwired/stimulus"
export default class extends Controller {
static targets = ["source"]
copy() {
navigator.clipboard.writeText(this.sourceTarget.value)
}
}
<div data-controller="clipboard">
<input data-clipboard-target="source" value="https://example.com/abc" readonly>
<button data-action="clipboard#copy">Copy</button>
</div>
Hotwire shines for CRUD-heavy, business-logic apps — dashboards, admin panels, marketplaces — where most of the work is on the server anyway. You keep one language, one set of templates, and skip the API layer entirely. If you’re building something with heavy client-side state (a drawing tool, a game), a dedicated front-end framework still makes sense. For everything else, Hotwire gets you a fast, reactive UI with a fraction of the code.
]]>In a world where applications need to handle thousands of tasks efficiently, job queues are the unsung heroes. They help process background tasks, ensuring your application stays responsive while heavy lifting happens in the background. One such solution that stands out is Solid Queue.
1. Lightweight and Minimal Overhead: Solid Queue avoids unnecessary complexity by focusing on core job queuing. Its lightweight design ensures it has minimal impact on your system resources. Unlike some heavy queuing systems, Solid Queue doesn’t add extra bloat to your stack.
2. Concurrency and Parallelism: Solid Queue uses Ruby’s threading capabilities effectively. It allows multiple tasks to run concurrently, ensuring maximum CPU utilization without bottlenecks. This design makes it ideal for high-throughput applications.
3. In-Memory Queuing: By default, Solid Queue operates in memory, making task enqueueing and dequeueing extremely fast. For production use, it supports integration with persistent storage like Redis or a database, ensuring job durability.
4. Customizable Workers: Solid Queue lets you define workers that can be tuned for specific tasks, enabling you to optimize resource allocation and processing efficiency.
5. Retry Mechanism: `Built-in support for retrying failed jobs ensures that transient errors don’t disrupt task processing. This reliability feature enhances application stability.
Solid Queue operates on a producer-consumer model: This separation ensures that heavy tasks don’t block the main application, keeping your users happy with fast responses.
Producer: Rails application enqueues tasks (jobs) into the queue.
Queue: Tasks are stored in memory or a persistent storage backend.
Consumer: Worker threads fetch and execute tasks from the queue.
gem 'solid_queue'
bundle install
Create an initializer file to set up Solid Queue. For example, config/initializers/solid_queue.rb:
SolidQueue.configure do |config|
config.worker_count = 5 # Number of concurrent workers
config.logger = Rails.logger # Use Rails' logger for job logs
config.retry_attempts = 3 # Retry failed jobs 3 times
end
Here, you configure the number of workers (threads), logging, and retry attempts. You can add more configurations based on your application’s needs.
Create a directory for your jobs (e.g., app/jobs). Then, define your job classes. Each job must implement a perform method:
class MyBackgroundJob
def perform(data)
# Simulate a background task
Rails.logger.info "Processing data: #{data}"
# Example task: Send an email or process a file
UserMailer.welcome_email(data[:user_id]).deliver_now
end
end
You can define as many job classes as needed for different tasks. Each job encapsulates the logic for a specific background task.
Adding Job with Complex Logic
For tasks with multiple steps, break down the logic into helper methods:
class ComplexJob
def perform(data)
Rails.logger.info "Starting complex job for data: #{data}"
step_one(data)
step_two(data)
Rails.logger.info "Completed complex job for data: #{data}"
end
private
def step_one(data)
# Perform the first step
Rails.logger.info "Step one with: #{data[:step_one_info]}"
end
def step_two(data)
# Perform the second step
Rails.logger.info "Step two with: #{data[:step_two_info]}"
end
end
This structure ensures that your code remains readable and maintainable.
You can enqueue jobs from controllers, models, or services. Here’s an example from a controller:
class UsersController < ApplicationController
def create
@user = User.new(user_params)
if @user.save
# Enqueue a background job
SolidQueue.enqueue(MyBackgroundJob.new, data: { user_id: @user.id })
# Enqueue a complex job
SolidQueue.enqueue(ComplexJob.new, data: { step_one_info: "info1", step_two_info: "info2" })
redirect_to @user, notice: 'User was successfully created.'
else
render :new
end
end
private
def user_params
params.require(:user).permit(:name, :email, :password, :password_confirmation)
end
end
Here, both a simple and a complex job are triggered after a user is successfully created.
Solid Queue includes a worker manager to process jobs. Start the workers using the Rails runner:
rails runner "SolidQueue.start"
Example Worker Output When a job runs, you might see logs like this:
[Worker-1] Processing job: MyBackgroundJob with data: {:user_id=>42}
[Worker-2] Processing job: ComplexJob with data: {:step_one_info=>"info1", :step_two_info=>"info2"}
[Worker-1] Completed job: MyBackgroundJob
[Worker-2] Completed job: ComplexJob
For development, you can also start the workers manually. In production, integrate it with process managers like foreman, systemd, or Docker.
Monitor your jobs to ensure smooth operation. You can log queue length and worker utilization or use monitoring tools for deeper insights. For example:
Rails.logger.info “Current queue length: #{SolidQueue.queue_length}”
Implementing a Monitoring Job
You can create a job to monitor and alert on queue health:
class QueueMonitoringJob
def perform
length = SolidQueue.queue_length
if length > 10
Rails.logger.warn "High queue length: #{length}"
end
end
end
Schedule this job to run periodically using a cron scheduler like whenever or a similar tool.
Solid Queue provides robust mechanisms to handle job failures. Here’s how you can leverage them:
Solid Queue automatically retries failed jobs based on the retry_attempts configuration. You can also implement custom retry logic in your job class:
class ResilientJob
def perform(data)
begin
# Perform a task that might fail
process_data(data)
rescue StandardError => e
Rails.logger.error "Job failed: #{e.message}"
raise e # Re-raise to trigger a retry
end
end
private
def process_data(data)
# Example: Make an API call
RestClient.get(data[:url])
end
end
For jobs that fail even after retries, you can implement a dead letter queue to store them for further inspection.
SolidQueue.configure do |config|
config.dead_letter_handler = ->(job, error) {
Rails.logger.error "Job permanently failed: #{job.inspect}, Error: #{error.message}"
FailedJob.create(job_data: job, error_message: error.message)
}
end
This ensures no job is lost, even in the event of persistent failures.
Inspecting Failed Jobs
You can build a simple admin interface to inspect failed jobs:
class FailedJobsController < ApplicationController
def index
@failed_jobs = FailedJob.all
end
def retry
failed_job = FailedJob.find(params[:id])
SolidQueue.enqueue(eval(failed_job.job_data))
failed_job.destroy
redirect_to failed_jobs_path, notice: "Job retried successfully."
end
end
Use Idempotent Jobs: Ensure that your jobs can run multiple times without adverse effects. For example, check for the existence of a record before creating it.
Prioritize and Categorize Jobs: Use job priorities or categories to ensure critical tasks are executed first while others are queued.
Monitor Performance: Keep an eye on job metrics like execution time, retries, and failures. These insights will help you optimize job efficiency.
Scale Wisely: Adjust worker counts dynamically based on load using tools like Kubernetes for autoscaling or dedicated process managers.
Handle Failures Gracefully: Use retry and dead letter queue mechanisms effectively to recover from transient errors while identifying systemic issues.
Log Strategically: Avoid excessive logging, especially for high-frequency tasks, to prevent log bloat while still capturing essential job execution details.
Have you ever wondered how raw data gets transformed into something meaningful and useful? Whether you’re migrating a database, cleaning up messy data, or synchronizing information between systems, you’ve likely been doing ETL (Extract-Transform-Load) without even realizing it!
Extract: The first step is like being a data detective—you gather data from various sources. Whether it’s a CSV file, a database, or even an API, your mission is to pull in all the information you need.
Transform: Next, the fun part—transforming the data! This is where you clean, filter, and reformat your data into a shiny, polished version. It’s like giving your data a makeover so it’s ready for action.
Load: Finally, you place the transformed data into its final destination. Whether it’s a database, a report, or a dashboard, this is where your hard work pays off, and your data is ready to be used
Ruby is a fantastic language for building ETL processes because it’s simple, powerful, and flexible. And with the Kiba gem, you can create robust ETL pipelines with ease. Let’s walk through a basic example of how to implement ETL using Kiba.
First, you’ll need to install the Kiba gem. Add it to your Gemfile:
gem 'kiba'
Then, run bundle install to install the gem.
1. Extract the Data
We’ll start by extracting data from a CSV file. Kiba makes defining a source for your data straightforward:
require 'kiba'
require 'csv'
module ETLJob
extend Kiba::DSLExtensions
source Kiba::Common::Sources::CSV, filename: 'users.csv', csv_options: { headers: true }
end
2. Transform the Data
Next, we’ll transform the data. We’ll clean up names, convert emails to lowercase, and ensure ages are integers. Here’s how:
module ETLJob
transform do |row|
row['Name'] = row['Name'].strip
row['Age'] = row['Age'].to_i
row['Email'] = row['Email'].downcase
row
end
end
3. Load the Data
Finally, we’ll load the transformed data. This integrates the ETL process into your Rails application, making data handling smooth and consistent:
# app/models/user.rb
class User < ApplicationRecord
end
# etl_job.rb
module ETLJob
destination Kiba::Common::Destinations::Lambda, ->(row) {
User.create(
name: row['Name'],
age: row['Age'],
email: row['Email']
)
}
end
Now that you’ve defined the source, transformation, and destination, it’s time to run the ETL job. Here’s how you can do it:
Kiba.run(ETLJob)
Once the job runs successfully, your data will be extracted from the CSV file, transformed to ensure consistency, and loaded into the SQLite database—all with just a few lines of Ruby code!
ETL is a powerful process that turns raw data into valuable insights, and with Ruby and the Kiba gem, you can create your own ETL pipelines with ease. Whether you’re working on a small project or handling large-scale data processing, Ruby gives you the tools to get the job done efficiently.
So the next time you’re working with data in Ruby, remember: with Kiba, you’re just a few steps away from turning your data into gold!
]]>In today’s fast-paced digital world, email marketing has become a vital part of business communication. Whether it’s a promotional campaign, a newsletter, or a product update, having an attractive and responsive email can make a big difference. But creating fancy emails that look good across different devices and email clients can be a headache. This is where MJML comes to the rescue.
MJML (Mailjet Markup Language) is an open-source framework designed to help developers create responsive and visually appealing emails. It’s a powerful tool that makes crafting emails simpler, faster, and more efficient. Instead of dealing with messy HTML and complicated CSS for different email clients, MJML allows you to focus on content while the framework takes care of the layout and responsiveness.
Responsive Design Made Easy: MJML’s key strength is its ability to create emails that automatically adapt to various screen sizes. It ensures that your emails look great on both desktops and mobile devices without the need for complicated media queries.
Cross-Client Compatibility: Emails often render differently across email clients (Gmail, Outlook, etc.). MJML’s framework handles the inconsistencies across these platforms, ensuring a consistent look.
Simplified Markup: Writing email HTML can be complex, especially when you’re trying to make the design responsive. MJML simplifies this by using an easy-to-read syntax, so you don’t have to worry about writing lengthy CSS or intricate HTML tags.
Faster Development: MJML speeds up the design process because it abstracts away the repetitive and challenging parts of coding for emails. It generates clean, optimized HTML that’s ready to be sent.
Open Source: MJML is free to use, and it’s continuously updated by a community of developers.
MJML works by letting you write in a custom markup language that’s easier to understand than traditional HTML. You then use the MJML engine (available as an online tool, Node.js library, or even through plugins for different code editors) to compile it into responsive HTML code ready for emails.
Let’s break down the structure a little. MJML has tags like <mj-section>, <mj-column>, <mj-text>, and <mj-button> to create sections, columns, text blocks, and buttons. You don’t need to worry about complex CSS to make these elements look good on different devices.
Let’s take a look at a professional, well-designed email using MJML, perfect for a Product Launch or Special Offer campaign. This example will demonstrate how to create an engaging, visually appealing email with clear branding, a call-to-action, and mobile responsiveness.
<mjml>
<mj-body background-color="#f4f7fa">
<!-- Header Section -->
<mj-section background-color="#ffffff" padding="20px 0">
<mj-column>
<mj-image src="https://via.placeholder.com/150" alt="Brand Logo" width="150px" align="center"></mj-image>
</mj-column>
</mj-section>
<!-- Main Hero Section -->
<mj-section background-color="#ff6347" padding="40px 0">
<mj-column>
<mj-text color="#ffffff" font-size="30px" font-family="Arial, sans-serif" align="center" padding="10px 0">
🚀 Introducing Our Latest Product!
</mj-text>
<mj-text color="#ffffff" font-size="18px" font-family="Arial, sans-serif" align="center" padding="10px 0">
Get ready to elevate your experience with the best features we’ve ever designed.
</mj-text>
<mj-button background-color="#ffffff" color="#ff6347" font-family="Arial, sans-serif" font-size="18px" href="https://example.com" padding="15px 25px" align="center">
Explore Now
</mj-button>
</mj-column>
</mj-section>
<!-- Features Section -->
<mj-section background-color="#ffffff" padding="40px 0">
<mj-column width="33.33%">
<mj-text font-size="20px" font-family="Arial, sans-serif" align="center" color="#333333">
🔥 Feature 1
</mj-text>
<mj-text font-size="16px" font-family="Arial, sans-serif" align="center" color="#777777">
A groundbreaking innovation that will change the way you use products forever.
</mj-text>
</mj-column>
<mj-column width="33.33%">
<mj-text font-size="20px" font-family="Arial, sans-serif" align="center" color="#333333">
🚀 Feature 2
</mj-text>
<mj-text font-size="16px" font-family="Arial, sans-serif" align="center" color="#777777">
Experience seamless integration with every device you own.
</mj-text>
</mj-column>
<mj-column width="33.33%">
<mj-text font-size="20px" font-family="Arial, sans-serif" align="center" color="#333333">
✨ Feature 3
</mj-text>
<mj-text font-size="16px" font-family="Arial, sans-serif" align="center" color="#777777">
Enjoy the most user-friendly interface yet, designed for everyone.
</mj-text>
</mj-column>
</mj-section>
<!-- Footer Section -->
<mj-section background-color="#2c3e50" padding="20px 0">
<mj-column>
<mj-text color="#ecf0f1" font-size="14px" font-family="Arial, sans-serif" align="center">
If you no longer wish to receive emails from us, you can <a href="https://example.com/unsubscribe" style="color: #ecf0f1;">unsubscribe here</a>.
</mj-text>
</mj-column>
</mj-section>
</mj-body>
</mjml>
Responsive Layout: This email will adapt to different screen sizes and devices (mobile, tablet, and desktop). The content will look great no matter where it’s viewed.
Clear Call-to-Action: The button in the Hero Section stands out with its contrasting color, encouraging the recipient to click and learn more about the product.
Professional Design: The clean and consistent design enhances user experience while making your brand look trustworthy and modern.
Cross-Client Compatibility: With MJML, you don’t need to worry about rendering issues across different email clients like Gmail, Yahoo, Outlook, and Apple Mail.
MJML makes designing responsive, beautiful emails a breeze. Whether you’re a beginner or a seasoned developer, it simplifies the email creation process while ensuring high-quality results. The best part? You don’t need to worry about the headache of making your email look good on every device and email client, as MJML handles that for you.
Give it a try: You can start using MJML right now by visiting their official site, where you can write, test, and compile your emails directly online!
XSLT is a powerful tool for transforming XML data into a desired format. It can be especially useful in Rails applications when you need to:
Transform incoming XML into a format compatible with your application’s database.
Extract only the necessary information from complex XML documents.
Convert XML into JSON for use in APIs or front-end applications.
Leverage a declarative approach that separates transformation logic from application code, making it easier to maintain and modify.
Handle complex XML structures efficiently without extensive custom parsing logic.
Reuse existing XSLT stylesheets for standardized transformations across different applications or services.
Let’s assume you have the following XML file (data.xml):
<products>
<product>
<id>1</id>
<name>Product A</name>
<price>100</price>
<category>Electronics</category>
</product>
<product>
<id>2</id>
<name>Product B</name>
<price>200</price>
<category>Furniture</category>
</product>
<product>
<id>3</id>
<name>Product C</name>
<price>150</price>
<category>Electronics</category>
</product>
</products>
And an enhanced XSLT file (transform.xslt) to transform the XML into a JSON-like format, including a condition to filter products by category:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text" indent="yes"/>
<xsl:template match="/">
[
<xsl:for-each select="products/product[category='Electronics']">
{
"id": "<xsl:value-of select="id"/>",
"name": "<xsl:value-of select="name"/>",
"price": "<xsl:value-of select="price"/>",
"category": "<xsl:value-of select="category"/>"
}<xsl:if test="position() != last()">,</xsl:if>
</xsl:for-each>
]
</xsl:template>
</xsl:stylesheet>
This XSLT transformation filters products to include only those in the “Electronics” category. You can further customize the conditions, such as filtering by price range or combining multiple criteria.
Create a Service Object
To keep your code clean, encapsulate the logic in a service object. Create a file app/services/xml_importer.rb:
require 'nokogiri'
class XmlImporter
def self.import(xml_path, xslt_path)
xml = File.read(xml_path)
xslt = File.read(xslt_path)
doc = Nokogiri::XML(xml)
stylesheet = Nokogiri::XSLT(xslt)
transformed_data = stylesheet.transform(doc)
JSON.parse(transformed_data)
end
end
Generate a controller to handle XML imports:
rails generate controller Imports
In app/controllers/imports_controller.rb, add the following code:
class ImportsController < ApplicationController
def create
xml_path = Rails.root.join('data.xml')
xslt_path = Rails.root.join('transform.xslt')
@data = XmlImporter.import(xml_path, xslt_path)
render json: @data
end
end
Set Up Routes
Add a route for the import action in config/routes.rb:
Rails.application.routes.draw do
post 'imports', to: 'imports#create'
end
Testing the Implementation
Place the data.xml and transform.xslt files in the Rails root directory. Start the Rails server:
rails server
Use a tool like curl or Postman to test the endpoint:
curl -X POST http://localhost:3000/imports
You should receive a JSON response with the transformed data:
[
{"id": "1", "name": "Product A", "price": "100", "category": "Electronics"},
{"id": "3", "name": "Product C", "price": "150", "category": "Electronics"}
]
By leveraging XSLT and Nokogiri, you can easily transform and import XML data into your Rails application. This approach is powerful, flexible, and allows for clean separation of transformation logic from application code. Experiment with different XML and XSLT structures to unlock the full potential of this technique!
]]>React Query is a powerful library for managing server-state in React applications. It simplifies data fetching, caching, and synchronization, making your app faster and easier to maintain. In this blog, we’ll explore how to use React Query to fetch and cache data with a practical example.
Automatic Caching: React Query caches data automatically and updates it when necessary.
Out-of-the-Box Features: It provides features like retries, background refetching, and stale data handling.
Simplifies State Management: Avoids the need for global state management for server data.
Customizable and Flexible: You can fine-tune how data is fetched, cached, and synchronized.
First, install the necessary package:
npm install @tanstack/react-query
You’ll also need React Query Devtools for debugging:
npm install @tanstack/react-query-devtools
Set up a QueryClient to manage your queries. Wrap your app with the QueryClientProvider:
import React from 'react';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { ReactQueryDevtools } from '@tanstack/react-query-devtools';
const queryClient = new QueryClient();
function App() {
return (
<QueryClientProvider client={queryClient}>
<div>
<h1>React Query Example</h1>
<MyComponent />
</div>
<ReactQueryDevtools initialIsOpen={false} />
</QueryClientProvider>
);
}
export default App;
Let’s fetch and display a list of users from a public API.
Create a function to fetch data from the API:
const fetchUsers = async () => {
const response = await fetch('https://jsonplaceholder.typicode.com/users');
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
};
In your component, use the useQuery hook to fetch and cache the data:
import React from 'react';
import { useQuery } from '@tanstack/react-query';
function MyComponent() {
const { data, error, isLoading } = useQuery(['users'], fetchUsers);
if (isLoading) return <div>Loading...</div>;
if (error) return <div>Error: {error.message}</div>;
return (
<ul>
{data.map((user) => (
<li key={user.id}>{user.name}</li>
))}
</ul>
);
}
export default MyComponent;
React Query offers several options to fine-tune behavior:
const { data, error, isLoading } = useQuery(['users'], fetchUsers, {
staleTime: 60000, // Data is considered fresh for 60 seconds
cacheTime: 300000, // Cache data for 5 minutes
retry: 2, // Retry failed requests up to 2 times
refetchOnWindowFocus: false, // Disable refetching on window focus
});
React Query supports pagination and infinite scrolling with the useInfiniteQuery hook. For example:
import { useInfiniteQuery } from '@tanstack/react-query';
const fetchUsersPage = async ({ pageParam = 1 }) => {
const response = await fetch(`https://jsonplaceholder.typicode.com/users?_page=${pageParam}`);
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
};
function PaginatedComponent() {
const {
data,
fetchNextPage,
hasNextPage,
isFetchingNextPage,
} = useInfiniteQuery(['users'], fetchUsersPage, {
getNextPageParam: (lastPage, allPages) => (lastPage.length ? allPages.length + 1 : undefined),
});
return (
<div>
{data?.pages.map((page, i) => (
<ul key={i}>
{page.map((user) => (
<li key={user.id}>{user.name}</li>
))}
</ul>
))}
<button
onClick={() => fetchNextPage()}
disabled={!hasNextPage || isFetchingNextPage}
>
{isFetchingNextPage ? 'Loading...' : hasNextPage ? 'Load More' : 'No More Users'}
</button>
</div>
);
}
Mutations are used to create, update, or delete data. For example:
import { useMutation, useQueryClient } from '@tanstack/react-query';
const addUser = async (newUser) => {
const response = await fetch('https://jsonplaceholder.typicode.com/users', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(newUser),
});
if (!response.ok) {
throw new Error('Network response was not ok');
}
return response.json();
};
function AddUserComponent() {
const queryClient = useQueryClient();
const mutation = useMutation(addUser, {
onSuccess: () => {
queryClient.invalidateQueries(['users']); // Refetch users after adding
},
});
return (
<button
onClick={() => mutation.mutate({ name: 'New User', email: 'newuser@example.com' })}
>
Add User
</button>
);
}
React Query is a game-changer for managing server-state in React applications. Its features like automatic caching, background refetching, and retry logic reduce boilerplate and improve performance. Start using React Query today to streamline your data-fetching logic and enhance your app’s user experience!
]]>