PostgreSQL & Application Architecture

Traditional Thinking

Before Rails

• Manage data in the database

• Assume you will different server side languages

After Rails

• Do everything in Rails

• Assume you change databases

Why?

• Databases didn’t do much well

• MySQL was the standard for what your application database could do– Writing procedures/functions/triggers was hard

• Oracle and SQL Server cost money even though that had many more features– Procedures/database logic is much easier

• Do everything in your app results in quicker product release

Downside

• Introduce race conditions / data corruption• Locked into server side code base/framework• Must depend on API to read/write data• SOA requires an entire API layer between services

and different data– Extra server load– Unnecessary code– Additional bottlenecks– Additional coding time– Internal services do not need an API layer

Enter PostgreSQL

• Functionality that meets or exceeds Oracle/SQL Server

• Free, open source and easily able to replace MySQL

• Easier to write logic to use this functionality

The “before” Rails way

• Database manages your data• Data in the database is always correct• Create different users with different database permissions

– Exactly what can this user read from, write to?– Give a user access to specific procedures instead of the tables

directly

• No need for internal API– SOA can connect directly to their database– Faster internal connections, no overhead

• Connect with as many different languages as needed– Free to use the best solution to the problem– Write your API in Go / Node / Java without those requests

hitting Rails

TALK TO OUTSIDE SYSTEMS

But PostgreSQL can also…

Rails w/ PostgreSQL way

Use the database…• Enforce data integrity• Handle data-specific logic• Avoid race conditions• Avoid data corruption• Process, sort, compute large

data

Use the application(s)…• Create many services accessing

the same database– In different languages if needed

• Visualize the data• Control your user experience

Do BOTH

DATA CONTROLS THE APPLICATION

And because PostgreSQL can talk to outside systems...

But wait…there’s more

We also simplify our application

Because PG can do so much…

• Like various search techniques– So we only rarely need an outside engine

• It can do asynchronous logic– So we don’t need a special database for that

• It handles multiple types of unstructured JSON data…fast– So we don’t need a NoSQL database

• It has extensions that replace many outside system needs (like GIS data)– So we don’t need to run a lot of extra tools

• With Postgres-XC it scales out for reads and writes– So we can use it in the cloud easily– And we don’t need a special database just for write loads

• Since it can return query results as JSON– We don’t have to overload our web server processing large data API responses

• It can talk to outside systems via Foreign Data Wrappers– We don’t have to use an application to relay/process/compare data between PG and…

• Redis, Memcached, MongoDB, etc

• Outside systems can listen for events in your data without polling– Meaning thousands of parts can listen for changes in one place with no stress

• And you can do all of these things in a variety of languages– Python, Javascript, R, Perl, etc…

Multi-Tenant

• PostgreSQL has schemas

• Schema let you use the same tables under different names

• Schema-per-customer

• Subdomain-per-customer

• Subdomain-per-Schema

– Built in sharding from the start

And yes, there’s a gem for that

• Apartment Gem

– https://github.com/influitive/apartment

• Rack maps the subdomain to the schema for the request

• Tools to handle your migrations and management

• Tools to share data (users) globally

What are you writing?

Building a Gem?

• Abstract the solution

• Don’t hook directly to a DB– Utilize ActiveRecord

• Don’t specify a JSON parser– Use MultiJSON

• Don’t specify an HTTP library– Use Faraday

Building an App?

• Solve your problem

• Use YOUR tools

And if you combine that…

With a fully load app server like Torquebox

Then you go from this…

To this…

And eventually this…

Remember

With great power…

Comes your final project…

• Improve your application

– Find something you want to do to it and figure out how to do it

– No reason or explanation needed

– Criteria

• Learn something new

• Use it

• Figure out how the database can help you

• Learn and do

Due 9/21/2014 by 8pm

Turn in code via BitBucket

Share with my user ‘aramisbear’

9/24 we will meet up in Greenville for Graduation (optional). Location TBA.

If that seems open ended…

• My #1 criteria for observing success in a programmer is desire to learn– If you have that you won’t stop learning– You’ll get a lot better– You’ll better understand your tools– You’ll see problems as learning opportunities– You’ll do all this because you enjoy it

• And that is where real success is

• I coach interviewers to get a programmer to geek out about something they work on– Any programmer that can get excited about the details of how

they solve problems is going to succeed– This technique has yet to fail me

Lots of reference material

• Railscasts - http://railscasts.com/• Ruby Tapas - http://www.rubytapas.com/• GoRails - https://gorails.com/• Rails Guides - http://guides.rubyonrails.org/• Rubygems - https://rubygems.org/• Ruby Warrior - https://www.bloc.io/ruby-warrior/• Try Ruby - http://tryruby.org/levels/1/challenges/0• Rails for Zombies - http://railsforzombies.org/• Rails Tutorial - https://www.railstutorial.org/• PostgreSQL -

http://www.postgresql.org/docs/9.3/static/

You have a powerful set of toolsShow me you can use them and you graduate. That simple.