ruby 36 lines · 7 steps

How Rails jobs handle reverse geocoding

A background job turns signup coordinates into a readable address, with retries, guards, and safe database writes.

Explained by highlit
1class ReverseGeocodeSignupJob < ApplicationJob
2 queue_as :default
3 
4 retry_on Geocoder::OverQueryLimitError, wait: 5.minutes, attempts: 3
5 discard_on ActiveJob::DeserializationError
6 
7 def perform(signup)
8 return if signup.latitude.blank? || signup.longitude.blank?
9 
10 results = Geocoder.search([signup.latitude, signup.longitude])
11 result = results.first
12 return if result.nil?
13 
14 signup.update_columns(
15 city: result.city,
16 region: result.state,
17 country_code: result.country_code&.upcase,
18 formatted_address: result.address,
19 geocoded_at: Time.current
20 )
21 end
22end
23 
24class Signup < ApplicationRecord
25 validates :email, presence: true, uniqueness: { case_sensitive: false }
26 
27 after_create_commit :enqueue_reverse_geocode
28 
29 private
30 
31 def enqueue_reverse_geocode
32 return unless latitude? && longitude?
33 
34 ReverseGeocodeSignupJob.perform_later(self)
35 end
36end
01 / 01
STEP 01

Walkthrough

Space play step click any line
Three takeaways
  1. 1Offload slow, failure-prone external API calls to background jobs so the request cycle stays fast.
  2. 2Declarative retry_on and discard_on keep transient failures recoverable while dropping permanently invalid work.
  3. 3Guard clauses and update_columns let a job write results defensively without re-triggering callbacks.

Related explainers

Share this explainer

Here's the card — post it anywhere.

How Rails jobs handle reverse geocoding — share card
Made with highlit — turn any snippet into a walkthrough like this in about a minute.
Explain your code