Functionaly Separated Web Development

432 views

Published on

The idea is to present a different way of thinking about web development.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
432
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Functionaly Separated Web Development

  1. 1. Functionally separated  web development Marian Marinov mm@yuhu.biz jabber: hacman@jabber.org
  2. 2. Database Templates PHP Code HTML JavaScript CSS ➢You have single place for logic -> the PHP code ➢In the b est case you have alittle logic into the DB  
  3. 3. DATABASE BACKEND FRONTEND SERVER
  4. 4. 1. Database which handles some to all of the  data-oriented logic You should not have tools that:   * retrieve all rows from atable(s)      * checks all rows in atable(s)     * update all rows in a table(s)
  5. 5.   * The database should return only what you  need and what you will use.   * All logic considering only data should b e  contained within the DB.   * SQL and PlSQL stored procedures are your  friends.
  6. 6. 2. Backend software which:   * receive requests   * verify the received information   * retrieve the information from the DB   * insert or update information into the DB   * apply more logic on it   * format it into desired messaging format  XML/JSON/PLAIN TEXT   * send response to the requesting user   * DO NOT GENERATE HTML OR CSS,  generate only content
  7. 7. 3. Server software which:   * handles more complex logic   * keeps a constant state of the system   * executes regular or slower jobs   * should b e implemented only if required by  the design   * can b e replaced by cron jobs
  8. 8. 4. Frontend software   * JavaScript based software    * Use JavaScript frameworks (jQuery,  Prototype, ExtJS)   * Handles all the logic of the user interface   * changes dynamically    * uses only client resources for changing   * requests content from the server   * sends actions to the server
  9. 9. 5. Requirement of this architecture   * You have to use the same messaging  format b etween common modules   * Parameters b etween modules MUST b e  negotiated in the b egining   * You should use common error report codes
  10. 10. 6. Benefits of the architecture   * Ease of adding new modules   * Ease of extending current modules   * You are not aslave to asingle messaging      format   * Having different versions of the frontend  doesn't require different versions of the  backend   * Better scalability    * Better p erformance (since almost all of the  frontend logic is computed at the client side)
  11. 11. THANK YOU Marian Marinov System Architect at Siteground.com mm@yuhu.biz hackman@jabber.org http://hydra.azilian.net

×