NYCPHP Meetup

[David Krings]

Elliotte Harold wrote:
> David Krings wrote:
>>
>> But isn't that the old GET that has so many limitations that many web 
>> app design guides basically tell you not to use it?
> 
> I have no idea what you're talking about. GET is GET. There's no old GET 
> and new GET that I've ever heard of.

Bad wording on my part. The talk went from states and sessions and 
whathavenot to the Google URL example, which is nothing more than 
passing form info via GET. It came across as this is a great new way of 
solving the discussed issue, which indeed it isn't as it is a plain GET 
mechanism that is around for ages.


> It's certainly true that there are a lot of bad web app design guides 
> out there. Most of them try to reinvent client server on the web.

Uhm, isn't browser and server the purest form of client server? The 
server doesn't to crap without the client constantly asking for it. 
There are ways to improve that with AJAX or server side scripting like 
PHP or a combination of both (which is needed when using databases as 
the client cannot connect to the db server directly).
I wouldn't necessarily call the design guides all bad, but they are for 
sure different.

> They're like a manual for plastic molding machines that pretends the 
> molder is really just a funny kind of table saw and drill press. Follow 
> their directions and you'll develop problematic, unscalable 
> applications; and certainly lots of people do.
Which begs the question if every app developed needs to be scalable. If 
there are at any given point in time no more than a few dozen clients 
connecting scalability isn't an issue. So it depends. For the low 
client, one site app I find sessions extremely useful.

> 
>> And it depends on what you transfer in clear text as URL parameters. A 
>> Google search is probably OK, but what if your application is about 
>> sensitive data? You then need to craft identifiers that are dropped 
>> after first use and never used again or some other untraceable 
>> obfuscating mechanism.
> 
> No. You use HTTPS.
Understood....bit with all that security discussion, it is funny that 
nobody focuses any effort on securing keyboards, mice, and monitors. 
Many tests have shown that you don't need a password cracker, but just 
some cheap equipment from Radioshack to record signals coming from input 
devices. That just as a side note.


> 
>> There was also the point made of scalability. As in this example, the 
>> search results are not stored anywhere, but get recreated each time a 
>> request is sent. That pushes the scalability issue from the web server 
>> to the database server, where it may or may not be handled more 
>> efficiently.
> 
> In point of fact, Google uses probably millions (maybe hundreds of 
> thousands but I expect millions) of servers. They need this massive 
> horizontal scalability. To make that work you really need to not care 
> which server processes any given request. Three subsequent requests can 
> and usually do go to three different physical servers. The more session 
> state you try to maintain the harder that is to handle.
> 
> By contrast, if you design apps so they don't need session state, then 
> you can scale horizontally very easily and you need a lot fewer actual 
> servers.

Understood as well...which is why Google and the likes drop sometimes 
massive cookies on the client side. That addresses the scalability 
issue, but is from a security standpoint somewhat questionable, which 
again in case of a Google search is likely a non-issue. This is why I 
routinely dump all cookies except for a few that I know I want to keep 
for convenience.

David