A way to execute the backend code in the web browser instead in a web application?_问答_开发者

Is there a way to execute the backend code (ruby) in the web browser instead in a web application (rails)?

Cause I wonder why all the code should be executed in the server, isn't it bad architecture.

It开发者_StackOverflow中文版's like the same concept of SVN, it is very dependent of the server, rather than having a more distributed architecture like Git, every client executes the backend code. In that way it will free performance load from the web server and it could handle more clients cause today's computers are quite performable on the client side.

The client will communicate with the database through the backend server, but the backend will not contain all the application code, just for the communication part. The server code on the client will be compiled.

Isn't this actually a better approach to solve performance load issues?

I think RIA applications built using Adobe Flex etc / Silverlight are moving in that direction itself. You should look at some of these if you want to do a lot of things on the client rather than the server.

However, there has always existed the old client - server paradigm of building applications. Technologies like VB6, Powerbuilder, Oracle2K etc and their current avatars like WPF/ Windows Forms/ Oracle Forms all provided with a way of doing more on the client side rather than doing everything on the server.

Also, moving all the application logic - other than DB communication logic - to the client means that you are moving back to the thick client way of doing things - which has its benefits but also its drawbacks compared to the thin client model of web applications.

The deployment / upgrades of thick client applications ; support for multiple client OS'es / varying client environments which could potentially make your application performance unpredictable are just some of the issues why there was a move away of thick clients to thin in the first place. Inspite of technologies like ClickOnce which help with deployment, these issues still exist - in varying degrees even today.

Hence its a tradeoff as to whether you choose a thick / thin client depending on your needs.

You can't run Ruby code in the browser, but you can certainly offload some things to it. Javascript and Flash are probably the most common languages for client-side scripting. The limitations of client-side work are mostly about security and data. For security purposes, many things have to be done server side. And typically your server has a much better connection to the data stores than the client will, so its often more efficient to do work on the server.

The most common reason to use heavy javascript/client side scripting is for responsiveness -- it's not so much that you've offloaded the CPU-intensive work to the client, but the client's perceived responsiveness will obviously be much better if they don't have to hit the server to perform an action.

One problem with running code on the client is that you need to be much more careful of security issues. The server is a known/controlled environment, and can be well tested before deploying the application. If you're releasing the application publicly then you never know what the configuration of a client machine is going to be, so you may have to cater for different configurations, and your code is a lot more open to abuse, either accidentally or maliciously.

Security.

If this was an e-commerce application, you most definitely don't want the client to run the backend code, as then some unscrupulous person could modify a financial transaction for example. It is much easier to control data and ensure its security when it all resides on the server (think health records).

Another example is form validation. While the client code can perform input validation, the fact that it's located on the client means it can be bypassed. That's why servers will (should) validate all user input before processing it, even if the client code has already performed validation.

An interesting idea would be an architecture that allows for an admin users' browser to execute code for the validate of non-admin users.

A server would still be required for the event that no admin users are online when a non-admin user is performing a request that requires validation.

This is of course an extremely complicated architecture but has the potential to save on server-side hosting costs for the use case where validation can be offloaded to another users computer.