Reference documentation for Jahuty's Ruby SDK.
This library requires Ruby 2.6+.
Add this line to your application’s
Gemfile and then run
Instantiate a client with your API key and call
You can also access the render’s content with
In an HTML view:
You can pass parameters into your snippet using the
The parameters above would be equivalent to assigning the variable below in your snippet:
You can use caching to control how frequently this library requests the latest content from Jahuty’s API.
- When content is in development (i.e., frequently changing and low traffic), you can use the default in-memory store to view content changes instantaneously with slower response times.
- When content is in production (i.e., more stable and high traffic), you can use persistent caching to update content less frequently and improve your application’s average response time.
Caching in memory (default)
By default, this library uses an in-memory cache to avoid requesting the same render more than once during the same request lifecycle. For example:
The in-memory cache only persists for the duration of the original request, however. At the end of the request’s lifecycle, the cache will be discarded. To store renders across requests, you need a persistent cache.
A persistent cache allows renders to be cached across multiple requests. This reduces the number of synchronous network requests to Jahuty’s API and improves your application’s average response time.
To configure Jahuty to use your persistent cache, pass a cache implementation to the client via the
cache configuration option:
The persistent cache implementation you choose and configure is up to you. There are many libraries available, and most frameworks provide their own. At this time, we support any object which responds to
set(key, value, expires_in:) or
write(key, value, expires_in:) including ActiveSupport::Cache::Store.
There are three methods for configuring this library’s
:expires_in, the amount of time between when a render is stored and when it’s considered stale. From lowest-to-highest precedence, the methods are:
- configuring your caching implementation,
- configuring this library’s default
- configuring a render’s
Configuring your caching implementation
You can usually configure your caching implementation with a default
:expires_in. If no other
:expires_in is configured, this library will defer to the caching implementation’s default
Configuring the library
You can configure a default
:expires_in for all of this library’s renders by passing an integer number of seconds via the client’s
:expires_in configuration option:
If this library’s default
:expires_in is set, it will take precedence over the default
:expires_is of the caching implementation.
Configuring a render
You can configure a single render’s
:expires_in by passing an integer number of seconds via its
:expires_in configuration option:
If a render’s
:expires_in is set, it will take precedence over the library’s default
:expires_in and the caching implementation’s
You can disable caching, even the default in-memory caching, by passing an
:expires_in of zero (
0) or a negative integer (e.g.,
-1) via any of the methods described above. For example:
If an error occurs with Jahuty’s API, a
Jahuty::Exception::Error exception will be raised:
If you’d like to see the SDK in action, see jahuty/jahuty-ruby-example.
Bug reports and pull requests are welcome on GitHub.
Find a typo? Something is wrong in this documentation? Fork and edit it!