WebFund 2016W Lecture 21: Difference between revisions
Created page with "==Video== The video for the lecture given on March 29, 2016 [http://homeostasis.scs.carleton.ca/~soma/webfund-2016w/lectures/comp2406-2016w-lec21-29Mar2016.mp4 is now availab..." |
(No difference)
|
Revision as of 20:47, 29 March 2016
Video
The video for the lecture given on March 29, 2016 is now available.
Notes
In Class
Lecture 21
----------
* interactive-graphs-sol will be posted after lecture
* study session on April 11th, time TBD (final is on April 12th) but will be in the morning.
(Earliest is 10 AM).
What did I leave out?
First, what did we cover?
- JavaScript
- Some HTML, CSS
- clients versus servers
- HTTP
- synchronous versus async code
- callbacks
- Node, Jade, Express
- browser developer tools
- closures, lexical scoping
- a little networking
- databases
- noSQL, MongoDB
- queries
- a little crypto (SSL, certificates, password hashing)
- a little security
(cross-site scripting, input validation
- client side versus server side JavaScript
- jQuery
- DOM basics
- basic AJAX
Left out...
- much more to HTML, CSS
- much more to the DOM
- more to AJAX, client-server communication
(e.g., WebSockets)
- SQL
- transactions
- indexing *
- PHP
- language + HTML templates
- instead we learned Node + Jade
- Meteor, AngularJS, ...
client-side JS libraries and frameworks
- other server-side languages & frameworks
- ASP.NET, .NET, Java-based frameworks,
Ruby on Rails
- every programming language has multiple
web frameworks
So, is this how the "big players" do the web?
- facebook, google, etc.
They have
- more servers
- challenge is how to *use* them
HTTP is inherently stateless. How do you scale stateless?
- replicate, load balance
- to store state, make state store bigger
- need bigger database!
Big websites have some mix of:
- scalable databases
- replicate application servers
- caching for static content
E.g., ecommerce
- while shopping, users get static content
- easy to scale
- but purchases have to hit the database
- and have to generate writes
To scale you have to engineer the system
- but you don't need to change your basic application
Security?
- input validation/sanitization
- don't let the user talk to the browser, server,
or database directly - no code injection
- use reasonable crypto
- communications security (SSL/TLS)
- authentication (passwords, etc)
- security policy
- what is allowed, what is not
- how to enforce
Networking?
- latency versus bandwidth*
- IPv6
- firewalls
- NAT
Cloud computing
- remote servers where there are LOTS of remote servers
- challenge is in coordinating applications across
all of those servers
- basic tools is virtualization
- easier to manage a virtual server than a real one
- Give me 10,000 servers for 2 hours
- cloud servers run web apps, almost entirely
Amazon is the real "parent" of cloud computing
- they got into the cloud because of Christmas
- they had servers that were doing nothing 11 months
out of the year
- so why not rent them out
- they provide more and more infrastructure for
building large web applications, based on their
internal tech
Networking
The Internet is a network of networks
SCS network is connected to the Carleton backbone
which is connected to the Unicentre's network. The
backbone also connects to Carleton's ISPs (ISPs)
Firewalls on the Internet block all kinds of network traffic.
Mainly for 'security reasons'
Now, arbitrary network traffic gets routed through HTTP.
Because it can reach all of the Internet
- other protocols get squeezed into HTTP
WebRTC
Learn networking but realize modern networks just ship HTTP
* Databases, indexes
* Security
- web security issues
* The future
Posting Assignment 5 solutions now