Delayed Job is a great and simple solution for background jobs in a Rails application. But if you don’t have the memory or resources to run a background thread 24 hours on a server what do you do?

We were in a similar situation for a client, who was strictly on a shoe string budget, running on Heroku. The background job was to process some applications, verify and sent emails if they had errors. This was to be done once a day. Running a background job just for this was a bad choice.

Another option was to run this as a rake task, at a set time, use Heroku Scheduler to run this at 04:00am every day. But we wanted to try a bit more generic solution.

We decided to stick to write Delayed Job classes, so that in future, it can serve both the purposes.

1. For more background processing, more jobs we just have to write new classes with perform methods
2. When the app is moved into it’s own private hosting VPS, run a background thread more often, to scale it.

But in the current setup, we had to run the jobs as a rake task, triggered once a day at a specific time, while leaving room for a full fledged background process in the future.

Looking at the delayed_job source at Github we figured that this could be easily implemented. It internally creates a Delayed::Worker class and works off all the jobs in the delayed_jobs table.

The solution was really simple. Create a rake task in lib/tasks/delayed_job.rake

# File lib/tasks/delayed_job.rake

namespace :delayed_job do 
  desc 'Run Delayed job worker' 
  task work: :environment do 
    worker = Delayed::Worker.new worker.work_off 
    #by default runs 100 rows 
  end 
end

For more information on the sources:

• The rake task for starting delayed job — delayed/tasks.rb
• The Delayed::Worker start — delayed/worker.rb
• Delayed::Worker work_off definition — delayed/worker.rb#work_off

If you found this article useful, please click on the 👏 button a few times to make others find the article and show your support!

Originally published at blog.hash32.com on March 4, 2019. Credits - Header photo by Elisa Michelet on Unsplash.

Delayed Job as a Rake Task was originally published in Neumeral on Medium, where people are continuing the conversation by highlighting and responding to this story.

All that is possible by running Rails as a rack application. See how below.

First things first - so what is Rack?

Rack provides a modular interface for developing web apps in Ruby. A Rack::Handler connects webservers with Rack. By default it ships with handlers for many Ruby servers like Thin and WEBRick. It also provides a handy rackup commandline tool, which internally starts a Rack::Server.

Any object that responds to a call function and takes an env hash as parameter, returning an Array with the http response code, hash of headers, and a response body that can respond to each.

For example the below instance of the class RunMe. You can run this with a Rack Handler.

Save all of this in a server.rb and run it with ruby server.rb.

The rackup command line tool can be used, in which case you can forego the explicit use of the WEBrick handler. rackup internally calls Rack::Server.start

Running the Rails Application on Rack

When rails server is called the start method of Rails::Server is called. Rails::Server inherits from Rack::Server.

Rails::Application is an class with a call function and has all the properties of [1]. So if we define a class that inherits from Rails::Application we can serve it with.

So lets create a simple Rails::Application. Create a file named config.ru as follows:

This just prints ‘Hello World’. For a more useful experiment, you can define a controller and render a template.

Lets create a PagesController that renders some html inline.

This right here, is a Rails application in a single file, with just 16 lines of Ruby. Well pretty small, huh! If you need to build something useful with this, it will be well beyond 16 lines of course, but you can fit all of it in a single file.

You can use this for running specialized applications on Rack, with the features of Rails, and you can pick and choose which ones. Load only the libraries and middlewares you use in Rails and run the app on Rack.

You can split up the views to a separate folder, models into separate files and use require_relative to use them. Or organize folders based on functionality. Or bring a folder structure that fit your needs.

You can find the source for this article, and more examples in the https://github.com/HASH32/rails-and-rack repository.

References

• Read the official Ruby on Rails guide on Rails on Rack.
• Watch this talk by José Valim — You’ve got a Sinatra on your Rails

PS: This article was originally posted in HASH32 Engineering Blog.

If you found this article useful, please click on the 👏 button a few times to make others find the article and show your support!

Don’t forget to follow me, to get notified of upcoming articles like these.

How small can a Ruby on Rails app be? was originally published in Neumeral on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Using rack_mini_profiler gem

Install it by adding the gem 'rack_mini_profiler' to your Gemfile. If you append your url with the pp parameter, you will get to see some options for Rack Mini Profiler.

For example, running locally http://localhost:3000/?pp=help — shows the help screen.

Memory Profiling

To find which gems and files are using the memory, accessing the url http://localhost:3000/?pp=profile-memory — will show the memory profile.

This requires gem 'memory_profiler' to be added to the Gemfile.

As you can see above, gems like newrelic_rpm, meta_requests etc are adding to the memory consumed by the Rails app; so its important to add them to the right group in the Gemfile.

Flamegraph of the Stack

Add the following gems to show the flamegraph of the call stack with rack_mini_profiler.

gem 'flamegraph' gem 'stackprof'

It can show the flamegraph of the call stack. For more about how to interpret the famegraph read Rails App’s Performance blog post by Justin Weiss.

2. Rails Panel

If you are using Google Chrome, there is a handy Chrome extension called Rails Panel. Download it from the chrome web store.

This extension will show you the breakdown of time taken in Rendering, ActiveRecord etc.

The gem 'meta_request' needs to be added to the development group in the Gemfile, for the data to appear in Rails panel.

3. Scout DevTrace

Using the scout agent (add gem 'scout_apm' in the Gemfile) in development mode will show a beautiful panel with the breakdown of time consumed in various sections - Views, Middleware, ActiveRecord, controllers etc. It also shows N+1 queries and backtraces.

You need to start the server with the environment variable SCOUT_DEV_TRACE=true for this.

$ SCOUT_DEV_TRACE=true be rails server

4. Derailed Benchmarks

Derailed Benchmarks gem can be used for a variety of tasks. Well, the gem has packaged common performance into rake tasks. Read the code here — derailed_benchmarks#tasks.rb.

Gem-wise memory consumption

Running the following command will give the list of gems used in the app, along with the memory they consume.

bundle exec derailed bundle:mem

Identify memory leaks

For running memory and stack profilers you need to prepare your app to run in RAILS_ENV=production. The following needs to be taken care of:

• Disable ssl configuration for the test config.force_ssl = false in environments/production.rb. Troubleshooting - Read this Gist.
• Check database for production and the secrets file.
• Use the same server as you use in production. Derailed by default uses Rack::Mock by default.
• Configure authentication as per the documentation.

Running perf:mem_over_time will boot up the app and show the memory consumed by the app, as its hit by a larger amount of requests.

USE_SERVER=puma bundle exec derailed exec perf:mem_over_time

If the memory remains constant after a point, then the app does not have any memory leaks. But if the memory keeps increasing, it is an indication of a memory leak.

You can debug further by looking at the objects in the memory

bundle exec derailed exec perf:objects 

# OR get a Heap Dump 
bundle exec derailed exec perf:heap

5. Using fasterer gem

fasterer gem is not exactly a monitoring tool, but it will give suggestions on Ruby speed improvements. This is not Rails specific, but generic Ruby.

There is also a fast-ruby repo, which has benchmarks of fast and slow Ruby code.

6. Using bullet gem

Eliminating N+1 queries can improve the application speed drastically.
Use the bullet gem to identify and remove N+1 queries.

7. Newrelic Agent

The developer panel of Newrelic has been removed in the newer editons of the gem.
For viewing this an old gem version '~> 4.0.0' has to be used.

gem 'newrelic_rpm', '4.0.0.332'

If you found this article useful, please click on the 👏 button a few times to make others find the article and show your support!

Credits: Header photo by Markus Spiske on Unsplash.

Rails Performance Monitoring Tools Compared was originally published in Neumeral on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post let’s see how to create GraphQL mutations to add a speaker to our database.

In Part 1 of this series talks about how to set things up, and how to define a query to get a list of Speakers from our Conference GraphQL API.

GraphQL server with Sinatra (Ruby) — Part 1

A mutation is something that mutates or changes the data in the server. In DB terms, if we need to change the data in a table using graphql we need mutations — be it an INSERT, UPDATE or DELETE. Only SELECTs are covered with a Query.

Note: Updated to the new class-based API, which was introduced in version 1.8 of the gem. While the define DSL based syntax will still work, it will eventually get removed in version 2.0.

So to add a new speaker to the database we need a mutation.

In the GraphQL language, a mutation is of the form

mutation AddSpeaker($name:String, $talkTitle:String) {
  createSpeaker(name: $name, talkTitle:$talkTitle) {
    success
    errors
  }
}

A set of “query” variables needs to be supplied to the GraphQL endpoint.
Say for example,

{
  "name": "John Doe",
  "talkTitle": "Introduction to GraphQL in Ruby"
}

Read more about GraphQL mutations and its syntax in the specifications — https://graphql.org/learn/queries/#mutations

For our little server to accept mutations, we need to make some changes and add more files for defining mutations. Lets see how, step-by-step.

STEP 5: Adding a Mutation root type

A mutation root MutationType has to be created and it should then be added to our Schema, like the QueryType that was added in the last post.

STEP 6: Define a Mutation for speaker creation

Next, we need to tell GraphQL about the parameters that needs to be accepted for creating a new speaker.

Let’s split this into a separate file, that handles this mutation — create_speaker.rb. Instead of inheriting from GraphQL::Schema::Mutation we create a mutation base class Mutations::BaseMutation. Also lets group all the mutations in mutations folder.

It needs to accept all the fields for a speaker, which we created as strings in the DB. In GraphQL ruby, strings are represented with the String type, as defined in the gem.

Next we need to take these fields and then call speaker.save with the defined input fields in the resolve function.

This returns a hash with success and errors. We need to tell GraphQL about it as well. Note: errors is an array of Strings. We define these as fields in the mutation.

Now the CreateSpeaker mutation is complete. It needs to be added to the root mutation — MutationType so that it gets included in the schema.

Restart the server with bundle exec puma.

If you use a client like GraphiQL, you should be able to see the docs in the right sidebar changes and now has a Mutation.

Add a new speaker, with the mutation and the query variables in the client.

Execute the mutation in the GraphiQL client. You should be able to see the response data json, with something like below:

The CreateSpeaker mutation has all the fields optional, but the Speaker model validates the presence of the name field. If you try to create a speaker without giving a name field, it will show up in errors return field.

We can avoid this validation at the schema level, by making the required argument mandatory. You just need to change null: false to the respective arguments.

Now the name and talk_title fields are non-nullable fields, and you’ll have to always give these fields when executing the mutation. Read about the type system in the official documentation.

Show me the code

You can see all the code for this post in the sinatra-graphql Github repository.

If you found this article useful, please click on the 👏 button a few times to make others find the article and show your support!

Don’t forget to follow me, to get notified of upcoming articles like these.

GraphQL with Sinatra (Ruby) — Part 2— Mutations was originally published in Neumeral on Medium, where people are continuing the conversation by highlighting and responding to this story.

Updated to the new class-based API, graphql gem version 1.8+

GraphQL has redefined the way we deal with APIs and endpoints. With the client being able to specify the fields it needs, development in the client could in one way be independent of the server changes, if a schema is predefined.

We’ll see how to create a GraphQL server using the Sinatra framework in Ruby. In this example we will be creating the schema for a conference app, where you can add speakers and list them.

STEP 1: Create a Sinatra application

I wish there was a template to create a sinatra application using a cli. But there isn’t a lot of boilerplate files to create, so lets add it one-by-one.

We’ll be using puma as the server. Create an app.rb file which defines a basic sinatra app with a / route. Also a Gemfile is added and bundle install is run.

Next we need a rackup file config.ru so that puma will pickup the app as a rack application.

Running the puma server will serve your application at http://localhost:9292, and you should see the message ‘It Works!’.

bundle exec puma

Yay! The app is up.

STEP 2: Add JSON responses

For the server to respond to JSON, we add the sinatra-contrib gem, which adds a json helper. Change the app.rb file to respond to json.

Now our app contains just these files:

conference_app
  |
  ├── Gemfile
  ├── Gemfile.lock
  ├── app.rb
  └── config.ru

STEP 3: Add database connections and models with ActiveRecord

For talking to the database, we’ll use activerecord gem.

Add database configuration to connect to sqlite3

Also add a configuration file database.yml with the connection details and the sqlite3 gem for connecting to the sqlite database. app.rb needs changes to update this configuration.

Add Rakefile

Add the rake gem along with the Rakefile. This gives handy rake tasks for creating the table (migrations) and managing them.

bundle exec rake -T will display the added rake tasks.

Create the sqlite database, by running bundle exec rake db:create

Add a migration and model for Speaker object

Create a migration with the following rake command:

bundle exec rake db:create_migration NAME=create_speakers

Change the created migration file in db/migrate folder, to add the required database fields.

Run migrations with the rake task bundle exec rake db:migrate

Create a model file for Speaker, to access this table.

I’ve added a basic validation for the model. Read more on activerecord basics in the official basics introduction.

Add the pry gem for debugging and execute the following two statements in the pry console, for adding rows to the speakers table.

require './app'

Speaker.create(name: 'John', twitter_handle: 'johnruby', bio: 'This is John\'s bio', talk_title: 'How to bootstrap a sinatra application')

Speaker.create(name: 'Jacob', twitter_handle: 'jacob-ruby', bio: 'This is Jacob\'s bio', talk_title: 'Introduction to graphql')

Add a /speakers endpoint

Create a new endpoint to show the list of speakers, as JSON.

STEP 4: Add graphql and define a query to list speakers

Now we have a sinatra app that connects to the database and shows a list of speakers as a JSON response. Now let’s add graphql and define a schema for speakers.

Add the graphql gem. https://github.com/rmosolgo/graphql-ruby. Read the documentation at http://graphql-ruby.org/.

Also the rack-contrib gem needs to be added so that the sinatra app can accept raw JSON payloads.

Add type, query and schema for graphql

Now we need to add a type for Speaker, also a query and a schema for GraphQL.

We need to then add a root query.

Define a schema for GraphQL.

The /graphql endpoint

We now need to have a POST endpoint for GraphQL.

GraphQL schema can be executed to give a GraphQL::Query::Result which can then be converted to JSON. app.rb needs change to include this endpoint.

Querying the endpoint

You can use the GraphiQL app or the Postman app to query the endpoint. Make sure that you have puma running and the server is up.

A JSON response like the below will be obtained.

That’s it for now. You have a GraphQL server up and running on sinatra, and you can query the endpoint to get a list of speakers with the fields defined in the GraphQL query.

Source Code

The source code is available at https://github.com/awinabi/sinatra-graphql

In Part 2 of this series, we’ll see how to add a mutation to add a new Speaker.

GraphQL with Sinatra (Ruby) — Part 2— Mutations

If you found this article useful, please click on the 👏 button a few times to make others find the article and show your support!

Don’t forget to follow me, to get notified of upcoming articles like these.

GraphQL server with Sinatra (Ruby) — Part 1 was originally published in Neumeral on Medium, where people are continuing the conversation by highlighting and responding to this story.