On 27 Feb 2014, at 17:38, Jason Hect wrote: > Can you elaborate? Do you mean from a security standpoint or something else?
Well this is just my opinion, but there were several reasons why I originally thought the client-server architecture more optimal: [1] - Stability The client application is about 100 to 200 times less reliable than the data server. It is likely to crash several time per year for all sorts of reasons not to do with bad coding. It is simply a very complex piece of software which has to perform thousands of network operations per minute, interacting with a query engine, operating system network layer, possible email servers etc etc. The data server on the other hand is doing a very simple task by comparison and can reasonably be expected to stay up all year without a single failure. By fusing these together, you are making the entire system as reliable as the weakest link in the chain. When the web server fails (and it will) you now have a potential data recovery job on your hands as well which was otherwise entirely unnecessary. In client server mode, when the web server fails it's just a restart - possibly even an unattended one - and end of story. [2] - Security 4D's client-server interface represents a natural firewall which is very secure by comparison with classic architectures such as PHP-SQL. (especially if you use 4D's native query language and switch SQL off on the server). By making the data server co-host the web server you've basically invited the whole world wide web right into your living room and have to now rely on purely a software firewall instead of a hardware one plus a software one. [3] - Performance In a typical eCommerce web request when running client-server, the database querying portion takes up a tiny amount of the overall response time. That's because while each web process is waiting for a query return from 4D server, all the other web processes are free to continue doing web serving. On the other hand, if you host the web server on 4D Server, they are not, because a whole load of processing time is busy running queries for ALL the web processes. So it reaches saturation earlier than a 4D Client web server would. (That's my theory - I haven't actually tested and measured it in practice, but I can safely predict that the data server DOES have to run queries on top of doing web serving whereas the client doesn't). [4] - Scaleability A web server bolted onto a data server is not scaleable. You can only ever have 1 machine doing web serving, whereas with the Client-Server approach you can continue to add clients and load balance them ad infinitum. There's a few for a start. But the one that sticks out a mile for me is stability. Planning to crash your 4D Server 20 times a year is not a good way to start off. Peter _______________________________________________ Active4D-dev mailing list [email protected] http://list.aparajitaworld.com/listinfo/active4d-dev Archives: http://active4d-nabble.aparajitaworld.com/
