Web Application Architectures

Design Patterns

Client - Server Model

• n-tier Architecture : Each tier provides a specific functionality and interacts with adjacent tiers through well defined interfaces.
• Early web-apps were 2-tier client architectures. Server served mainly static web pages.
• 3 Tier Architecture : Most common : Presentation Tier, Application Tier, Data Tier
• App Tier divided into : Business Logic Tier, Data Access Tier (insulates from specific DB)
• Presentation Tier divided into : Client Side UI components, Server Side UI components that generate web pages.

Rails

• Rails is a Ruby gem.
• Uses a lot of code generators, automated testing scripts etc.
• Provides additinal tools such as Rake - to create/migrate databases, clear web session data etc.
• WEBrick is the web server that is bundled with Rails.
• Rails directory structure :

Philosophy

• Convention over configuration : Ideally, dev should only specify the unconventional parts of the web-app : Models, view, controllers, tests auto created using certain conventions.
• DRY : Every piece of information should have a single unambiguous authoritative representation within the system. e.g, model maps directly to DB column name and is kept in sync if used correctly. Therefore, makes it easy to use code-generators, automatic build systems.
• Agile Development : Emphasizes working software as the primary measure of progress. In dev mode, there are no recompile, deploy, restart cycles. Testing is built into Rails.
• XP is an agile approach that centres around TDD. BDD extends TDD by writing test cases in natural language that non programmers can read. So all stakeholders can be involved easily.

Distributed Version Control

• No centralized repository, users check out the entire repository.
• When someone checks the project back in, the proj. is marked as a different version of the repository.
• So Distributed VCS is like storing snapshots of the project over time (as compared to storing delta's of individual files in centralized VCS)
• It is upto the owner of the repository to merge different versions together if he chooses to.
• Individual developers can also collaborate with each other as opposed to going through any "central" system.

Git

• Git essentially provides means for comparing differences between various versions of a project and to merge them accordingly.
• Main dev. branch is the master. New versions can be created along the master branch, or new branches created off it (e.g. a new feature)
• Then these branches are merged back into the main branch.
• In Git, the repository can be hosted locally or remotely.
• Sites like GitHub, Bitbucket provide remote repository hosting.
• Changes can be pushed from the local git repo to the remote git repo.

mkdir repo1
cd repo1
git init #Initializes git repository
git add . #Add all files to git (to the staging area)
git status #Shows the files that need to be committed
git commit -m "First Commit" #Commits the changes to the local repo
git status #Will show that we are on master branch with nothing to commit
#make edits to the file, git recognizes file has changed and will not allow commit
#instead we need to git add first. Or can do it one shot :
git commit -a -m "2nd commit"

• Push to remote repository : push <remote> <branch>
• Retrieve is fetch (all branches) and then checkout the branch
• Pull does a fetch and checks out the most recent branch and makes it the master
• Clone creates repo initially and then use pull commands

#git remote add <remote-repo-name> <remote-repo-url>
git remote add origin https://suhridk@bitbucket.org/suhridk/test1.git
#git push <remote-repo-name> <remote-branch-name>
git push origin master

Database Interactions

• When scaffold generator is run, rails creates a db migration file (inside db/migrate dir)
• Rails uses the rake command to run the migrations - which creates the schema (SQL statements), from which the db is created.
• The schema file contains the timestamp and migrations are run in order of timestamp - this allows undo of previous migrations.
• rails sets up app's to run in one of three environments (custom env's can also be defined)
  • Development : src changes immediately reflected, uses sqlite
  • Test
  • Production : src changes not reflected, rails optimizes delivery of assets : css/js etc.

rails server #uses dev environment
rails server -e production #prod