From Idea to SaaS in 30 days, building Qiu

Elijah Goh — Tue, 31 Oct 2023 15:56:48 +0000

Having been a Ruby developer for a decade, Rails was my go-to for building Qiu. It just made sense. Rails provided a treasure trove of tools right at my fingertips. No reinventing the wheel and allowed me to build Qiu from a concept to a live product in 30 days.

Sensible Defaults

Rails comes with great feature from the start, like ActiveJob for background processing, has_secure_password for authentication, mailers for email handling, and ActiveStorage, were invaluable. This blog engine is written using ActionText! 🤯

Convention over configuration is the way

Ruby Gems

Ruby gems was what allowed us to stay productive when building Qiu. Here are some I consider great defaults.

pay-rails - rapid integration of Stripe and other payment types
good_job - what powers our background job, from queuing to sending
nanoid, hashid - URL obsfucuration, allows us to create URLs with nicer slugs than incremental IDs
discard - soft deletion, why code one when you could install one!
bool_at - personal favorite (I made it), DSL for boolean statuses
name_of_person - Easy first name, last name
liquid - templating engine for dynamic data (we use this for our email parser)
ahoy_matey, ahoy_captain - built-in Rails analytics

Analytics

Special mention to Ahoy + Ahoy Captain. It allowed us to add custom tracking without any external requirement, and it is GDPR compliant.

And includes a beautiful UI for analytics tracking.

Coding Convention

I did not follow the skinny model, nor service models very closely.

We deploy a mix of Rails callbacks and model methods to perform tasks.Instead of fighting Rails, we embrace class and instance methods than going immediately for a service class whenever we want to implement something. This allows us to avoid early code bloat and Service class hell early on while keeping code maintainable.

Hosting

Using Render with Docker allowed Qiu to iterate quickly, changing code and deployment only takes 3 minutes.

It allows us to quickly iterate, fix bugs or add features without worrying about deployment times.

And with that

Is what allowed us to build Qiu from idea to MVP in 30 days using Ruby + Rails. Hope you enjoyed this article!

Also, if you want an easier way to send emails, try Qiu.

This article was originally posted in Qiu

Dependency Injection in Ruby 🌈

Elijah Goh — Wed, 10 Jul 2019 09:19:31 +0000

I once wrote an article on Medium about dependency injection - Dependency Injection is not Scary!. Recently joined dev.to, I thought I'd bring my thoughts here as well.

Okay Eli, I know how to dependency inject now thanks to the medium article. BUT WHEN DO USE IT?

Bear with me here, I'll get to that soon. Currently building an inbox feature, I needed a form object for creating the conversation AND responding/editing the conversation.

What I could have done was create a form object, wipe my hands clean and be done with it. Or I could also make this form reusable in other controllers. 🤓

module Inbox
  class ConversationForm < BaseForm
    attr_reader :conversation, :message, :sender

    def initialize(conversation, params = {})
      @conversation = conversation
      @sender = build_sender
      @message = conversation.messages.build(user: @sender)
    end

    ...
  end
end

But making use of dependency injection, I was able to reuse the form for another controller.

module Inbox
  class ConversationForm < BaseForm
    attr_reader :conversation, :message, :sender

    def self.build(params={})
      conversation = Conversation.new
      sender = build_sender
      new(conversation, sender, params)
    end

    def initialize(conversation, sender, params = {})
      @conversation = conversation
      @sender = sender
      @message = converation.messages.build(sender: sender)
    end

    ...
  end
end

I would use Inbox::ConversationForm.build when I want to create a new conversation. In another controller/action, I would predefine the conversation and inject it into the form.

# ConversationsController
# Creating a Conversation
def new
  @form = Inbox::ConversationForm.build
end

# My::ConversationsController
def new
  @form = Inbox::ConversationForm.new(fetch_conversation, Current.user)
end

# BOTH
def create/update
  if @form.save
    render :new
  else
    redirect_to some_path
  end
end

private

def fetch_conversation
  Inbox::Conversation.find(params[:conversation_id])
end

Once again, go forth and Dependency Inject!

DEV Community: Elijah Goh