PoNG: 10 Reasons to Rethink the Web

Aus MH
Version vom 31. März 2014, 07:11 Uhr von Mh (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „UNDER CONSTRUCTION == Scaling of Dynamic Web Sites == What do you think scales better: # Classic Web Application Server or Web Portal Server: ** Server: Loa…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

UNDER CONSTRUCTION

Scaling of Dynamic Web Sites

What do you think scales better:

  1. Classic Web Application Server or Web Portal Server:
    • Server: Load Data
    • Server: Crunch to HTML
    • Net: Deliver HTML
    • Client: Render HTML to Page
  1. PoNG style
    • Server: Load Data
    • Net: Deliver Data
    • Client: Crunch HTML
    • Client: Render HTML to Page

What are the facts:

  • If it really dynamic, the server has to render the page for each client individually -- for each request.
  • Clients have more computing Power than the server, all clients in summary factors better
  • The net traffic round about 1000 times higher in the classic case, since HTML is so huge, compared with the raw data

Client Computing Power

Portal Projects

I've seen and done a lot of web application programming projects. We have JPA and a lot of good frameworks, but crunching good HTML is still a lot on programing work.

MVC Life Cycle

TODO

Barrier Free Web

TODO

Device Independency

TODO


The light weight JEE Portal

No joke: Some Project, the customer defined a standard JEE Portal server to use. So we purchased licenses, to build up a cluster -- expensive Licenses.

Then we stripped out all the good built in features -- WIKI, Chat, User Management ... -- because of security issues.

Finally an other part of the project came with the deployment -- and it was an "iFrame Portlet". All the rendering was done on the Tomcat in the backend tier.

Is there a better way to waste money?