DEV Community: Andy Peters

Up and running on Render.com with a Ruby on Rails app and a static site

Andy Peters — Fri, 02 Apr 2021 13:05:50 +0000

I have a Ruby on Rails app and static site to support my SaaS app both now hosted on Render.com. Good things have been said about Render and now seemed like a good time to compare the cost and health of my app to running on Heroku.

As I dove into hosting there here are some things I noticed right away when coming from Heroku:

No "App" and no "Dynos". There are "shared environments" and, everything is a "service".
No heroku run rails c from my terminal.
Sometimes you use render.yaml I guess.
Dashboard is barebones, but who cares I am barely using it after setup.
Daily cost breakdown was neat.
Slack notifications were handy.
Scale services up, not down.
Basic metrics per service is good enough for now.
Use the LogDNA add-on.
yay http/2 support!

I spent about an hour getting everything running 💯; including external DNS configurations. For the most part I followed Render's docs and went the manual setup direction. I went the manual route so I could see everything stand up on its own.

If I remembered everything, this is how I got it up and running...

1. Static site

Cost: $0/month up until 100GB, then $0.10/GB.

Easy to setup. Here's my setup: I have a separate rails repo for the static site and use Bridgetown to generate it. Setup is easy and I followed step one and two of the Jekyll setup docs. I'm sure you can figure it out for whatever static site generator you are using; they also have docs for a few others. Here's the steps I did to get it running:

Link to its GitHub repository.
Build command is yarn deploy.
Publish directory was ./output
Point my DNS to it.

Speed? Here's my unscientific thoughts on speed: It's now quite a bit faster than my free Netlify site was.

Neat to have them all on platform too.

2. health-check gem

I used the health-check rubygem to ensure the Rails app and its services were up and running correctly. It was handy to me and will be a good uptime / health check later in the future.

This ruby gem is not a requirement by any means. Maybe you already know about it or have something setup. Another bonus, the Rails app service on Render can have a "Health Check" endpoint. Neat.

3. Redis

Cost: $7/month Starter Plan 512MB with a shared CPU.

I used the “Deploy to Render” option here; pretty straight forward.

Cool that redis isolated to your environment and not publicly available. The redis service has basic metrics on RAM, CPU usage in the dashboard. Hopefully this is enough redis for my needs. I know I can always run another server as well.

Keep the redis URL handy for your Rails app. It'll be something like: redis://redis-whateverthenameis:10000

FYI: They have plans on the roadmap for a managed Redis more like Heroku I guess..

4. Create Database

Cost: Standard $20/month (1GB RAM, 1 CPU, 16GB SSD)

I went with the next up database plan for my app. There is a perfectly fine $7/month plan that I could have used and upgraded from, but I wanted to start here.

PostgreSQL was also “Click to Deploy”. Just pick the size of server. Remember you can size up, but no downsizing on Render. The basic db needs are covered: Nightly backups and basic metrics.

What you name the Database Service is what the database will be created under and the prefix of the username will be.

They are Postgresql version 11 and I noticed their roadmap indicates version 12 coming soon. This isn't a problem for me.

NOTE: The DATABASE_URL was automagically setup when I created the rails app in step 6. I did move that to a shared environment so the worker could access it; which I setup next.

5. Create your Environment Group

Perhaps doing this before my Redis step is smart. However, I didn't do this until after the database setup and I'm just walking through the steps I did best I can remember.

A environment group allows you to share environment variables and secret files across your Rails app and its workers. I have DATABASE_URL, RAILS_MASTER_KEY, SECRET_KEY_BASE, REDIS_URL etc in there. I only have one shared environment and its called “production”.

You don't need an Environment Group. It is handy to share the environment variables between the worker and web service though.

6. Rails Application

Plan: Starter+ $15/month

The Deploy Rails documentation was full of stuff for creating an app. Skip past all that to the "Go Production Ready".

I did all the app changes from the doc. I now have a render.yml and a bin/build-render.sh and the changes to puma.rb in my project and all of that was from the docs.

The deployment failed a few times until I had all my environment variables setup. I forgot a few, oops.

Be sure to linked to your configured Shared Environment if you have it.

Once it deployed, I set configured the custom domain to it. When you do that and the DNS is verified it'll create and manage your SSL certificate.

7. Background worker service (Sidekiq)

Plan: Starter+ $15/month

In Heroku you'd have a "Worker Dyno". Here you have a Worker Service. I over simplify a worker service to be a “web service” that is not publicly available. Its linked to the same repo, deploys at the same time but no public address and the start command is different. I set the start command to bundle exec sidekiq -e production; from the old Procfile.

Be sure to linked to your configured Shared Environment if you have it..

8. 🤞🏻

Now when I look at the dashboard I have a database, a web service, a static site, a redis service and a worker service.

Hopefully I didn't forget anything and this was helpful for anyone with a Rails app wanting to get up and running on Render.

If you are looking for a Render vs Heroku comparison there are a ton available. Here is Render's Render vs Heroku comparison. However, it was hard for me to not compare the cost savings from Heroku. Before I was on a pretty typical “SaaS starter package” at $150/monthly. There are obvious differences with Render, but I'm pretty pumped that I'm now just roughly $57/month. Where Render lacks in bells and whistles, it makes up in cost savings, a great platform and the team hustle (all very active on Twitter especially the founder and elsewhere on the internet and in their forums).

Heroku might be expensive but its very truth worthy. I'm hoping Render earns the same trust over time. They sure seem to be earning many others. While they host host my app and static site, I'm hoping they'll earn mine.

Setup Bridgetown to use TailwindCSS

Andy Peters — Fri, 09 Oct 2020 19:40:02 +0000

I've been using the Ruby powered static site generator: Bridgetown for a lot of things lately. If you don't already know, here is the Bridgetown tagline:

A Webpack-aware, Ruby-powered static site generator
for the modern Jamstack era.

I'm a Ruby on Rails fan and, TailwindCSS believer and I'm all in on TailwindUI. So naturally, I wanted to use this stack to build my site. Andrew Mason had a great writeup to setup Bridgetown with TailwindCSS, but for the life of me I couldn't get TailwindCSS to build with those instructions. After getting things to work on my end, I think the difference was in the PostCSS and/or the index.scss file but I'm still not 100%. 🤷🏻‍♂️ Here is his detailed write up:

Build and deploy a static site with Ruby, Bridgetown, TailwindCSS, and Netlify

Andrew Mason ・ May 7 '20

#ruby #tutorial #beginners #bridgetown

Since everything is working just fine today, I thought I'd write up my steps. This is assuming you have a Bridgetown site created and ready to go:

Note this is with Bridgetown 0.17.1

1. yarn add ...:

yarn add -D postcss autoprefixer postcss-import postcss-loader tailwindcss

It's my understanding that postcss is a dependency of postcss-import and postcss-loader. So I didn't need to call it out here, but I did anyway for verbosity when I was trying to get things working.

2. Create `tailwind.config.js`

Easiest way to do this: npx tailwindcss init

module.exports = {
  future: {
    // removeDeprecatedGapUtilities: true,
    // purgeLayersByDefault: true,
  },
  purge: [],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

3. Create `postcss.config.js`

Here is a copy of my postcss.config.js file. It was actually taken from an old Jekyll site doing the same thing. Seems to work. 🤷🏻‍♂️

const purgecss = require("@fullhuman/postcss-purgecss")({
  content: ["./src/**/*.html", "./src/**/*.md", "./src/**/*.liquid", "./frontend/**/*.js", "./src/_data/**/*.yml"],

  defaultExtractor: content => content.match(/[\w-/.:]+(?<!:)/g) || []
})

module.exports = {
  plugins: [
    require("postcss-import", {
      path: "frontend/styles",
      plugins: []
    }),
    require("tailwindcss"),
    require("autoprefixer"),
    ...(process.env.NODE_ENV == "production" ? [purgecss] : [])
  ]
}

4. Update `webpack.config.js` to use postcss.

There is only one change I did and that was to add "postcss-loader" on line 56. Here is a full copy of the file for reference:

const path = require("path");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
const ManifestPlugin = require("webpack-manifest-plugin");

module.exports = {
  entry: "./frontend/javascript/index.js",
  devtool: "source-map",
  // Set some or all of these to true if you want more verbose logging:
  stats: {
    modules: false,
    builtAt: false,
    timings: false,
    children: false,
  },
  output: {
    path: path.resolve(__dirname, "output", "_bridgetown", "static", "js"),
    filename: "all.[contenthash].js",
  },
  resolve: {
    extensions: [".js", ".jsx"],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: "../css/all.[contenthash].css",
    }),
    new ManifestPlugin({
      fileName: path.resolve(__dirname, ".bridgetown-webpack", "manifest.json"),
    }),
  ],
  module: {
    rules: [
      {
        test: /\.(js|jsx)/,
        use: {
          loader: "babel-loader",
          options: {
            presets: ["@babel/preset-env"],
            plugins: [
              ["@babel/plugin-proposal-decorators", { "legacy": true }],
              ["@babel/plugin-proposal-class-properties", { "loose" : true }],
              [
                "@babel/plugin-transform-runtime",
                {
                  helpers: false,
                },
              ],
            ],
          },
        },
      },
      {
        test: /\.(s[ac]|c)ss$/,
        use: [
          MiniCssExtractPlugin.loader,
          "css-loader",
          "postcss-loader",
          {
            loader: "sass-loader",
            options: {
              sassOptions: {
                includePaths: [
                  path.resolve(__dirname, "src/_components")
                ],
              },
            },
          },
        ],
      },
      {
        test: /\.woff2?$|\.ttf$|\.eot$|\.svg$/,
        loader: "file-loader",
        options: {
          outputPath: "../fonts",
          publicPath: "../fonts",
        },
      },
    ],
  },
};

5. Update the main stylesheet

frontend/styles/index.scss

@import "tailwindcss/base";
@import "tailwindcss/components";
@import "tailwindcss/utilities";

UPDATE:. I also had used the @tailwind in the config and it worked fine. I switched to the @import as I think that is the correct way when working with postcss-import (as detailed on the Tailwind site).

More details here

6. Start the server

yarn start.

🚀

6.5: If you are using TailwindUI, then simply follow the instructions on the site documentation. You'll just be adding the `tailwindui` plugin as the instructions indicate.

That's it. Enjoy!

Oh, just incase here is Bridgetown on Github:

bridgetownrb / bridgetown

A next-generation progressive site generator & fullstack framework, powered by Ruby

Bridgetown

Bridgetown is a next-generation, progressive site generator & fullstack framework, powered by Ruby. Bridgetown takes your local content and external data loaded from APIs; renders templates in Markdown, ERB, and many other formats; automatically compiles frontend assets via esbuild; and exports a complete website ready to be served by fast CDNs like Render or traditional web servers. Bridgetown also integrates closely with Roda for fullstack, dynamic web application functionality—but only when and where you need it.

Special Thanks to Our GitHub Sponsors! 🙏 🎉

Say howdy 👋 to our blossoming list of current and past sponsors of Bridgetown on GitHub You too can join this list and sponsor open source "alt" Ruby development.


@svoop	@rahoulb	@joshuap	@skvk	@monfresh
Website	Website	Website	Website


@renuo	@subsevenx	@collindonnell	@nbkkb7x	@bpo
Website	Website	Website	Website


@DRBragg	@andrewmcodes	@karloscarweber	@swilgosz	@ttilberg
Website	Website	Website	Website	Website


@Brem-LLC	@posiczko	@fuzzygroup	@maxveldink	@oleingemann
Website	Website	Website

…

View on GitHub

Creating a modal dialog in Tailwind CSS and Alpine.js

Andy Peters — Tue, 17 Mar 2020 00:15:10 +0000

Recently I converted an application I'm working on from a Bootstrap 4 theme to Tailwind CSS and Alpine.js. During that process, it was not immediately obvious (to me) on how to open a full screen modal window dialog clicking of a button; and close it again. At the time I didn't get far searching Google, Dev.to or GitHub. After figuring it out, I thought it warranted a short write up. I'm assuming you are all setup with TailwindCSS or AlpineJS; here we go...

Versions: At the time of this article, this was all done using Tailwind CSS 1.2 and Alpine.js 2.2.0

Reminder, it is not TailwindCSS's responsibility to provide a way to create a modal window. Tailwind is the CSS framework. Alpine.js is just commonly referenced in the Tailwind community in creating a modal, dropdowns, as well as other interactions.

Alpine.js didn't give me much to start with in the README.md. For example currently it only shows a dropdown: AlpineJS Use dropdown/modal

I needed these things to get everything work:

Enclosing <div> with x-data="{ open: false }" tag. This <div> will enclose the next few tags.
<button> with the x-show="open" tag. The button can be styled however you want of course.
Dialog <div> with x-show="open" tag. I also styled this <div> for the darker background when the modal was displayed: style="background-color: rgba(0,0,0,.5);". I couldn't get another class or another <div> inside to do this. 🤷
- Maybe you want this?: On your dialog <div> add @click.away="open = false" so when your user clicks off screen it'll go away.
Enclosed in the <div> dialog, you'll need a <button> tag with @click="open = false", to ensure it'll close the modal when clicked.
BONUS: Animations. Some excellent animations to really make the opening and closing of your modal pop.

Copy / paste-able example:

I have all of this inside the main container of the app layout.

    <!-- modal div -->
    <div class="mt-6" x-data="{ open: false }">

      <!-- Button (blue), duh! -->
      <button class="px-4 py-2 text-white bg-blue-500 rounded select-none no-outline focus:shadow-outline" @click="open = true">Open Modal</button>

      <!-- Dialog (full screen) -->
      <div class="absolute top-0 left-0 flex items-center justify-center w-full h-full" style="background-color: rgba(0,0,0,.5);" x-show="open"  >

        <!-- A basic modal dialog with title, body and one button to close -->
        <div class="h-auto p-4 mx-2 text-left bg-white rounded shadow-xl md:max-w-xl md:p-6 lg:p-8 md:mx-0" @click.away="open = false">
          <div class="mt-3 text-center sm:mt-0 sm:ml-4 sm:text-left">
            <h3 class="text-lg font-medium leading-6 text-gray-900">
              Modal Title
            </h3>

            <div class="mt-2">
              <p class="text-sm leading-5 text-gray-500">
                Adipisci quasi doloribus. Veniam veritatis dignissimos. Quis maiores ea. Et nulla sunt.
              </p>
          </div>
        </div>

          <!-- One big close button.  --->
          <div class="mt-5 sm:mt-6">
            <span class="flex w-full rounded-md shadow-sm">
              <button @click="open = false" class="inline-flex justify-center w-full px-4 py-2 text-white bg-blue-500 rounded hover:bg-blue-700">
                Close this modal!
              </button>
            </span>
          </div>

        </div>
      </div>
    </div>