DEV Community: Rodrigo Walter Ehresmann

React App From Scratch and Deploy to Heroku

Rodrigo Walter Ehresmann — Fri, 21 Jan 2022 12:23:54 +0000

Tired of using CRA (Create React App) for everything? This post is for you. In this post, we'll set up what could be used as the base for you to create your own React project template, already ready for deploying to Heroku.

Note: If you try to code along with this post, be aware of the packages versions I'm using, though. For reference, the final package.json is listed right after the Conclusion section of this post.

Create your project folder, run npm init --y to create your package.json, and let's start!

React Installation and Package Structure

We'll start installing what we need about react with npm install react react-dom.

Now create two folders:

build: Where your built app will be placed;
src: Where your actual app components will be placed;
public: Where we'll put our static files.

Populate your src folder with two files:

App.js, the main component of your application:

import React from "react";

function App() {
  return <div>Hello World!</div>
}

export default App;

index.js, the entry point of your application:

import React from "react";
import ReactDom from "react-dom";
import App from "./App";

ReactDom.render(
  <App />,
  document.getElementById("root")
);

Did you notice we need an html element with id root to make this work? Don't worry about it, it's our next step.

Webpack and Project Up!

Webpack is our project bundler, the one responsible for getting our javascript files and making them usable in the browser. Install the necessary webpack packages with npm install webpack webpack-cli --save-dev.

In your project root folder, create the webpack.config.js. This is the basic structure we'll fill:

module.exports = {
  mode: "development",
  entry: "",
  output: {
  },
  plugins: [],
  module: {},
}

mode: If you're running in production or development. You can use an ENV variable to determine the environment if you want (e.g., process.env.MY_ENV);
entry: The entry point of our application, or in other words, from where the bundler must start looking in order to bundle our application;
output: Output interface to configure where the bundled files should be placed;
plugins: Plugins interface in case we wanna use any plugin;
module: Interface to configure Webpack dependencies if you have any.

Let's start with the module. You probably know about Babel to get browser compatible-javascript, and I wanna make it available through Webpack module. Also, you probably will need some Babel presets (a.k.a., Babel plugins to support particular language features), so install everything with npm install @babel/core babel-loader @babel/preset-env @babel/preset-react --save-dev, and update your webpack module to be like this:

module:{
    rules:[
      {
        test:/\.js$/,
        exclude:/node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env','@babel/preset-react']
          }
        }
      },
    ]
},

I'll not elaborate about these presets and how rules are configurated, you can search more about it if you're interested, and keep in mind those configurations aren't something you need to memorize because you'll usually find them in the npm package description.

Going next for the entry, we simply set it to our application entry point:

...

entry: './src/index.js',

...

For the output we want to have our bundled files to be placed in a single file named bundle.js inside our build folder:

const path = require('path'); // add this at the top of your webpack.config.js
...

  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'build'),
  },

...

This bundle file will be loaded through a <script> tag in your index.html file. But here is the question: how do we generate this bundle file? First off, let's create our index.html inside our public folder:

<html>
   <head>
      <title>React App From Scratch</title>
   </head>
   <body>
      <div id="root"></div>
   </body>
</html>

Note: it's just a simple html you can update the way you want, just don't forget to keep <div id="root"></div> because is where we specified that the App component will be rendered (back to our index.js).

Now we can add the package npm install html-webpack-plugin --save-dev that will handle the bundle.js generation. Update the plugins with this:

...

const HtmlWebPackPlugin = require("html-webpack-plugin");

...

plugins:[
  new HtmlWebPackPlugin({
    template: path.resolve( __dirname, 'public/index.html' ),
    filename: 'index.html'
  })
],

...

When we build our application, a default index.html will be generated if we use HtmlWebPackPlugin template and filename. We don't wanna have the default one, though, so we're saying to template it with our public/index.html and name it with this same filename.

Before we can run our app, add the server boot script inside scripts of your package.json: "dev": "webpack-dev-server". We also need to add in our webpack.config.js the option indicating we're using a dev server ():

...

devServer: {},

...

For reference, here is the final version of our webpack.config.js and package.json:

const path = require('path');
const HtmlWebPackPlugin = require("html-webpack-plugin");

module.exports = {
  mode: "development",
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'build'),
  },  
  plugins:[
    new HtmlWebPackPlugin({
      template: path.resolve( __dirname, 'public/index.html' ),
      filename: 'index.html'
    })
  ],
  module:{
      rules:[
        {
          test:/\.js$/,
          exclude:/node_modules/,
          use: {
            loader: 'babel-loader',
            options: {
              presets: ['@babel/preset-env','@babel/preset-react']
            }
          }
        },
      ]
  },
  devServer: {},
}

// package.json
{
  "name": "react-app-from-scratch",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "dev": "webpack-dev-server"
  },
  "author": "",
  "license": "MIT",
  "dependencies": {
    "react": "^17.0.2",
    "react-dom": "^17.0.2"
  },
  "devDependencies": {
    "@babel/core": "^7.16.7",
    "@babel/preset-env": "^7.16.7",
    "@babel/preset-react": "^7.16.7",
    "babel-loader": "^8.2.3",
    "html-webpack-plugin": "^5.5.0",
    "webpack": "^5.65.0",
    "webpack-cli": "^4.9.1",
    "webpack-dev-server": "^4.7.2"
  }
}

Just run npm run dev and your server is up! We didn't change the default port of the server, so you'll be able to see our "Hello World!" message accessing http://localhost:8080.

Deploy to Heroku

To deploy to Heroku we need beforehand:

A web server: we're essentially serving static files, and Heroku requires a web server. We can create our own webserver to simply serve the static files;
npm run build npm run start command: those commands are the default ones Heroku will run to build and start our application.

Run npm install express that we'll use to create our node server. In your root repository create your server.js:

const path = require('path');
const express = require('express');

const app = express();

app.use(express.static(path.join(__dirname, 'build')));
app.set('port', process.env.PORT || 3000);

const server = app.listen(app.get('port'), function() {
  console.log('listening on port ', server.address().port);
});

This is the most basic node server snippet you'll find over the internet, and the magic happens here app.use(express.static(path.join(__dirname, 'build'))): we're saying that our built app is inside the build folder, and those files should be served as static.

Now we finish adding the build and start scripts in our package.json:

{
  "name": "react-app-from-scratch",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "dev": "webpack-dev-server",
    "start": "node server.js",
    "build": "webpack --config ./webpack.config.js --mode='production'"
  },
  "author": "",
  "license": "MIT",
  "dependencies": {
    "express": "^4.17.2",
    "react": "^17.0.2",
    "react-dom": "^17.0.2"
  },
  "devDependencies": {
    "@babel/core": "^7.16.7",
    "@babel/preset-env": "^7.16.7",
    "@babel/preset-react": "^7.16.7",
    "babel-loader": "^8.2.3",
    "html-webpack-plugin": "^5.5.0",
    "webpack": "^5.65.0",
    "webpack-cli": "^4.9.1",
    "webpack-dev-server": "^4.7.2"
  }
}

You can test if everything is working properly running your newly added scripts: npm run build and npm run start. You should be able to see our "Hello, World!" message again, now on http://localhost:3000.

And this is it, you are ready to deploy to Heroku!

Note: Just ensure yourself that heroku/nodejs buildpack is present in your Heroku app. Probably is, because already comes by default when you create your app!

Conclusion

This post shows how you can create your React app by scratch. It was explained the basics of the webpack configuration file, and how you can create your webserver to deploy your application to Heroku.

Bear in mind that those configurations don't deliver you a template for a React app ready for production, there's a lot more to be done before you can say this, like server routing, code splitting, etc. But with what it's presented here you have a start point in order to start building your own template, in case you just don't wanna use something like CRA.

This is it! If you have any comments or suggestions, don't hold back, let me know.

Options if you like my content and would like to support me directly (never required, but much appreciated):

BTC address: bc1q5l93xue3hxrrwdjxcqyjhaxfw6vz0ycdw2sg06

A Bit of Advanced ActiveRecord Querying - With Benchmarks

Rodrigo Walter Ehresmann — Sun, 16 Jan 2022 13:55:35 +0000

Introduction

The SQL provides us many features to query with efficiency: sub-queries, custom joins, aggregations, etc. We can use all of this with an ORM like ActiveRecord, however often we ignore it. Why? I believe there are three main reasons for this:

You're not an advanced user of SQL;
You don't know enough of ActiveRecord to use its advanced features;
You simply are attained to some bad habits because of the facilities of your programming language (after all, it's much simpler to iterate over ruby objects doing simply comparisons than thinking in a complex custom join, right?).

All good with that until you don't face the side-effects of poor writing code: memory leak and low performance.

This post has the intention of deepening a little bit more in what ActiveRecord can do to help you avoid the problems mentioned above, and benchmark the ActiveRecord approach with some other solution using a ruby Enumerable.

Note: If you wanna follow along with the coding of this post, you can use this script with all the data, queries, and comparisons I used.

Domain

In this post, a simplified version of a Cryptocurrency Exchange will be used as a domain. To better understand what it's being queried in the next sections, here is an explanation of the meaning of each table:

networks: The networks with a running blockchain, each one working with a specific set of currencies;
currencies: Cryptocurrencies;
currency_networks: An association table linking a currency to a network, meaning that this currency can be processed in the specified network;
pairs: A pair of currencies that can be traded, e.g., "BTC-ETH" means "buying ETH (quote currency) with BTC (base currency)";
tickers: Last 24h information from a specific currency pair.

It's not in the scope of this post to discuss anything related to the right way of modeling this domain. The domain was built just thinking in exemplifying queries.

Querying `belongs_to` associations

Consider the following domain models:

class Network < ActiveRecord::Base
  has_many :currency_networks
  has_many :currencies, through: :currency_networks
end

class Currency < ActiveRecord::Base
  has_many :currency_networks
  has_many :networks, through: :currency_networks
end

class CurrencyNetwork < ActiveRecord::Base
  belongs_to :currency
  belongs_to :network
end

Let's say we wanna have all currency networks where the network is active. We can solve this using a ruby Enumerable:

CurrencyNetwork.all.select { |cn| cn.network.active? }

Although that solves our problem, we're potentially scaling to new ones:

Our select block is hitting the database for each CurrencyNetwork we retrieved;
We're retrieving more data than we really need with cn.network: we don't wanna retrieve the Network data, just the CurrencyNetwork. Bare in mind that when we call cn.network we are instantiating a new ActiveRecord object to store the Network result, consuming more memory than needed.

Those aren't big problems to a situation where we don't have many records in the database, as in the case of the script I'm running to exemplify this command, but you can imagine what that cause for your application depending on how frequent you run this action and the number of rows in your database.

We can improve this by delegating great part of the heavy lifting to our database doing this:

CurrencyNetwork.joins(:network).where(networks: { active: true })

If we append to_sql at the end of this query we can see the SQL that's producing:

SELECT "currency_networks".* 
  FROM "currency_networks" 
  INNER JOIN "networks" 
  ON "networks"."id" = "currency_networks"."network_id"

joins is a powerful resource responsible for joining our tables (INNER JOIN), what we can do because CurrencyNetwork belongs_to :network (specified on the ON clause). ActiveRecord provides us a clean way to access the table attributes from our belongs_to association with the hash syntax: { networks: { active: true } }.

What are the benefits of your query approach:

Performance: We only hit the database once, compared to the potentially thousands of times with the Enumerable solution;
Spare memory: We only receive ActiveRecord instances from CurrencyNetwork instead of the Network instances that came as plus with the Enumerable solution.

We don't need to rely upon a priori reasoning only, we can use memory_profiles and benchmark_ips to compare the memory consumption and iterations per second of each solution.

Belongs to query - Enumerable solution (memory profiler):
Total allocated: 120236 bytes (1290 objects)
Total retained:  27100 bytes (224 objects)

Belongs to query - ActiveRecord query solution (memory profiler):
Total allocated: 4584 bytes (52 objects)
Total retained:  360 bytes (7 objects)

Considering how the database was populated in the script used for this test, with the query solution we consume ~26x less memory with the total allocations and ~75x less memory with retained allocations.

IPS - Belongs to query - ActiveRecord query solution:    17716.1 i/s
IPS - Belongs to query - Enumerable solution:      656.8 i/s - 26.97x  (± 0.00) slower

Comparing the iterations per second, we can check that the Enumerable solution is 26.97x slower.

Querying `has_many` associations

Consider the same domain models of the previous section. We wanna do a slightly similar query that the previous one, but now our result must be the currencies belonging to active networks.

Enumerable solution:

Currency.all.select { |currency| currency.networks.where(active: true).any? }

In this example, I'm doing things propositional worse mixing a query with a where clause, but this is probably with what you'd come up to if not using joins.

ActiveRecord query solution:

Currency
  .joins(currency_networks: :network)
  .where(networks: { active: true })

You can notice that we use the same interface to query has_many as the one used with belongs_to, so there's nothing new here besides the pluralized relationship name in the joins.

The benefits are the same we saw in the previous section, and we can benchmark both approaches here too:

Has many query - Enumerable solution (memory profiler):
Total allocated: 171024 bytes (2107 objects)
Total retained:  24566 bytes (243 objects)

Has many query - ActiveRecord query solution (memory profiler):
Total allocated: 4464 bytes (50 objects)
Total retained:  280 bytes (6 objects)

We can see an, even more, accentuated memory consumption in this case with the Enumerable solution. The ActiveRecord query solution consumed ~38x less memory in the total allocated, and ~87x less memory in the total retained.

IPS - Has many query - ActiveRecord query solution:    23395.8 i/s
IPS - Has many query - Enumerable solution:      569.6 i/s - 41.08x  (± 0.00) slower

No surprise, the Enumerator solution is 41.08x slower.

Querying With Aggregations and Subqueries

Aggregations are actions that imply in perform any mathematical operation in your data, be it counts, sums, averages calculations, or comparisons to retrieve maximums and minimums.

Consider the following domain models:

class Currency < ActiveRecord::Base
  has_many :currency_networks
  has_many :networks, through: :currency_networks
  has_many :pairs_as_base, class_name: "Pair", foreign_key: :base_currency_id
  has_many :pairs_as_quote, class_name: "Pair", foreign_key: :quote_currency_id
end

class Pair < ActiveRecord::Base
  has_many :tickers

  belongs_to :base_currency, class_name: "Currency", foreign_key: :base_currency_id
  belongs_to :quote_currency, class_name: "Currency", foreign_key: :quote_currency_id
end

class Ticker < ActiveRecord::Base
  belongs_to :pair

  validates_presence_of :trade_count
end

Using aggregation we can answer how many trades were performed in all pairs:

Ticker.avg(:trade_count)
# => 458926.666666667

We deliver the heavy lifting of looking at each ticker record and performing the calculation to our database, which is good. At this point, you already have a notion of the performance improvement of ActiveRecord queries over Enumerable based solutions to do the same, so I'll spare you of the performance metrics in more simple examples like this one.

Bear in mind the result of this query I added as commentary in the snippet above: it's an integer, not an ActiveRecord relation. So it's not possible to keep chaining queries after calling an aggregation on that way.

You can expect another outcome if you're using aggregation over grouped columns. Let's say we wanna retrieve the sum of trade_count for each currency that is a base_currency of a Pair:

Currency
  .joins(pairs_as_base: :tickers)
  .group("currencies.name").sum(:trade_count)
# => {"Bitcoin"=>930518, "Ethereum"=>103466, "Polkadot"=>342796}

As a result, you have a hash with your aggregated answer.

Subqueries

Subqueries are queries inside queries, and can be placed basically anywhere in your query: SELECT, WHERE, FROM, etc. You can perform interesting queries combining aggregations with subqueries.

Let's say we wanna list all pairs are inside tickers that have the trade_count above the average trade counts of all tickers:

# Hits the database twice
Pair
  .joins(:tickers)
  .where("trade_count >= :avg", avg: Ticker.average(:trade_count))

# Hits the database only once
Pair
  .joins(:tickers)
  .where("trade_count >= (:avg)", avg: Ticker.select("AVG(trade_count)"))

Why the first query hits the database twice, and the second query only once? It's a detail of the ActiveRecord syntax.

Remember what we saw just before: calling the aggregation method as a ruby method directly from ActiveRecord object returns to us a number, and that can only be done by executing the query. So Ticker.average(:trade_count) is returning a number, and ActiveRecord is replacing :avg with it.

If you wanna have lazy using aggregation inside a query, we explicitly express the aggregation as an SQL function like here Ticker.select("AVG(trade_count)"). In the example of the single database hit, ActiveRecord is taking this query and injecting it in place of :avg. Be aware that here we're calling (:avg)! That's because a subquery must be evaluated inside (), otherwise an error will be raised. Appending to_sql in the single database hit query we can see the query that's performed:

SELECT "tickers".* 
  FROM "tickers" 
  WHERE (trade_count > (SELECT AVG(trade_count) FROM "tickers"))

Following to another query, we could ask now for the tickers that have their trade_count above or equal the average trade_count of all listed tickers:

avg_trade_count_sql = Ticker.select("AVG(trade_count)").to_sql
Ticker
  .group(:pair_id)
  .having("tickers.trade_count >= (#{avg_trade_count_sql})")

Here we use the subquery in the having clause, producing the following query:

SELECT "tickers".* 
  FROM "tickers" 
  GROUP BY "tickers"."pair_id" 
  HAVING (tickers.trade_count >= (SELECT AVG(trade_count) FROM "tickers"))

Or we could do a query to analyze this info in another way: get the average ticker trade_count for each pair, and only return the tickers that have trade_count above or equal the average trade_count of the tickers belonging to given pair:

avg_trade_count_by_pairs_sql = Ticker.select("pair_id, AVG(trade_count) as average").group(:pair_id).to_sql
Ticker
  .joins("INNER JOIN (" + average_trade_count_by_pairs_sql + ") trades ON tickers.pair_id = trades.pair_id")
  .where("tickers.trade_count >= trades.average")

This produces the following SQL:

SELECT "tickers".* 
  FROM "tickers" 
  INNER JOIN (
    SELECT pair_id, AVG(trade_count) as average 
    FROM "tickers" GROUP BY "tickers"."pair_id"
  ) trades 
  ON tickers.pair_id = trades.pair_id 
  WHERE (tickers.trade_count >= trades.average)

This is a tricky one, so let's break it down to understand how we're doing this. First off, we have our subquery SQL in avg_trade_count_by_pairs_sql. If executed individually, will return to you an aggregated result like the following:

Each pair_id is listed with an aggregated result that represents the average of trade_count of all of the tickets belonging to the pair (i.e., SELECT * FROM tickets WHERE pair_id = [THE PAIR ID]). This SQL is merged inside the Ticker custom join (INNER JOIN) we named as trades. In the end, we have tickers.trade_count from the current ticker row being iterated, and trades.average that we have from our subquery, and represents the average ticker_count of the ticker pair of the current iteration (association made because of our ON tickers.pair_id = trades.pair_id from the custom join).

We're already writing custom joins, anything beyond that it's more SQL specifics than ActiveRecord, so we can end up here. To finish, though, let's benchmark this query with a simple solution using ruby Enumerable:

  tickers = []
  Pair.all.each do |pair|
    avg = Ticker.where(pair: pair).average(:trade_count)
    selectable_tickers = Ticker.where(pair: pair).where("trade_count >= ?", avg)
    tickers.push(*selectable_tickers.to_a)
  end

Avg trade count by pairs - Enumerable solution (memory profiler)
Total allocated: 72357 bytes (872 objects)
Total retained:  573 bytes (9 objects)

Avg trade count by pairs - ActiveRecord query solution (memory profiler)
Total allocated: 6348 bytes (86 objects)
Total retained:  296 bytes (5 objects)

Our ActiveRecord solution consumes ~11x less memory in the total allocated, and ~2x less memory in the total retained.

IPS - Avg trade count by pairs - ActiveRecord query solution:    15095.6 i/s
IPS - Avg trade count by pairs - Enumerable solution:      740.6 i/s - 20.38x  (± 0.00) slower

Comparing the iterations per second, we can check that the Enumerable solution is 20.38x slower.

Conclusion

In this post, we saw how to use advanced ActiveRecord features to go beyond a simple where clause. We saw how to use ActiveRecord to query belongs_to and has_many associations, using joins, aggregations, and subqueries, combining all.

We also compared some queries with the equivalent using a ruby Enumerable based solution. For benchmarking both approaches we checked the memory consumption and iterations per second, which showed without surprise the Enumerable based solutions consuming in most cases dozens of times more memory because of extra allocations and being also dozens of times slower.

Of course, we should keep in mind that the benchmark was done using only a very small database. We weren't worried about checking how much worse it can get with larger databases, or searching for points of stabilization (a.k.a., "it doesn't get much worse than that"). The idea of benchmarking was to show you how bad it can be when you rely upon ruby Enumerator to do things that our database is capable of doing through ActiveRecord, which is a common bad "code smell".

This is it! If you have any comments or suggestions, don't hold back, let me know.

Options if you like my content and would like to support me directly (never required, but much appreciated):

BTC address: bc1q5l93xue3hxrrwdjxcqyjhaxfw6vz0ycdw2sg06

Making Your Ruby Gem Configurable

Rodrigo Walter Ehresmann — Sun, 06 Jun 2021 16:43:09 +0000

Ruby gems are pretty much a module. It's not a big deal to us to declare a module, but how do we create those richest configuration files we usually have in /initializers folder of a Ruby on Rails application? Let's check it out.

First of all, there are many ways to make your gem configurable. I'll present you one, and further, we'll give it a look at how other gems implement it.

Example of implementation

I'll call my example gem gsdk. You can assume the gem structure is the default of bundle gem gsdk (Bundler version 1.17.3), but this isn't important for the context of this post, it's just to give you some orientation. This gem will have a token and a secret key I'd like to inform as configuration, so let's put that in code:

# gsdk/lib/gsdk/configuration

module Gsdk
  class Configuration
    attr_accessor :token, :secret_key

    def initialize(token = nil, secret_key = nil)
      @token = token
      @secret_key = secret_key
    end
  end
end

As simple as that, we have the configuration class that makes token and secret key available through attr_accessor.

Gsdk is a module, but the Configuration is a class instance. How do we make the instance available to be used anywhere, by any class that exists inside the Gsdk module?

module Gsdk
  class << self
    attr_accessor :configuration
  end

  def self.configuration
    @@configuration ||= Configuration.new
  end
end

It's a matter of scope. Although it's a module, modules are implemented as classes (Module.class == Class) and can make use of instance or class variables too. However, we need to inform that to the module, and we do so in a code block inside the class << self. The block code is enough by itself, but I wanna initialize with an empty Configuration instance if configuration is accessed, that's why we have self.configuration.

Now it is possible to configure the gem and make the token and secret key available in the module.

module Gsdk
  class Caller
    def call
      puts "Token: #{Gsdk.configuration.token}"
      puts "Secret key: #{Gsdk.configuration.secret_key}"
    end
  end
end

(base) ➜  gsdk git:(master) ✗ ./bin/console
2.6.6 :001 > configuration = Gsdk::Configuration.new('my_token', 'my_secret_key')
 => #<Gsdk::Configuration:0x000055b8ada3d638 @token="my_token", @secret_key="my_secret_key"> 
2.6.6 :002 > Gsdk.configuration = configuration
 => #<Gsdk::Configuration:0x000055b8ada3d638 @token="my_token", @secret_key="my_secret_key"> 
2.6.6 :003 > Gsdk::Caller.new.call
Token: my_token
Secret key: my_secret_key
 => nil

The gem is already configurable, but we still missing what we proposed to answer in the first paragraph of this post: how to do what was shown above but in a configuration block. Now we know that it's a matter of scope, the answer should be easier to understand :

module Gsdk

...

  def self.configure
    yield(configuration)
  end
end

The class method self.configure allows us to achieve our goal:

Gsdk.configure do |config|
  config.token = "your_token"
  config.secret_key = "your_secret_key"
end

(base) ➜  gsdk git:(master) ✗ ./bin/console
2.6.6 :001 > Gsdk.configure do |config|
2.6.6 :002 >       config.token = "your_token"
2.6.6 :003?>     config.secret_key = "your_secret_key"
2.6.6 :004?>   end
 => "your_secret_key" 
2.6.6 :005 > Gsdk.configuration
 => #<Gsdk::Configuration:0x000055f935a2e818 @token="your_token", @secret_key="your_secret_key"> 
2.6.6 :006 >

With yield we're calling the empty Configuration instance (config.class == Gsdk::Configuration), that uses attr_accessor for token and secret_key, making them available in the code block.

Implementation alternatives

Let's check how big and consolidated gems achieve roughly the same we did above. To identify this we can check two things: (1) where is the method that accepts a configuration block, and (2) how a configuration option is set. The place to get the name of the method and the configuration options is the configuration file usually pointed out in the gem's documentation.

Devise gem:

Devise.setup do |config|
...

config.password_length = 6..128

...
end

This is part of the configuration file generated by Devise using their rails generate devise:install. Looking into lib/devise.rb:

module Devise

...

  mattr_accessor :password_length
  @@password_length = 6..128

...

  def self.setup
    yield self
  end

...
end

Devise uses Rails specific mattr_accessor that provides getters and setters in a class/module level, and self.setup is the equivalent of our self.configure implemented in the previous section.

We could achieve the same as Devise eliminating the use of Gsdk::Configuration and changing our module to:

module Gsdk
  class << self
    attr_accessor :token, :secret_key
  end

  def self.configure
    yield self
  end
end

(base) ➜  gsdk git:(master) ✗ ./bin/console
2.6.6 :001 > Gsdk.configure do |config|
2.6.6 :002 >       config.token = "your_token"
2.6.6 :003?>     config.secret_key = "your_secret_key"
2.6.6 :004?>   end
 => "your_secret_key" 
2.6.6 :005 > Gsdk.secret_key
 => "your_secret_key" 
2.6.6 :006 > Gsdk.token
 => "your_token"

Sidekiq gem

  Sidekiq.configure_server do |config|
    config.redis = { url: ENV.fetch('REDIS_URL') }
  end

This is part of Sidekiq configuration I have in an initializer of a Rails project. Looking into lib/sidekiq.rb:

...

module Sidekiq

...

  def self.redis
    ...
  end

  def self.redis=(hash)
    ...
  end

  def self.configure_server
    yield self if server?
  end

...

end

In Sidekiq they explicitly implement getters and setters, which we saw being accomplished before using attr_accessor and mattr_accessor. Once again, we can change our implementation to work in the same manner:

module Gsdk
  def self.token
    @token
  end

  def self.token=(token)
    @token = token
  end

  def self.secret_key
    @secret_key
  end

  def self.secret_key=(secret_key)
    @secret_key = secret_key
  end

  def self.configure
    yield self
  end
end

(base) ➜  gsdk git:(master) ✗ ./bin/console
2.6.6 :001 > Gsdk.configure do |config|
2.6.6 :002 >       config.token = "your_token"
2.6.6 :003?>     config.secret_key = "your_secret_key"
2.6.6 :004?>   end
 => "your_secret_key" 
2.6.6 :005 > Gsdk.token
 => "your_token" 
2.6.6 :006 > Gsdk.secret_key
 => "your_secret_key"

Conclusion

In this post, we saw how to make a gem configurable. We implemented our configuration strategy and further checked how Devise and Sidekiq gems are implemented to be configurable.

All three implementations explored in this post are different one from another, but they summed up to getters and setters. You can explicitly implement getters and setters on your own or use something like attr_accessor; make use of instance variables or class variables.

Which one is the best implementation strategy? My response would be: don't overthink this. You can argue that to use mattr_accessor you need an extra dependency, or that instance variables in modules are simply poor design. But the point is that we're talking about something trivial, so start with what you think is the best for you.

This is it! If you have any comments or suggestions, don't hold back, let me know.

Options if you like my content and would like to support me directly (never required, but much appreciated):

BTC address: bc1q5l93xue3hxrrwdjxcqyjhaxfw6vz0ycdw2sg06

Continuous Delivery With Heroku

Rodrigo Walter Ehresmann — Fri, 07 May 2021 14:14:17 +0000

Introduction

Continuous Delivery (CD) is a software engineering approach in which the development team produces valuable software in short cycles and ensures that a reliable version of the software can be released at any time.

Although it can be painful to develop your own custom Continuous Delivery solution, it's relatively simple to do it with Heroku. Although you'll find a good documentation about this on Heroku, you'll not see in one place an application example fully integrated into the CD approach. The goal of this post is to provide this example for further reference.

The pipeline will consist of the following steps:

As soon as a Pull Request (PR) is opened on the GitHub repository, a review app is created;
Once the PR is merged, automatically deploy the alterations into the staging app;
Manually promote the staging app to production.

I like to have review apps enabled because it gives you an URL reflecting the repository code on your PR. It's easy to share it with your team or even with customers (the ones paying you for the work).

The staging environment is normally intended to be a copy of the production environment and used as a final validation step before sending your alterations to production.

In this post, I'll be showing a configuration I often have in my projects. I'll be deploying a Ruby on Rails application, but if you came here aiming to configure CD for another kind of application, don't worry: the configuration is quite general.

Setting Up Heroku Pipeline

First things first, we create the production app on Heroku (naming it is up to you):

heroku apps:create generic-app-t

Now we create the pipeline:

➜  ~ heroku pipelines:create -a generic-app-t
? Pipeline name generic-app-t-pipeline
? Stage of generic-app-t production
Creating generic-app-t-pipeline pipeline... done
Adding ⬢ generic-app-t to generic-app-t-pipeline pipeline as production... done

The parameter -a specifies the app name, and that's required when creating a pipeline. I changed the default name for the pipeline appending the -pipeline at the end of the app name (personal taste, you can keep the default if you want) and informed that generic-app-t is the production app.

Note: If you prefer to use the Heroku dashboard, the action above plus the next ones can be found in the Deploy tab.

Now it's time to create the staging app:

heroku apps:create generic-app-t-staging

and add it to our pipeline:

➜  ~ heroku pipelines:add generic-app-t-pipeline -a generic-app-t-staging
? Stage of generic-app-t-staging staging
Adding ⬢ generic-app-t-staging to generic-app-t-pipeline pipeline as staging... done

Let's review what we wanna achieve with the staging app: each time we merge the PR in our master branch, the alteration must be deployed to our staging app. To allow this to happen, you need to enable automatic deploys. The configuration option is found in the deploy tab:

Supposing you already have your app repository on GitHub, it's time to connect your pipeline to it:

Now it's possible to enable Review Apps in your pipeline. We have some configuration options available, and I'll choose the following:

Create new review apps for new pull requests automatically, as proposed in the introduction section of this post;
Destroy review apps that don't have any new deploy after 30 days. It's up to you really, but I don't like to keep old review apps, and you can always create a new one if necessary.

With that, the pipeline has all the apps it should contain. Let's continue with specific configurations for each one now.

Configuring Environments and Review Apps on Heroku

I'm assuming that both environments will have the following Heroku add-ons:

1) Two Heroku Postgres databases;
2) Redis Cloud database;
3) Rollbar.

For what purpose I'll use two databases or any other add-on, that is not important in the context of this post. They're here just to provide more comprehensive configurations.

As a Ruby on Rails application, we also include the heroku/ruby buildpack.

The next step is to set your config vars. My config vars are all inside an encrypted credentials file, so I'll just set one called RAILS_MASTER_KEY that is used to decrypt it.

Add-ons, buildpack, and config vars: do again exactly the same you did but now for the staging app (in my case, generic-app-t-staging).

To finish it, set the config vars for the review apps. This is a general configuration that will be applied over all review apps that will be created in the future, and you can find it in the Settings tab of your pipeline.

Configuring Review Apps on Your Application

The final step to have your review apps working is the app.json file. This is a file that needs to be on the root of your repository, containing instructions of which add-ons/builpacks should be used, as well as the required config vars.

In my case, I'm replying the configuration made for production/staging, and here is how it'll look like:

{
  "env":{
     "RAILS_MASTER_KEY":{
        "require":true
     }
  },
  "scripts":{
     "postdeploy":"bin/bundle exec rake db:migrate rake db:seed"
  },
  "addons":[
     {
        "plan":"heroku-postgresql:free"
     },
     {
        "plan":"heroku-postgresql:free",
        "as":"audit"
     },
     {
        "plan":"rediscloud:free"
     },
     {
      "plan": "rollbar:free"
     }
  ],
  "buildpacks":[
     {
        "url":"https://github.com/heroku/heroku-buildpack-ruby"
     }
  ]
}

We have two postgresql add-ons, and we cannot add both with the same name. To handle that we simply name differently one of them with as. The add-on notation is add-on-name:plan, and one question you may face is where to find the add-on name to add: add-ons can be added through the heroku-cli (heroku addons:create [name]), and the name must follow the same notation. This name can be found on the add-on page (e.g., Redis Enterprise Cloud). The postdeploy specifies if something should run right after the deploy is finished. In my case, I'm using rails command to create/update the database tables (db:migrate) and provide some seed data (db:seed).

Putting Everything to Work

Create a PR in your GitHub repository, and you'll see a review app being deployed.

Merge the PR, and you'll see that's automatically deployed to the staging app, offering you the option to promote to production:

Promote it to production, and congratulations: you delivered your software alterations in a short cycle using the continuous delivery approach!

Conclusion

This post showed how to integrate an application in a Continuous Delivery approach using Heroku. It was presented how to fully configure the pipeline that consisted of review apps for each pull request, a staging app for tests, and finished with the production app.

The configuration presented is just an example of what you could do, and you can modify it according to your needs. For instance: Continous Integration (CI). CI is out of the scope of this post, but you could easily include it in your approach (e.g., deploying to the staging app only if your tests pass).

Keep in mind that besides what was shown here, you need to configure your application on how to handle the staging environment. The same way you have specific configurations implemented for the test, development, and production environment, your application needs to know how to behavior when env == staging.

As a final suggestion, if you're not using Continuous Delivery, considered it. Regardless of the size of your project, if your team is small or even if you're working alone: it's better to organize your project.

This is it! If you have any comments or suggestions, don't hold back, let me know.

Options if you like my content and would like to support me directly (never required, but much appreciated):

BTC address: bc1q5l93xue3hxrrwdjxcqyjhaxfw6vz0ycdw2sg06

Design Patterns: Query Objects

Rodrigo Walter Ehresmann — Thu, 04 Mar 2021 00:39:32 +0000

Query Object is a Design Pattern you can use to avoid/starting fixing God Classes. A God Class is nothing more than a class that does more than should do and becomes one of the biggest files in your project regarding number lines.

If you ask me, it's barely impossible to not face at least one User model with these characteristics throughout your software developer career 😅

Query objects are most used to clean up your models from queries. Let's jump straight to a real-world example of how you can build one:



class CurrenciesQuery
  def initialize(relation = Currency.all)
    @relation = relation.extending(Scopes)
  end

  def self.gold
    Currency.find('XAU')
  end

  def relation
    @relation
  end

  module Scopes
    def all_except(code)
      self.where.not(code: code)
    end
  end
end



class ExchangeRatesQuery
  def initialize(relation = ExchangeRate.all)
    @relation = relation.extending(Scopes)
  end

  def relation
    @relation
  end

  def self.from_gold
    ExchangeRate.find_by!(
      base_currency_code: 'BRL', 
      currency_code: CurrenciesQuery.gold.code
    )
  end

  module Scopes
    def from(base_currency_code)
      self.where(base_currency_code: base_currency_code)
    end

    def to(currency_code)
      self.where(currency_code: currency_code)
    end
  end
end

Let me give a bit of context about these query objects first. It represents two models: Currency and ExchangeRate. Currencies are fiat currencies and gold, and each one has many exchange rates. An exchange rate is a record that says that base currency X is worthed a given amount of currency Y.

I added two query objects to you observe the similarities of how they are built:

Inside the class, a module Scopes is defined, containing the queries;
In the class constructor, we use the ActiveRecord extending method to add these query methods to the @relation variable.

With that, we can simply run things like ExchangeRatesQuery.new.relation.from('BRL').to('USD'). That gives us the exchange rate from BRL to USD (how much 1 BRL is worthed in USD). As you can see, is also a personal preference of mine to define fixed params in query objects (e.g., self.gold in CurrencieQuery, to identify which record represents the gold currency).

In my Rails projects, I'm used to having the query objects in app/queries folder, with one query object per model (when necessary). I like to do so for one reason: totally decoupling queries from models.

You can also decide on creating query objects for one specific query each. With this approach, you probably wanna create query objects just for more complicated queries. For instance, check this one from Hound repository:



class RecentBuildsByRepoQuery
  NUMBER_OF_BUILDS = 10

  static_facade :call

  def initialize(user:)
    @user = user
  end

  def call
    Build.find_by_sql([<<-SQL, user_id: @user.id, limit: NUMBER_OF_BUILDS])
      WITH user_builds AS (
        SELECT
          builds.id
        FROM
          builds
          INNER JOIN repos
            ON builds.repo_id = repos.id
          INNER JOIN memberships
            ON repos.id = memberships.repo_id
        WHERE
          memberships.user_id = :user_id
        LIMIT 1000
      ),
      recent_builds_by_pull_request AS (
        SELECT distinct ON (repo_id, pull_request_number)
          builds.*
        FROM
          builds
          INNER JOIN user_builds
            ON user_builds.id = builds.id
        ORDER BY
          repo_id,
          pull_request_number,
          created_at DESC,
          id DESC
      )
      SELECT
        *
      FROM
        recent_builds_by_pull_request
      ORDER BY
        created_at DESC
      LIMIT
        :limit
    SQL
  end
end

If you look in the models from this same repository, you'll find that simple queries stay there, and that is totally fine once your class isn't too big, messy, and take care of many things.

In the end, the best approach is the one your team agrees to keep and go forward. Query objects aren't a requirement, boot an approach to keep your code more maintainable.

This is it! Feel free to share how you've been using query objects in your project. If you have any comments or suggestions, don't hold back, let me know.

Options if you like my content and would like to support me directly (never required, but much appreciated):

BTC address: bc1q5l93xue3hxrrwdjxcqyjhaxfw6vz0ycdw2sg06

Ruby on Rails + Auth0: Authenticating your API with an external authentication service

Rodrigo Walter Ehresmann — Mon, 01 Mar 2021 01:30:44 +0000

Introduction

In 2019 I wrote a post with this same subject and an extra tool: Knock.

With a few modifications in the gem source code, we could easily integrate Auth0 into our Rails API, but that on Rails 5. Rails 6 brought Zeitwerk code loader together, which makes it harder to perform the alterations suggested in my previous post.

With those problems in mind, I came to the conclusion that is easier to drop Knock off this task and do it yourself. It isn't a difficult task but requires some understanding of Auth0 API. In this post, I'll show you one way you can do it.

What We are Going to Build

An integration with Auth0 allowing our users to signup and login with a username and password, plus the functionality of update the user password.

The users need to login into our Rails API, but to our API perform any action in Auth0, like update a password, the API itself must have access to the access token. To do so we'll use the Client Credentials Flow.

Configuring Auth0 Application

1) Select the Machine to Machine Applications and create it;

2) In the next step, select Auth0 Management API as your API, and be sure to select the necessary scopes to allow us to update the user password as proposed in the introduction of this post. You can click in Authorize to proceed;

3) On the application page, go to Show Advanced Settings. In the Grant Types tab, be sure to select the grants we'll use to authorize our API to communicate with Auth0 and allow the user-password registering process.

If furtherly you wanna allow new features in your API, like delete users and email confirmation, for instance, the scopes presented in step 2 are the place to go. If you wanna implement other authorization flow, like refresh tokens, for instance, the grants presented in step 3 are the place to go.

With the Auth0 application set, you're ready to proceed with your Rails API.

Rails API

Setting your credentials/ENV

You'll need to make available in your Rails API some information from Auth0. To do so, you can use rails credentials, .env, or anything else you feel comfortable using:

Domain
Client ID
Client Secret
Your JWKS (JSON Web Key Set)
Audience

The first three ones you can find on your Auth0 application page. The JWKS are available in the following URL (you should copy the whole JSON): https://[YOUR-DOMAIN]/.well-known/jwks.json (i.e., https://rwehresmann.auth0.com/.well-known/jwks.json). The audience is named as API Identifier and you can find it in the APIs tab of your application.

Calling Auth0 API

Everything will be created under the class Auth0, and it'll be using HTTP gem to perform the quests, but feel free to decide over your code organization and tools.

About the Auth0 API, you can check the Authentication API and Management API v2 for relevant documentation and further instructions.

So let's signup an user.



class Auth0
  @@credentials = Rails.application.credentials.dig(:auth0)

    def self.signup(email, password)    
    HTTP.headers(accept: 'application/json').post(
      "https://#{@@credentials.dig(:domain)}/dbconnections/signup",
      form: {
        client_id: @@credentials.dig(:client_id),
        email: email,
        password: password,
        connection: 'Username-Password-Authentication',
      }
    )
  end
end

Calling it in the rails console:



3.0.0 :001 > response = Auth0.signup('devto@mail.com', 'supersecrectpasswd')
 => #<HTTP::Response/1.1 200 OK {"Date"=>"Sun, 28 Feb 2021 20:35:28 GMT", ... 
3.0.0 :002 > user_id = JSON.parse(response.to_s)['_id']
 => "603bfe90c23beb006ad972d6"

There is nothing special about the request itself, but you can be wondering about the connection param. Auth0 connection is simply the source of the user and in this case, the source is a database. The Username-Password-Authentication is a database created by default in your account.

The _id represents the id of the user inside Auth0.

Now we'll log in the created user:



class Auth0
  @@credentials = Rails.application.credentials.dig(:auth0)

...

  def self.login(email, password)
    HTTP.headers(accept: 'application/x-www-form-urlencoded').post(
      "https://#{@@credentials.dig(:domain)}/oauth/token",
      form: {
        grant_type: 'password',
        username: email,
        password: password,
        audience: @@credentials.dig(:audience),
        client_id: @@credentials.dig(:client_id),
        client_secret: @@credentials.dig(:client_secret),
      }
    )
  end
end

Calling it in the rails console:



3.0.0 :003 > response = Auth0.login('devto@mail.com', 'supersecrectpasswd')
 => #<HTTP::Response/1.1 200 OK {"Date"=>"Sun, 28 Feb 2021 20:38:12 GMT", ... 
3.0.0 :004 > puts response.to_s
 => {"access_token":"eyJhbGc...","scope":"read:current_user update:current_user_metadata delete:current_user_metadata create:current_user_metadata create:current_user_device_credentials delete:current_user_device_credentials update:current_user_identities","expires_in":86400,"token_type":"Bearer"}

The grant_type is password because we configured before that the user login would be through username and password.

The access_token (shortened it in the example) returned in the response is the JWT (JSON Web Token). Where is necessary, the users will use this token to perform actions in your Rails API. Once the JWT is decoded, you'll have the following payload structure:



{
  "iss": "",
  "sub": "",
  "aud": "",
  "iat": ,
  "exp": ,
  "azp": "",
  "scope": "",
  "gty": ""
}

The sub (subject) is represented by the ID of the user in your Auth0 application. This ID is already returned in the signup call and is a good idea to persist it. The following flow could be implemented to identify the current user:

A user access your rails API sending you his JWT;
You decode the JWT and get the user id (sub);
You query for the user that has this id, and he is your current user.

To finish, let's change the user password:



class Auth0
  @@credentials = Rails.application.credentials.dig(:auth0)

...

  def self.update_password(token, auth0_user_id, new_password)
    HTTP.auth("Bearer #{token}")
      .headers(accept: 'application/json')
      .patch(
        "https://#{@@credentials.dig(:domain)}/api/v2/users/#{auth0_user_id}",
        json: {
          client_id: @@credentials.dig(:client_id),
          password: new_password,
          connection: 'Username-Password-Authentication',
        }
      )
  end
end

There are two details to pay attention to about this method:

1) The endpoint used has the finality to update a user, not only a password. There are many attributes we can update and you can check the documentation to get further details. We'll be updating only the password because this is everything we need in the demonstration built in this post;

2) We need to inform a token. And what is this token about? It is the Client Credentials Flow we discussed earlier, that will provide us a token that will allow our Rails application to perform actions in the Auth0 application (limited by the scopes we defined).

So let's implement the client credentials flow:



class Auth0
  @@credentials = Rails.application.credentials.dig(:auth0)

...

  def self.login_server
    HTTP.headers(accept: 'application/x-www-form-urlencoded').post(
      "https://#{@@credentials.dig(:domain)}/oauth/token",
      form: {
        grant_type: 'client_credentials',
        audience: @@credentials.dig(:audience),
        client_id: @@credentials.dig(:client_id),
        client_secret: @@credentials.dig(:client_secret),
      }
    )
  end
end

Testing everything in the rails console:



3.0.0 :006 > response = Auth0.login_server
 => "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6Ik5USXhRVUUyTTBJeE1qSkVOM...
3.0.0 :013 > Auth0.update_password(token, "auth0|#{user_id}", 'newsupersecretpas
swd')
 => #<HTTP::Response/1.1 200 OK {"Date"=>"Sun, 28 Feb 2021 20:58:21 GMT", "Content-Type"=>"application/json; charset=utf-8", "Transfer-Encoding"=>"chunked", "Connection"=>"close", "Set-Cookie"=>"__cfduid=d47242c0ca577209101634ebb26a907ba1614545901; expires=Tue, 30-Mar-21 20:58:21 GMT; path=/; domain=.auth0.com; HttpOnly; SameSite=Lax; Secure", "Cf-Ray"=>"628d1029fc00d07a-CWB", "Cache-Control"=>"no-cache", "Strict-Transport-Security"=>"max-age=31536000", "Vary"=>"origin,accept-encoding", "Cf-Cache-Status"=>"DYNAMIC", "Cf-Request-Id"=>"088c086e400000d07a70897000000001", "Expect-Ct"=>"max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\"", "Ot-Baggage-Auth0-Request-Id"=>"628d1029fc00d07a", "Ot-Tracer-Sampled"=>"true", "Ot-Tracer-Spanid"=>"2f5c2d4c6a8d5ee6", "Ot-Tracer-Traceid"=>"4003510336be279a", "X-Content-Type-Options"=>"nosniff", "X-Ratelimit-Limit"=>"10", "X-Ratelimit-Remaining"=>"9", "X-Ratelimit-Reset"=>"1614545902", "Server"=>"cloudflare", "Alt-Svc"=>"h3-27=\":443\"; ma=86400, h3-28=\":443\"; ma=86400, h3-29=\":443\"; ma=86400"}>

And it's done! As you can see, we used "auth0|#{user_id}" (all the examples of this section run in the same terminal session, and user_id comes from later when we signup). The Auth0 user ID we must inform is always in the format provider|ID. We didn't use any external provider when signed up, and because of that, the provider is Auth0 itself.

Decoding the JWT

Decoding JWTs is simple whit the help of an already implemented solution. In this section, I'll be using the ruby-jwt.

How to decode will depend on how it was encoded first. For instance:



3.0.0 :001 > JWT.encode({ sub: 'my user id' }, nil, 'none')
 => "eyJhbGciOiJub25lIn0.eyJzdWIiOiJteSB1c2VyIGlkIn0." 
3.0.0 :002 > jwt = JWT.encode({ sub: 'my user id' }, nil, 'none')
 => "eyJhbGciOiJub25lIn0.eyJzdWIiOiJteSB1c2VyIGlkIn0." 
3.0.0 :003 > JWT.decode(jwt, nil, false)
 => [{"sub"=>"my user id"}, {"alg"=>"none"}]

Quite simple. With Auth0, however, the JWT is signed, so there are a few parameters we need to inform to decode it successfully. You can read more about JWT in general here, and the class below is what you can use as a decoder for the Auth0 JWT:



class JwtDecoder

  def initialize(access_token)

    @access_token = access_token

  end

def call

    JWT.decode(

      @access_token, 

      nil,

      true, # Verify the signature of this token

      algorithm: 'RS256',

      iss: "https://#{credentials.fetch(:domain)}/",


      verify_iss: true,

      aud: credentials.fetch(:audience),

      verify_aud: true

    ) do |header|

      jwks_hash[header['kid']]

    end.first

  end

private

def jwks_hash

    jwks_raw = credentials.fetch(:jwks).to_json

    jwks_keys = Array(JSON.parse(jwks_raw)['keys'])

    Hash[

      jwks_keys.map do |key| 

        [

          key['kid'],

          OpenSSL::X509::Certificate.new(Base64.decode64(key['x5c'].first)).public_key

        ]

      end

    ]

  end

def credentials

    @credentials ||= Rails.application.credentials.dig(:auth0)

  end

end

Conclusion

This post showed how to implement a complete authorization flow with username and password in your Rails API using Auth0 as your authentication service.

With the configurations showed in the Auth0 section, you can easily extend your implementation and start using other features from Auth0 just by authorizing new scopes. Auth0 docs are a bit messy, but remember that most of the information necessary to use their API you will found in Authentication API and Management API v2.

Rails API is our context, but it wasn't in the scope of this post to build an API from step 0. In my first post about this subject, Knock provided the helpers we are used to having like current_user and authenticate_user. However, once you have the Auth0 access methods, know how to get the JWT and decode it, like shown in the Rails API section, there is no mystery:

authenticate_user is nothing more than decode the JWT, get its sub (subject, the id from the user in Auth0), and search for the user in your database;
current_user is nothing more than get the user in the authentication process and make it a helper for your controllers.

You have full flexibility to implement those methods the way more suit your application.

This is it! If you have any comments or suggestions, don't hold back, let me know.

Options if you like my content and would like to support me directly (never required, but much appreciated):

BTC address: bc1q5l93xue3hxrrwdjxcqyjhaxfw6vz0ycdw2sg06

Migrating from Create React App to SSR with Razzle

Rodrigo Walter Ehresmann — Thu, 25 Feb 2021 14:37:13 +0000

Introduction

Not always you, as a software developer, can run away from a project's scope change. Poor requirements gathering can lead you to these situations, and here I'll show how I handled a specific case where I need to change a project created with CRA (Create React App) to support SRR (Server Side Rendering).

At first, I considered Nextjs, which is a robust solution for SSR, but the problem was: lots of rewriting would be necessary. Nextjs is a framework, and as so it has its specific way to implement things. The code impact would be big, big enough to make me search for something new and more affordable for my current situation.

So I found Razzle. As you can read in the Razzle project description, it specifically aims to feel the gap in buy you into a framework
or setting things yourself.

Solution

Similar to CRA, Razzle has its own create-razzle-app. The first step was simple as:

npx create-razzle-app my-app-name

I created a new app and throw my app files inside it, but you can merge what was generated into your existing app (although this can be a bit more arduous).

Razzle works like a charm but, although it has a low code impact on the codebase, there is some impact already expected because SSR requires some alterations. So here is what I needed to focus on:

Routes;
Replace what was using js window object;
Styles.

First, it is necessary to know when you are on the server or on the browser. The helper below was used for this purpose.

export const isServer = !(
  typeof window !== 'undefined' &&
  window.document &&
  window.document.createElement
);

Routes

To be able to navigate back/forward previously accessed pages, history from React Router was being used. The following alteration was necessary:

From

export const history = createBrowserHistory();

export const history = isServer
  ? createMemoryHistory({
      initialEntries: ['/'],
    })
  : createBrowserHistory();

Using the createBrowserHistory function in the server throws you the error Invariant failed: Browser history needs a DOM. Obviously, no DOM is available there, so we used the createMemoryHistory function that doesn't require a DOM.

Replacing the `window` object functions

The window object was being used in some parts of the code where the localStorage was being called. The localStorage was being used to store login sessions and a shopping cart id, so the first step was to find a replacement for it: cookies.

Cookies can be accessed by the server, and although I didn't need to do so, it wouldn't break the app (what otherwise would happen using the window object). React Cookies filled my needs, and I encapsulated all my cookies interaction in a class I called CookieUtility.

Replacing localStorage with my CookieUtility solved the question here, and I wanna show the only one that was tricky at first: the PrivateRoute component. So the alteration was:

From

...

const PrivateRoute = (props) => {
  const token = localStorage.getItem(BrowserStorageKeyEnum.Jwt);
  let isTokenExpired = false;

  if (token) {
    const decodedJwt = jwt.decode(token);
    const currentTimeInSeconds = moment(Math.floor(Date.now() / 1000));
    const expirationTimeInSeconds = decodedJwt.exp - currentTimeInSeconds;

    if (expirationTimeInSeconds <= 0) isTokenExpired = true;
  }

  if (token && !isTokenExpired) {
    return <Route {...props} />;
  } else {
    return (
      <Redirect
        to={{
          pathname: RouteEnum.Login,
          state: { from: props.location }
        }}
      />
    );
  }
};

...

...

export default function PrivateRoute(props) {
  if (isServer) return <LoadingPageIndicator isLoading={true} />;
  else {
    const jwt = CookieUtility.getJwt();

    if (!!jwt) {
      return <Route {...props} />;
    } else {
      return (
        <Redirect
          to={{
            pathname: RouteEnum.Login,
            state: { from: props.location },
          }}
        />
      );
    }
  }
}

Keep in mind that that the new version of the PrivateRoute is more succinct because the code was refactored, and all the time-wise logic was put in the CookieUtility, defining cookies expiration time.

What you should pay attention to is the first line of the new PrivateRoute component function: if in the server, just display a loading indicator. If you are doing so for SEO (Search Engine Optimization) purposes, this would be a problem, but in my case, no private route exists whit this intention, just public ones, so this trick works just fine.

Styles

The app was being implemented using Styled Components that already comes with an integrated solution for SSR, allowing you to load all the required styles for the target page and put it at the end of your <header> tag in the server.js generated by Razzle.

import { ServerStyleSheet } from 'styled-components';

...

server
  .disable('x-powered-by')
  .use(express.static(process.env.RAZZLE_PUBLIC_DIR))
  .get('/*', (req, res) => {

const sheet = new ServerStyleSheet();
const styleTags = sheet.getStyleTags();

...

res.status(200).send(
`<!doctype html>
    <html lang="">
    <head>
      <meta http-equiv="X-UA-Compatible" content="IE=edge" />
      <meta charset="utf-8" />
      <title>Welcome to Razzle</title>
      <meta name="viewport" content="width=device-width, initial-scale=1">
      ${assets.client.css ? `<link rel="stylesheet" href="${assets.client.css}">` : ''}
        ${
          process.env.NODE_ENV === 'production'
            ? `<script src="${assets.client.js}" defer></script>`
            : `<script src="${assets.client.js}" defer crossorigin></script>`
        }
        ${styleTags}
    </head>
`
...

Conclusion

This post showed how I migrated from a normal React app created with CRA to an SSR app, using Razzle to accomplish this. It was not done with the intention to work as a tutorial but to show you a path you can follow if you find yourself in the same situation as the one described in the introduction of this post, highlighting the steps that took me some time to understand how to overcome them.

It was worthed to use Razzle? I definitely would say yes. It was possible to migrate a middle-size app to work with SSR in a short time. The steps I described in the solution section were actually the only ones that forced me to change more large chunks of code, and besides that, I only needed to remove external libs that used the window object, but that is expected if you're dealing with SSR (the migration process can be harder depending on how much you relly on those libs).

At the moment this post was written, Razzle is quite an active project, and there are many plugins being developed for it. For instance, there is a plugin you can use to easily handle PWA.

This is it! If you have any comments or suggestions, don't hold back, let me know.

Options if you like my content and would like to support me directly (never required, but much appreciated):

BTC address: bc1q5l93xue3hxrrwdjxcqyjhaxfw6vz0ycdw2sg06

DEV Community: Rodrigo Walter Ehresmann

React App From Scratch and Deploy to Heroku

React Installation and Package Structure

Webpack and Project Up!

Deploy to Heroku

Conclusion

A Bit of Advanced ActiveRecord Querying - With Benchmarks

Introduction

Domain

Querying belongs_to associations

Querying has_many associations

Querying With Aggregations and Subqueries

Subqueries

Conclusion

Making Your Ruby Gem Configurable

Example of implementation

Implementation alternatives

Conclusion

Continuous Delivery With Heroku

Introduction

Setting Up Heroku Pipeline

Configuring Environments and Review Apps on Heroku

Configuring Review Apps on Your Application

Putting Everything to Work

Conclusion

Design Patterns: Query Objects

Ruby on Rails + Auth0: Authenticating your API with an external authentication service

Introduction

What We are Going to Build

Configuring Auth0 Application

Rails API

Setting your credentials/ENV

Calling Auth0 API

Decoding the JWT

Conclusion

Migrating from Create React App to SSR with Razzle

Introduction

Solution

Routes

Replacing the window object functions

Styles

Conclusion

Querying `belongs_to` associations

Querying `has_many` associations

Replacing the `window` object functions