Microservices: Ruby on Rails client application without database

μicroservice architecture, or, simply, microservices, is a distinctive method of designing software systems, where you model every part of your system as separate (micro)service, with it’s own encapsulated behaviour.

What is the benefits?

Separation of concerns. Every microservice must have a distinct business domain (called bounded context in that smart book). If it has any – this mustn’t be a microservice per se.

Low coupling. Everything that change together will change together. High cohesion inside service is the main goal. Forces you to write modular code. No ugly fixes and cheats for you. Sorry.
Independent operations. Since every service has bounded context it has everything it needs within itself. So… You can change services independently. You can deploy services independently. You can mix technologies and use even another language for specific service.
Cheap change. Due to the high decoupling – any part of microservice could be atomically changed. But you need to be aware of public interface of a service. Don’t change it, and you are good to go.

What is the costs?

Distributed computing. Yeees. Very bad. I know. But you need to understand and do more when you has a microservices. And many teams. Assigned to different services
Consistency. It must be the main goal of your app. But sometimes guys from other team introduces breaking changes. And you didn’t notice. And your service will die. Leading, you know… to disaster
Operational complexity. Any microservice must be monitored and deployed separately. Sometimes you need teammates with really different skills, depending on microservices tech stack. Or a big devops team…

So… Have I convinced you already, that microservices is a good fit for your task? If yes, we can start implementing them, using the best framework ever built. Meet Ruby on Rails!

TODO list for your microservices with Ruby on Rails:

Define main application (~~root of all evil~~). You can do this by answering a few questions:
Will database be shared?
Will our app will have one Object Model for different clients?
Will this fancy app have a REST api? Or a message brokers? Assuming we need centralized datastore, we will have a REST API with Postgres database on board. Assuming we define basic object model and refine our business. Stay tuned for the next part. We will dive deep into the ~~evil~~ core app.
Define clients. Yes. Those pesky web, mobile or desktop (or the god know what) applications.
We will use web app in this case
Client will be Rails application too. Didn’t you excited already?
Our client Ruby on Rails application would exists without database (our database will lie in ~~the~~ ~~mother of evil~~ core application). So, behalf:

rails new appname --skip-active-record

And in application.rb

require "active_model/railtie"

# require "active_record/railtie"

require "action_controller/railtie"

require "action_mailer/railtie"

require "action_view/railtie"

require "sprockets/railtie"

require "rails/test_unit/railtie"

# instead of require 'rails/all'

That’s all. No Active~~Super~~Record models, no database. You can start building your new client application. But without database, have you forgotten already? If you strife, you can continue to use session or light indexed db on client.

If this is not enough for you, and you need more…Than I have a gemfile for you:

source 'https://rubygems.org'
ruby '2.3.0' # You can use whenever version you want, but we want to be on edge

gem 'actionpack',    '~> 4.2.5' # For your favorite views
gem 'actionview',    '~>4.2.5'
gem 'activemodel',    '~> 4.2.5' # Models without activerecord.
gem 'activesupport',  '~> 4.2.5' # All things we like
gem 'bootstrap-sass', '~> 3.3.6' # You can use other frontend framework, but bootstrap is soo.. friendly
gem 'sprockets', '>= 3.0.0'  # Sprokets!

gem 'sass-rails', '~> 5.0'  # For styles, just if you need views)
gem 'uglifier', '>= 1.3.0' # Obfuscate this beautiful js
gem 'haml-rails' # It’s really that simple to write better views with this gem
gem 'dotenv-rails'  # This gem will allow you to store all of your ENV in nasty .env file

group :test do
  gem 'simplecov', require: false # testing is important? Have you forgot already? And coverage reporter give you more insights then everyone else
end

group :development, :test do
  gem 'faker' # Fake data! More fake data!

  gem 'pry-rails'  # I hate irb. But if you like it. Just remove...

  gem 'rspec-rails', '~> 3.0' # Testing, testing...
end

group :development do
  gem 'guard-rspec', require: false  # Run your specs automatically. Yeah, baby...

  gem 'guard-rubocop' # Remove every code smell with simple commands

  gem 'rubocop-rspec'

  gem 'quiet_assets' # Assets are so loud sometimes. Just make sure you remove some noise
end