Tuesday, September 28, 2010

Where on the web does your app run?

There has been a lot of discussion about our upcoming Web Edition on our beta list which is really great. One thing that some people seem to not be clear about is exactly where your code executes. Allow me to explain.

For those of you that haven't look into our Web Edition, you build web applications in a way that is pretty much identical to how you build a desktop application. You drag and drop, you double-click and create your application logic using the same language you use for the desktop. The difference is where code executes. In a desktop application, all code is executing on your computer as an application. For web applications, your application is on a server so it executes there and sends all the necessary stuff behind the scenes to the user's browser to provide them with your UI so they can use your application.

So from your perspective as the developer, you will develop basically the way you always have using REAL Studio. From the end user's perspective, the app will act very similar to how a desktop app works. Think of a page as a window and it's all the same. We handle the rest of the magic to make it work like that. If that's all you needed to know, stop reading here. If you want more nitty-gritty details, read on.

Let's take a simple app with a single page, a textfield and a button. The button is coded to set the Text property of the Textfield to "Hello World!". You created the app by dragging a Textfield and a Button onto a page. You added TextField1.text="Hello World!" to the Action event of the Button. You built the app and installed it on a server. That's everything you had to do. Now what happens when a user comes along?

When the user enters the appropriate URL to get to your app, our framework (inside your app) goes to work. It turns your page into HTML, CSS and JavaScript on the fly and sends it to the user's browser. The user can type all they want in the TextField, resize the window, etc., but that will not matter because the only thing your app cares about is the Button's Action event. Any other event that occurs will not create any communication with your app on the server because you didn't implement any other event. When the user clicks the button, the JavaScript that was generated to react to that event fires and sends a message to the your app on the server. Your app executes the Action event. And since this updates the TextField, the HTML and CSS needed to update the page are generated by the web framework and sent to the browser where the browser shows the updated page. This all happens really fast. And for each page a user has open, there is an equivalent object in memory on the server that represents that page. This allows us to save the state of that page as the user moves from one page to the next (even though the browser is only showing one page at at time to the user).

The thing that does not happen is any kind of translation of your code into JavaScript. Your code executes on the server and it's fast because unlike most web technologies, your code is compiled to machine code rather than interpreted at runtime.

Over time, we will add more ways to automatically generate JavaScript that takes care of more things in the browser to make communication between the browser and your app more and more efficient. And you will be abstracted from these details so you can focus on what makes your application unique.

If you still have questions, fire away.


Joseph Claeys said...

So how difficult is it to get our web application working on a shared server? Honestly, that's been the biggest hurdle I've had with web programming in general. I liked RoR but tackling the server issue turned me off to the whole thing.

Kundalini said...

Hate to be pushy, but hey! -- I'm going to really need hierarchical listbox. Can you tell me the ETA for that? Thanks! -- and I say again, WE is a brilliant concept.

Geoff Perlman said...

@ Joseph - We are currently working on support for dynamic FastCGI. That will make it pretty easy to get a FastCGI up and running. However, for apps with small number of concurrent users (perhaps 100 or so), you can build your app as a stand alone HTTP Server. Then's it's pretty easy. Just install the app and launch it.

Geoff Perlman said...

@ Kundalini - No hierarchical listbox for the first release but we know people will need it so it's likely to be high on the priority list for the second release. I can't guarantee that of course but we are thinking about it.

Karen said...

Any update on the feasibility and limits of using the REALSQLDatabase in the WE instead of a DB Server?

Allenwc said...

I don't see where it says which web servers the final application will run on?
What settings will be required on the server to make it work?

rlivingston said...

I wish that someone would go through the steps of how do you get a server on the web to host your apps.

I know a little REALbasic and like it. I have a little website using iWeb and MobileMe.

But I have no idea how to marry these things or whether it is possible. How do I get a server access? Is this MobileMe? Is this GoDaddy?

If I just had a very detailed description of how to get a simple program running in a web environment using servers that I can access on the web it would help me. As it is, I don't even know enough to know if this question makes sense.

Claudio Sánchez said...

Hello. I'm reviewing all this Web Edition, and still have to get an asnwer to this question:

"What are the server requirements to run a web server application?"

Will I be able to create a binary web server application that can be deployed as a Windows, MacOS or Linux application?


Geoff Perlman said...

@ clasanch - If you are going to run your app as a FastCGI you will need Apache or IIS. If you build it as a stand alone app, it will run as its own web server. And yes, in both cases, you can compile for Mac, Windows or Linux.

MacATDBB said...

Sounds like a great technology, I'm waiting for some license code glitches to resolve but am really looking forward to testing the concept. It reminds me a little of the compile for javascript option that I think I recall in one of the early (Andrew) versions of RB.

BTW Merry Christmas to all at RS. As I've never made to the dev conference it would be wonderful to have a group picture so I can see some of the folks I've been in touch with over almost a decade now. (or is there an RS flickr site?)

Alyssa said...

@MacATDBB Thanks and happy holidays from RS to you! There are pics up from past REAL Worlds on flicker http://www.flickr.com/photos/tags/realsoftware/