DEV Community: Aleksandr Ulanov

Using Rails Service Objects

Aleksandr Ulanov — Sat, 27 Aug 2022 16:29:00 +0000

If you're developing web apps using Ruby on Rails, you probably already know that Rails is an MVC (Model-View-Controller) framework, which means that you have your Models responsible for data, Views responsible for templates and Controllers responsible for requests handling. But the bigger your app gets, the more features it has - the more business logic you will have. And here comes the question, where do you put your business logic? Obviously it's not views that should handle it. Controllers or Models? That will make them fat and unreadable pretty soon. That's where Service Objects come to the rescue. In this article we'll find out what are Service Objects and how you can use them to make your app cleaner and kepp it maintainable.

Let's say you have a project for handling cab trips, we'll take a look at the particular controller action, which updates trip records. But it should not only update trips based on user input params (e.g. starting address, destination address, riders count, etc.), but it should also calculate some fields based on those params and save it to the database. So, we have a controller action like this:

class TripsController < ApplicationController
  def update
    @trip = Trip.find(params[:id])
    if update_trip(trip_params)
      redirect_to @trip
    else
      render :edit
    end
  end

  private

  def update_trip(trip_params)
    distance_and_duration = calculate_trip_distance_and_duration(trip_params[:start_address],
                                                                 trip_params[:destination_address])
    @trip.update(trip_params.merge(distance_and_duration))
  end

  def calculate_trip_distance_and_duration(start_address, destination_address)
    distance = Google::Maps.distance(start_address, destination_address)
    duration = Google::Maps.duration(start_address, destination_address)
    { distance: distance, duration: duration }
  end
end

The problem here is that you’ve added at least ten lines to your controller, but this code does not really belong to the controller. Also if you want to update trips in another controller, for example by importing them from a csv file, you will have to repeat yourself and rewrite this code. Or you create a service object, i.e. TripUpdateService and use that in any place you need to update trips.

What are Service Objects?

Basically a service object is a Plain Old Ruby Object ("PORO"), a Ruby class that returns a predictable response and is designed to execute one single action. So it encapsulates a piece of business logic.

The job of a service object is to encapsulate functionality, execute one service, and provide a single point of failure. Using service objects also prevents developers from having to write the same code over and over again when it’s used in different parts of the application.

All service objects should have three things:

an initialization method
a single public method
return a predictable response after execution

Let's replace our controller logic by calling a service object for trip updates:

class TripsController < ApplicationController
  def update
    @trip = Trip.find(params[:id])
    if TripUpdateService.new(@trip, trip_params).update_trip
      redirect_to @trip
    else
      render :edit
    end
  end
end

Looks much cleaner, right? Now let's take a look at how do we implement a service object.

Implementing a Service Object

In a Rails app there are two folders which are commonly used for storing service objects: lib/services and app/services. Basically you can choose whichever you want, but we'll use app/services for this article.

So we'll add a new Ruby class (our service object) in app/services/trip_update_service.rb:

# app/services/trip_update_service.rb
class TripUpdateService
  def initialize(trip, params)
    @trip = trip
    @params = params
  end

  def update_trip
    distance_and_duration = calculate_trip_distance_and_duration(@params[:start_address],
                                                                 @params[:destination_address])
    @trip.update(@params.merge(distance_and_duration))
  end

  private

  def calculate_trip_distance_and_duration(start_address, destination_address)
    distance = Google::Maps.distance(start_address, destination_address)
    duration = Google::Maps.duration(start_address, destination_address)
    { distance: distance, duration: duration }
  end
end

Alright, service object added, now you can call TripUpdateService.new(trip, params).update_trip anywhere in your app, and it will work. Rails will load this object automatically because it autoloads everything under app/ folder.

This already looks pretty clean, but we can actually make it even better. We can make service object to execute itself when called, so we can make calls to it even shorter. If we want to reuse this behavior for other service objects, we can add a new class called BaseService or ApplicationService and inherit from it for our TripUpdateService:

# app/services/base_service.rb
class BaseService
  def self.call(*args, &block)
    new(*args, &block).call
  end
end

So this class method named call creates a new instance of the service object with arguments or block passed to it, and then calls the call method on that instance.Then we need to make our service to inherit from BaseService and implement call method:

# app/services/trip_update_service.rb
class TripUpdateService < BaseService
  def initialize(trip, params)
    @trip = trip
    @params = params
  end

  def call
    distance_and_duration = calculate_trip_distance_and_duration(@params[:start_address],
                                                                 @params[:destination_address])
    @trip.update(@params.merge(distance_and_duration))
  end

  private

  def calculate_trip_distance_and_duration(start_address, destination_address)
    distance = Google::Maps.distance(start_address, destination_address)
    duration = Google::Maps.duration(start_address, destination_address)
    { distance: distance, duration: duration }
  end
end

then let's update our controller action to call the service object correctly:

class TripsController < ApplicationController
  def update
    @trip = Trip.find(params[:id])
    if TripUpdateService.call(@trip, trip_params)
      redirect_to @trip
    else
      render :edit
    end
  end
end

Where should you put your service objects

As we've discussed earlier two base folders for storing service objects are: lib/services and app/services and you can use whichever you want.
Another good practice for storing your service objects will be storing them under different namespaces, i.e. you can have TripUpdateService, TripCreateService, TripDestroyService, SendTripService, and so on. But what will be common for all of them is that they're related to Trips. So we can put them under app/services/trips folder, in other words under the trips namespace:

# app/services/trips/trip_update_service.rb
module Trips
  class TripUpdateService < BaseService
    ...
  end
end

# app/services/trips/send_trip_service.rb
module Trips
  class SendTripService < BaseService
    ...
  end
end

Don't forget to use new namespace when calling those services, i.e. Trips::TripUpdateService.call(trip, params), Trips::SendTripService.call(trip, params).

Wrap your code in one transaction

If your service object is going to perform multiple updates for different objects, you better wrap it in a transaction block. In this case Rails will rollback the transaction (i.e. all of the performed db changes) if any of the service object methods fail. This is a good practice because it will keep your db in consistency in case of a failure.

# archive route with all of its trips
class RouteArchiver < BaseService
  ...
  def call
    ActiveRecord::Base.transaction do
      # first archive the route
      @route.archive!

      # then archive route trips
      trips = TripsArchiver.call(route: @route)

      # create a change log record
      CreatChangelogService.call(
        change: :archive,
        object: @route,
        associated: trips
      )

      # return response
      { success: true, message: "Route archived successfully" }
    end
  end
end

It's a simple example of updating multiple records in a single transaction. If any of the updates fails with an exception (e.g. route can't be archived, changelog create fails), the transaction will be rolled back and the db will be in a consistent state.

Passing Data to Service Objects and Returning Response

Basically you can pass to your service objects almost anything, depending on the operations they perform: ActiveRecord objects, hashes, arrays, strings, integers, etc. But you should always pass the minimum amount of data to your service objects. For example, if you want to update a trip, you should pass the trip object and the params hash, but you should not pass the whole params hash, because it will contain a lot of unnecessary data. So you should pass only the data you need, i.e. TripUpdateService.call(trip, trip_params).

Service Objects can perform complex operations. They can be used to modify records in the database, send emails, perform calculations or call 3d party APIs. So it's quite possible that something can go wrong during those operations. That's why it's a good practice to return a response from your service objects. You can return a boolean value, or a hash with a boolean value and some additional data. For example, if you want to update a trip, you can return a boolean value indicating whether the trip was updated successfully or not, and you can also return the trip object itself, so you can use it in your controller action.

The thing you should keep in mind though, is that your response from the service object should be predictable. It should always return the same response, no matter what. So if you return a boolean value, it should always return a boolean value, and if you return a hash, it should always return a hash with the same keys. This will make your service objects more predictable and easier to test.

What are the benefits of using Service Objects?

Service Objects are a great way to decouple your application logic from your controllers. You can use them to separate concerns and reuse them in different parts of your application. With this pattern you get multiple benefits:

Clean controllers. Controller shouldn't handle business logic. It should be only responsible for handling requests and turning the request params, sessions, and cookies into arguments that are passed into the service object to perform the action. And then perform redirect or render according to the service response.
Easier testing. Separation of business logic to service objects also allows you to test your service objects and your sontrollers independently.
Reusable Service Objects. A service object can be called from app controllers, background jobs, other service objects, etc. Whenever you need to perform a similar action, you can call the service object and it will do the work for you.
Separation of concerns. Rails controllers only see services and interact with the domain object using them. This decrease in coupling makes scalability easier, especially when you want to move from a monolith to a microservice. Your services can easily be extracted and moved to a new service with minimal modification.

Service Objects Best Practices

Name rails service objects in a way that makes it obvious what they're doing. The name of a service object must indicate what it does. With our trips example, we can name our service object like: TripUpdateService, TripUpdater, ModifyTrip, etc.
Service Object should have single public method. Other methods must be private and be accessible only within particular service object. You can call that single public method the way you want, just be consistent and use the same naming for all your service objects.
Group service objects under common namespaces. If you have a lot of service objects, you can group them under common namespaces. For example, if you have a lot of service objects related to trips, you can group them under Trips namespace, i.e. Trips::TripUpdateService, Trips::TripDestroyService, Trips::SendTripService, etc.
Use syntactic sugar for calling your service objects. Use proc syntax in your BaseService or ApplicationService and inherit from it in other services. then you can use just .call on your service object class name to perform an action, i.e. TripUpdateService.call(trip, params)
Don't forget to rescue exceptions. When service object fails, due to exception, those exceptions should be rescued and handled properly. They shopuld not propagate up to the call stack. And if an exception can't be handled correctly within the rescue block, you should raise custom exception specific to that particular service object.
Single responsibility. Try keeping single responsibility for each of your service objects. If you have a service object that does too many things, you can split it into multiple service objects.

Conclusion

Service objects are a great way to decouple your application logic from your controllers. They can be used to separate concerns and reuse them in different parts of your application. This pattern can make your application more testable and easier to maintain as you add more and more features. It also makes your application more scalable and easier to move from a monolith to a microservice. If you haven't used service objects before, you should definitely try it.
Btw, Ruby on Rails is used for this example only, you can use same pattern with other frameworks.

Hotwire: building responsive Rails apps

Aleksandr Ulanov — Mon, 08 Aug 2022 05:48:00 +0000

If you're developing modern single page applications with Ruby on Rails, you're most likely using some fancy JS framework for your UI to be updated nicely, without page reloads. And there is really not much you can do without using them, that's kind of a standard these days... until Rails got Hotwire.
With Hotwire you can get fast and responsive web application, but without writing ton of Javascript. Well, sounds great, but what is Hotwire? In this article we'll go through the basics of Hotwire, as well as build a sample app using it.

What options are there for responsive Rails apps?

On June 25, 2013, Rails 4 was released introducing Turbolinks. What Turbolinks are doing for "responsiveness" of Rails? Turbolinks intercept all link clicks and instead of sending regular GET request it sends asynchronous Javascript request (AJAX) to fetch HTML. It then merges the head tag of the fetched page and replaces the whole body tag of the page, so there is no full page reload. No stylesheets or scripts reloading, which meana a faster page navigation. But it still is replacing the whole body, not only changed parts of the page.

But what if you want to reload only parts that changed? Well, you could use Rails AJAX helpers, when you mark some elements as data-remote='true', which makes those element sending AJAX GET/POST requests instead of regular GET/POST requests. And Rails responds with generated JS code, which then is executed by the browser to dynamically update those parts of the page.

Then we can get to some JS components on the frontend (e.g. using React) to make an app feel even more responsive. So, JS component sends an AJAX request and Rails server responds to it with JSON data. Then frontend framework transforms received JSON to DOM elements and updates DOM to reflect those changes. And it works nice, the only downside is that it's mixing server side rendering and client side rendering on a page.

Another, more traditional way these days, is going all in and using React, Vue or another JS framework on the frontend to use only client-side rendering, i.e. so-called Single Page Application (SPA). With this approach frontend is a separate application which sends AJAX requests to the Rails server, and Rails is being solely a JSON API. As you probably know there's a whole lot of complexity of building, maintaining and deploying two separate apps with interchangeable data.

But what if you could build an SPA w/out all that complexity of building two separate apps and writing lots of Javascript code? Here's what Hotwire can help you with.

What is Hotwire?

Hotwire is an alternative approach to building SPA like web apps, rendering all of the HTML server side using Rails templates, while keeping the app fast and responsive. Keeping redering on server side makes you development experience simpler and more productive. Hotwire name basically is an abbreviation for HTML Over the Wire, which means sending generated HTML instead of JSON from the server to the client. It also does not require you to write much of custom javascript code. Hotwire is made of Turbo and Stimulus.

What is Turbo?

Turbo gem is the heart of Hotwire. It's a set of technologies to dynamically update the page, which speeds up navigation and form submission by dividing pages into components whiuch can be partially updated utilizing Websockets as a transport. If you ever worked with websockets in Rails, you most likely know that Rails is using ActionCable to handle websockets connection, and it's included in Rails by default. And Trubo gem consists of: Turbo Drive, Turbo Frames and Turbo Streams.

Turbo Drive

Turbo Drive is used to intercept links clicks (just like Turbolinks were doing it previously) and also intercept form submissions. Turbo Drive then merges the head tag of a page and replaces the body tag of the page. Same case as with Turbolinks, no full page reload, which maybe fast for some pages, but not really as responsive as the 2022 app is expected to be, so you might consider updating only some parts of the pages, not the whole body. Here's where Turboframes come in handy.

Turbo Frames

You can simply make a part of a page a Turbo Frame, by simply wrapping it in a turbo-frame tag with a unique id

<turbo-frame id="13">
  ...
</turbo-frame>

This makes any interactions within the frame to be scoped to that frame. Any interaction within that framne send an AJAX request to the Rails server, and server responds with an HTML only for that frame. Which allows Turbo to automatically replace only that frame on a page. And this does not require to write any Javascript.
But what if you want to update multiple parts of the page at the same time? That's what Turbo Streams can help you with.

Turbo Streams

When user interacts with an element on the page (e.g. form/link) and Turbo Drive sends an AJAX request to the server, the server responds with an HTML, consisting of Turbo Stream elements. And those are like directions for Turbo to follow in order to update affected parts of the page. Turbo Streams include seven available actions: append, prepend, (insert) before, (insert) after, replace, update, and remove:

<turbo-stream action="append" target="target_a">
  <template>
    HTML
  </template>
</turbo-stream>

<turbo-stream action="prepend" target="target_b">
  <template>
    HTML
  </template>
</turbo-stream>

<turbo-stream action="replace" target="target_c">
  <template>
    HTML
  </template>
</turbo-stream>

Turbo Streams are using ActionCable to deliver updates to multiple clients via websockets asynchronously. Again, you're getting all of this w/out writing any of the Javascript code. But even if you need some custom Javascript for any reason (e.g. some animation, datepicker, etc.), Hotwire got you covered here with Stimulus.

What is Stimulus?

Just like Rails which has its controllers with actions, Stimulus allows you to organize client side code in a similar way. You have a controller, which is a Javascript object, which defines actions, i.e. Javascript functions. Then you connect the controller action to interactive element on a page using HTML attributes. The action is then run in response, when DOM events are triggered.

Let's create a sample Rails app with Hotwire

Now having read all of the above, you might be wondering: how do I work with it? Hotwire is pretty simple to use, all that we need is a standard Rails app and Redis server.
First you need to have Ruby 3 and Rails 7 and Redis server to be installed, I'm not going to cover installation process of those, but you can easily find any instructions you need based on your platform.

So, let's setup a new Rails app (we'll be using Bootstrap as css option, just to make our app look a bit better):

rails new bookstore --css bootstrap

After Rails generated all the needed files, cd into the app directory:

cd bookstore

Rails 7 initial app has everything we need to start using Hotwire, the Gemfile includes: Redis gem, Turbo-rails gem and Stimulus-rails.
Make sure that you have Redis server up and running. Redis is required because it's used by ActionCable to store websockets related information.
The default address and port for Rails to connect to Redis server is set in the config/cable.yml

development:
  adapter: redis
  url: redis://localhost:6379/1

Then we can genertate our model, controller and migration, which will be "Books" in our case of Bookstore. It'll have a string title, description of type text and likes counter as integer:

rails g scaffold books title:string description:text likes:integer

Let's fix generated migration, so we have 0 likes by default for any book we add to the db:

class CreateBooks < ActiveRecord::Migration[7.0]
  def change
    create_table :books do |t|
      t.string :title
      t.text :description
      t.integer :likes, default: 0

      t.timestamps
    end
  end
end

Don't forget to create a database for our app, run in terminal:

rake db:create db:migrate

Lets make books list page the root page of the app, open config/routes.rb and add the missing root declaration:

Rails.application.routes.draw do
  root 'books#index'
  resources :books
end

Then you should be able to run rails server with rails server command or ./bin/dev (which will also watch css and js changes) in your terminal and, when you visit http://localhost:3000 in your browser, you should see something like this:

Let's change the Book partial app/views/books/_book.html.erb to this:

<%= turbo_stream_from "book_#{book.id}" %>

<%= turbo_frame_tag "book_#{book.id}" do %>
  <div style="background: lightblue; padding: 10px; width: 400px;">
    <h2><%= book.title %></h2>
    <p><%= book.description %></p>
    <br>
    <%= button_to "Like (#{book.likes})", book_path(book, book: { likes: (book.likes + 1) }), method: :put %>
  </div>
  <br/>
<% end %>

turbo_stream_from tells Hotwire to use websocket for updates of a frame identified with :book_id, and turbo_frame_tag identifies a frame, which can be replaced with partial on update.

To tell Turbo that we want to add each new created book to the start of the books list, and update likes count on each like button click, we need to add following callbacks to app/models/book.rb file (also let's add a validation):

class Book < ApplicationRecord
  after_create_commit { broadcast_prepend_to :books }
  after_update_commit { broadcast_replace_to "book_#{id}" }

  validates :title, :description, presence: true
end

First one tells Turbo to use :books Turbo Stream for updates on create, and second one tells to use :book_id to replace partial with updates.

Then let's fix the ordering in our books controller and also add the new book variable assignment (so we could create a book from the root path) in app/controllers/books_controller.rb:

...
def index
  @books = Book.order(created_at: :desc)
  @book = Book.new
end
...

We should also edit app/views/books/index.html.erb to add our Turbo Streams and Turbo Frames:

<h1>Books</h1>

<%= turbo_stream_from :books %>

<%= turbo_frame_tag :book_form do %>
  <%= render 'books/form', book: @book %>
<% end %>

<%= turbo_frame_tag :books do %>
  <%= render @books %>
<% end %>

To avoid redirects when we create a new book or update an existing one and stay on the same main page, we need to also edit create and update actions in app/controllers/books_controller.rb:

...
def create
  @book = Book.new(book_params)

  respond_to do |format|
    if @book.save
      format.html { redirect_to root_path }
    else
      format.turbo_stream { render turbo_stream: turbo_stream.replace(@book, partial: 'books/form', locals: { book: @book }) }
      format.html { render :new, status: :unprocessable_entity }
    end
  end
end

def update
  respond_to do |format|
    if @book.update(book_params)
      format.html { redirect_to root_path }
    else
      format.html { render :edit, status: :unprocessable_entity }
    end
  end
end

At this point, our bookstore app should look like this:

Any time you create a new book using the form on the main page, Turbo prepends it to the books list, w/out page reloads. If you open multiple tabs in the browser - it will update all of them. "Like" buttons are also working w/out page reloads and update likes counts for the book in all of the tabs. And all of this with not a single line of Javascript code. How cool is that?

Conclusion

This sample application is just a basic example of what you can do with Hotwire in Rails, but you can do much more complex things with Turbo and Stimulus.
So if you want to start a new SPA with Rails, think twice if you need React, Vue or any other framework on the frontend, it might be much more productive to give Hotwire a try. There's a big chance it will make you happy.

Building geospatial apps is easy with Redis

Aleksandr Ulanov — Mon, 08 Aug 2022 05:37:00 +0000

Working with geospatial data is notoriously difficult, because latitude and longitude are floating point numbers and should be very precise. In addition, it would seem that latitude and longitude can be represented as a grid, but in fact they can't, simply because Earth is not flat and math is hard.

For example, to determine the distance of a great circle between two points on a sphere, based on their latitude and longitude, the haversine formula is used, which looks like this:

Another common task related to latitude and longitude is finding the number of points in a radius on the Earth's surface. That is, given a large ball (Earth) and you are trying to find points in a radius on this ball. But Earth, in fact, is not a perfect sphere, it is still an ellipsoid. As you might guess, the mathematical calculations for such an operation become quite complex.

In this article, we'll look at how Redis can help us minimize calculations when working with geospatial data.

Redis, which stands for Remote Dictionary Server, is a fast, open source key-value data store. Because of its speed, Redis is a popular choice for caching, session management, gaming, analytics, geospatial data, and more.

Let's get back to geospatial data. What is geohash?

Geohash is a system representing coordinates as a string. Geohashing uses Base32 encoding to convert latitude and longitude to a string. For example, the geohash of the Palace Square in St. Petersburg will look like this: udtscze2chgq. A variable geohash length represents a variable position accuracy, in other words, the shorter is the geohash, the less precise are the coordinates it represents. That is, a shorter geohash will represent the same geolocation, but with less accuracy. You can try encoding coordinates in geohash at http://geohash.org.

How does Redis store geospatial data?

Geospatial data storage is implemented in Redis using sorted lists (ZSET) as the underlying data structure, but with on-the-fly encoding and decoding of location data and a new API. This means that indexing, searching and sorting by a specific location can be thrown into Redis with very few lines of code and minimal effort using the built-in commands: GEOADD, GEODIST, GEORADIUS and GEORADIUSBYMEMBER (GEOSEARCH).

Geo Set is the basis for working with geospatial data in Redis - it is a data structure designed to manage geospatial indexes. Each Geo Set consists of one or more elements, each of which consists of a unique identifier, and a pair of coordinates - longitude and latitude.

Commands for working with geospatial data

To add a new list (or a new element to an existing list) in a Redis store, use the GEOADD command. For clarity, I will give examples of commands in Redis, as well as in the Ruby client for working with Redis:

# Redis example:
GEOADD "buses" -74.00020246342898 40.717855101298305 "Bus A"

# Ruby example:
RedisClient.geoadd("buses", -74.00020246342898, 40.717855101298305, "Bus A")

These commands add to the Geo Set named "buses" the coordinates of the location for bus "Bus A". If a Geo Set with this name is not yet stored in Redis, it will be created. A new entry will only be added to the index if an entry with the same name ("Bus A") is not already in the list. That is, Bus A is a unique identifier.

It is also possible to add multiple records at once with a single GEOADD call, which can help reduce network and database load. Record IDs must be unique:

# Redis example:
GEOADD "buses" -74.00020246342898 40.717855101298305 "Bus A" -73.99472237472686 40.725856700515855 "Bus B"

# Ruby example:
RedisClient.geoadd("buses", -74.00020246342898, 40.717855101298305, "Bus A",
                           -73.99472237472686, 40.725856700515855, "Bus B")

The same command is used to update the index of a record. If GEOADD is called with entries already in the Geo Set, Redis simply updates the data for those entries, as soon as bus A starts moving, its location can be updated:

# Redis example:
GEOADD "buses" -76.99265963484487 38.87275545298483 "Bus A"

# Ruby example:
RedisClient.geoadd("buses", -76.99265963484487, 38.87275545298483, "Bus A")

In addition to adding and updating, of course entries can be removed from the index. The ZREM command is provided to remove an entry from a Geo Set in Redis. ZREM takes the name of the index to delete records from and the IDs of the records to be deleted:

# Redis example:
ZREM buses "Bus A" "Bus B"

# Ruby example:
RedisClient.zrem("buses", "Bis A", "Bus B")

The geo index can be deleted entirely and since it is stored as a Redis key, the DEL command can be used:

# Redis example:
DEL buses

# Ruby example:
RedisClient.del("buses")

However, using DEL for big lists can be a bad idea, since it can block Redis for a long time. So it might be better to always use UNLINK instead of DEL, i.e. 'non-blocking' delete:

# Redis example:
UNLINK buses

# Ruby example:
RedisClient.unlink("buses")

Keep in mind that Redis has a mechanism for indexes expiration, if you do not specify an expiration date for an index, then it will never be expired and will eat memory. To prevent this from happening, you need to use the EXPIRE command, passing the name of the index and the number of seconds for expiration:

# Redis example:
EXPIRE buses 1000

# Ruby example:
RedisClient.expire("buses", 1000)

Redis uses a semi-lazy expiration mechanism, which means that the index is not expired until it is not read, if it turns out that the expiration time has passed during the reading operation, then the result is not returned, and the object itself is deleted from the storage. That is, until we request a Geo Set, it will be stored in memory indefinitely.

However, Redis has a second level of expiration - it's active and random. It's a garbage collector that randomly reads different keys, and when the key is read, the standard mechanism for checking expiration occurs.

Unfortunately, Redis does not have the ability to directly expire records in the index. Such a feature will have to be developed independently.

What about reading and searching by geospatial data?
There are several ways to read entries from an index. You can use the ZRANGE and ZSCAN commands to get started. These commands iterate over all entries in the index. For example, to return all entries in an index:

# Redis example:
ZRANGE buses 0 -1

# Ruby example:
RedisClient.zrange("buses", 0, -1)

With respect to geospatial data, there are two commands to get the location of an entry from an index. The first - GEOPOS command returns the coordinates of the entry in the index:

# Redis example:
GEOPOS buses "Bus A"

# Ruby example:
RedisClient.geopos("buses", "Bus A")

The second command - GEOHASH returns the coordinates of the entry encoded in the geohash:

# Redis example:
GEOHASH buses "Bus A"

# Ruby example:
RedisClient.geohash("buses", "Bus A")

To get the distance between two entries in an index, you can use the GEODIST command:

# Redis example:
GEODIST buses "Bus A" "Bus B"

# Ruby example:
RedisClient.geodist("buses", "Bus A", "Bus B", "km")

The result of the command will be returned by default in meters. You can specify the required units of measurement by passing the fourth argument to the command, for example: km for kilometers, m for meters, mi - for miles, ft - for feet.

To search the index, the GEORADIUS and GEORADIUSBYMEMBER (for Redis versions less than 6.2) or GEOSEARCH (for versions older than 6.2) commands are also used.

GEORADIUS and GEORADIUSBYMEMBER accept the parameters WITHDIST (display results + distance from the specified point/record) and WITHCOORD (display results + record coordinates), as well as the ASC or DESC sort option (sort by distance from the point):

# Redis example:
GEORADIUS buses -73 40 200 km WITHDIST

# returns:
1) 1) "Bus A"
  2) "190.4424"
2) 1) "Bus B"
  2) "56.4413"

GEORADIUS buses -73 40 200 km WITHCOORD

# returns:
1) 1) "Bus A"
  2) 1) "-74.00020246342898"
     2) "40.717855101298305"
2) 1) "Bus B"
  2) 1) "-73.99472237472686
     2) "40.725856700515855"

GEORADIUS buses -73 40 200 km WITHDIST WITHCOORD

# returns:
1) 1) "Bus A"
  2) "190.4424"
  3) 1) "-74.00020246342898"
     2) "40.717855101298305"
2) 1) "Bus B"
  2) "56.4413"
  3) 1) "-73.99472237472686
     2) "40.725856700515855"

# Redis example:
GEORADIUSBYMEMBER buses "Bus A" 100 km

# returns:
1) “Bus B”

# Ruby example:
RedisClient.georadiusbymember("buses", "Bus A", 100, "km")

The GEOSEARCH command for new versions of Redis has a similar syntax and does the same thing. The command syntax looks like this:

# Redis examples:
GEOSEARCH buses FROMMEMBER "Bus A" BYRADIUS 100 km ASC WITHCOORD WITHDIST WITHHASH
# returns all entries in 100km radius from Bus A with coordinates, distances and geohashes

GEOSEARCH buses FROMLONLAT -74.00020246342898 40.717855101298305" BYRADIUS 200 mi DESC COUNT 2
# returns maximum 2 entries sorted from the farest to the closest within 200 miles from the center
# with given coordinates

Conclusion

The simplicity of implementing location apps with geospatial data in Redis not only makes it easy to handle large amounts of geospatial data, but also allows you to implement some complex processing for the data. For example, querying for entries within a radius can help you implement searching for points of interest nearby, by giving the user only the choices closest to them. If your application uses geospatial data in any way, consider moving complex calculations to Redis, it may increase the efficiency of your application.