Download - Coimbra rb | microservic'ing and sinatra
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