microservic’ing with sinatra@linkedcare

Joaquim Adráz

and

mrbessajoaquimadraz & croudcarejoaquim.adraz@linkedcare.com@

prolinkedcare & mylinkedcare medic & patient

prolinkedcare app

• Electronic Prescription

• Video Consultation

• Electronic Health Record

• Schedule

mylinkedcare app

• Physical Activity Tracking

• Vital and Biometric Data

• Medication Alarms

• Appointment Scheduling

Medic & Patient Link

• Shared Electronic Heath Record

• Automatic Medication Alarms on prescriptions

• Video Appointments between apps

Pro My

Schedule

Bio & Vital

Sensors

Medication

Prescription Report

Analytics

Reference Data

UID

Linkedcare Services

Service Oriented Design Behind linkedcare’s micro services

!

“The goal of SOD is to split up the parts of an application into components that can be iterated

on, improved and fixed…”

Service Oriented Design with ROR Book by Paul Dix

Topologies

Service Oriented Design Behind linkedcare’s micro services

Service Oriented Design Behind linkedcare’s micro services

Client

ScheduleBio & Vital SensorsUID

Pro

• Current topology;

• Micro services control well defined and secure;

• Best for monolithic to service oriented design;

• Single point of failure;

• Latency.

Service Oriented Design Behind linkedcare’s micro services

!!

ScheduleBio & Vital SensorsUID

Client

• Future topology;

Pro

• Client controls micro services;

• “There’s no more” a single point of failure;

• Latency;

• Exposed micro services.

Service Oriented Design Behind linkedcare’s micro services

!

3 rules to build a micro service @linkedcare

Service Oriented Design Behind linkedcare’s micro services

!

• Small services with small tasks;• Well defined boundaries;

• Business logic for who needs it;

Service Oriented Design Behind linkedcare’s micro services

!

• Use well known standards and conventions;• RESTful APIs:

• Standard HTTP methods;

• One does not simply use POST /v1/events/1 to delete an event;

• Use HTTP Status Codes, and everything will be 200.

Service Oriented Design Behind linkedcare’s micro services

!

• Use only the necessary tools for the job.• We want MICRO Services;

• Lightweight and flexible systems;

• Sinatra is one of them..

Service Oriented Design Behind linkedcare’s micro services

!

• Isolation;

The goods

• Surviving lost of functionality;

• Scalability.

• …

Ruby doesn’t scale, but services do!

Service Oriented Design Behind linkedcare’s micro services

!

• Distributed system complexity;

The “not so” goods

• Dev Ops overhead;

• Synchronization;

• …

!

!

Sinatra rb "Sinatra is a DSL for quickly creating web

applications in Ruby with minimal effort"

The right tool(s) for the job* Behind linkedcare’s micro services

1. gem install ‘sinatra’

Sinatra rb Behind linkedcare’s micro services

3. ruby app.rb

require ‘sinatra’ !get ‘/’ do “Hello!” end

2.

Sinatra rb Behind linkedcare’s micro services

[2014-05-15 21:00:00] INFO WEBrick 1.3.1 [2014-05-15 21:00:00] INFO ruby 1.9.3 (2013-06-27) [x86_64-darwin12.5.0] == Sinatra/1.4.4 has taken the stage on 4567 for development with backup from WEBrick [2014-05-15 21:00:00] INFO WEBrick::HTTPServer#start: pid=5343 port=4567

Sinatra rb Behind linkedcare’s micro services

• Sinatra is written over 2000 lines of code, it’s 1% of Rails;

• Fast, flexible and light… like our micro services should be;

• Active Record, Rake tasks, Rspec, Bundler… it’s all available.

The goods

Sinatra rb Behind linkedcare’s micro services

• It’s pure Ruby, all Rails magic its gone;

• Structuring an app can bring some pain;

• There are some gems that only work well with Rails.

The “not so” goodsFor Rails only devs

Inside a Sinatra App Behind linkedcare’s micro services

erb :index # renders ./views/index.erb

erb :"home/index" # renders ./views/home/index.erb

VIEWS

Inside a Sinatra App Behind linkedcare’s micro services

ROUTING

get '/hello/:name' do # matches "GET /hello/foo" and "GET /hello/bar" # params[:name] is 'foo' or 'bar' "Hello #{params[:name]}!"!end

post '/say/*/to/*' do # matches post /say/hello/to/world params[:splat] # => ["hello", "world"] end

Inside a Sinatra App Behind linkedcare’s micro services

ROUTING

delete '/event/:id' do # matches "DELETE /event/1" end

put '/event/:id' do # matches "PUT /event/1" end

Inside a Sinatra App Behind linkedcare’s micro services

HELPERS

require 'sinatra' !get '/:color' do "<b>#{color_world(params[:color])} world!</b>" end !helpers do def color_world(red) red == "red" ? "red" : "yellow" end end

Inside a Sinatra App Behind linkedcare’s micro services

APP STRUCTURE

Classic Style vs Modular Style

Inside a Sinatra App Behind linkedcare’s micro services

CLASSIC | APP STRUCTURE

• require ‘sinatra’

• Uses the TOP Level DSL included when required;

!

Inside a Sinatra App Behind linkedcare’s micro services

MODULAR | APP STRUCTURE

• require ‘sinatra/base’

• DSL it’s not included in Object.

• class MyApp < Sinatra::Base

• DSL available inside MyApp object.

!

Sinatra rb Behind linkedcare’s micro services

DEMO?

Microservic’ing and Sinatra @linkedcare

The nice conclusion

Right now, it’s the best solution for our project!

Microservic’ing and Sinatra @linkedcareSome tips

LinkedBus => Ruby RabbitMQ Subscriber

https://github.com/tdantas/linkedbus

SmoothOperator => Lightweight and flexible alternative to ActiveResource,

https://github.com/goncalvesjoao/smooth_operator

UseCasing => Responsability Centric Design with use cases

https://github.com/tdantas/usecasing

Backshops linkedcare

JOBS linkedcare

http://linkedcare.com/jobs.html

microservic’ing with sinatra@linkedcare

Joaquim Adráz mrbessajoaquimadraz & croudcarejoaquim.adraz@linkedcare.com@

and