How to develop 100% server-side applications?

1.5k Views Asked by At

TL;DR

What framework can I use to keep 100% application logic on the server while providing the interactivity of RIA?

Explanation

Back in the 90's, one could build 100% server-side application with ordinary PHP. But then demands for in-page interactivity increased and more and more application logic was moved into client-side javascript. Today, with websocket and fully dynamic DOM, it is once again possible to build server-side applications while satisfying all in-page interactivity requirements. All that's needed on the client is a generic javascript library that syncs DOM with the server over websocket.

While I believe this approach to web development has its merits, I don't want to discuss pros and cons of this technique here.

My question is about state of the art frameworks available by the end of 2014 that support this style of development. Experimental frameworks are also okay as far as their architecture is sufficiently clear. I don't need a laundry list of existing frameworks. I would like to see some framework that implements this kind of software architecture or, should there be no such framework, I would like to learn about those that get closest to the ideal.

My own research so far shows that Meteor is going the right way, but it still encourages too much app-specific javascript on the client and it ties server-side platform to client-side platform (i.e. javascript). I've read about Trello architecture, which largely reduces the client to a template processor, but templates and associated template/binding libraries are among the things I would like to move back to server side. Amazon AppStream will keep all the UI logic on the server, but it's prohibitively expensive for web development, especially when users leave apps sitting idly in the background.

Update: All the answers so far focus on Meteor. I have removed Meteor tag, because it might be misleading. I've mentioned Meteor, because the Meteor presentation made it look like I have a choice as to whether I want to run code server-side or client-side. It's now clear that Meteor won't transmit any UI over the wire, just data. It thus needs half the application on the client, at least in the form of templates.

Update 2: I've found Remote Events for XML (REX), a protocol that could be used to manipulate client-side DOM remotely from server-side app. There's no clear way to send user actions (clicks, edits) back to the server, but perhaps these could be defined as extension events in REX, which is permitted by the spec. It's still just a protocol though. No real software I could use.

Update 3: I have to clarify one thing. Simply taking server-side templates and translating them to client-side templates, which are then subsequently executed on the client, doesn't count as 100% server-side app logic. While such frameworks allow me to use server-side API, they will inevitably burden the client and expose large part of application code. I am looking for something that only sends rendered content (and generic event hooks) down to the client.

Also, regarding widgets/controls, the framework can allow client-side code to handle fringe cases (new low-level widgets), but it must not require client-side implementation for typical application logic (templates and high-level widgets).

8

There are 8 best solutions below

1
On BEST ANSWER

Vaadin seems to come pretty close to what you want. I have no experience with it myself, but from what I've read, it should allow you to write your entire application (including the UI logic) in server-side code (Java). The framework takes care of the inevitable client-side stuff (Ajax).

References

3
On

Meteor is very modular so you can use it, but its in a very unconventional sense.

You would have to remove the client side/web based stuff in it. This is included in the meteor-platform package.

It may be better to have a "barebones" app

meteor create myapp
meteor remove meteor-platform

Now you can add back a selection of packages that make development helpful (you can remove any one of these):

meteor add logging ddp mongo check underscore random ejson

Now you have a 100% server application.

This app is slightly different from the typical Meteor application in that it has no 'web server' serving any client side code, its nearly a pure server app.

To begin you have to remove any boilerplate code (myapp.html, myapp.css, myapp.js) and have a file with the method main = function() { ... } that contains your application. Keep in mind you need something in this method that keeps your app up such as a socket listener (maybe express js?), once it runs the application will stop

Again I'm not sure what exactly you want with a 100% server side app, if you intend to use Meteor over Node, which has a benefit of allowing you to have synchronous code, mongo built in and DDP, this may be the way to go. If you don't want the client side stuff, or anything else you don't want, you can remove it using the method above.

0
On

You may want to consider using a combination of tools to accomplish this goal. Meteor is not the best approach for you since is relys on client side JavaScript and only passes data on the wire.

I suggest using Node.js as the server since it is the underlying server of Meteor. You can then use a server side templating engine like jade or similar to render the html. This will make your app dynamic, but less reliant on the client. You lose all of the reactivity, but that is the trade off of rendering on the server.

0
On

Bluntly, Meteor is not what you're looking for. The main advantages Meteor framework has to offer aren't the parts you're looking to use.

I'm honestly not sure what the right application is for you. But it sure ain't Meteor.

1
On

That's quite an interesting question given that a lot of people are trying hard to build apps on the client side and using BeASS (Backend As a Service). Off the top of my head the following two come to mind:

Since I;m most experienced with The Dojo Tookit, you can do the following:

1. Zend and Dojo Integration

Zend (One of the top contributors to PHP and the Apache Server) have integrated their framework with Dojo. As can be seen here http://framework.zend.com/manual/1.12/en/zend.dojo.view.html purely by using PHP code they have a way where they are able to render Dojo widgets on the client side.

2. Dojo and Node.JS integration

Simple intgreation is eady with Dojo and Node.js by doing this. http://dojotoolkit.org/documentation/tutorials/1.8/node/

But, Dojo widgets (completely interactive, RIA et al. as can be seen here http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html) can be rendered with Server side code and sent to the client. See this http://dojotoolkit.org/reference-guide/1.9/dijit/_AttachMixin.html and this http://jamesthom.as/blog/2013/01/15/server-side-dijit/

3. Templating frameworks

Like Point 2, there are many templating frameworks that exist for JavaScript. There may be many frameworks in the wild which may be populating these templates on the server side and just sending the View code to the client.

A word of caution on the above links though. Dojo itself is pretty hard to learn in the beginning (later on its power just amazes you!) but the above links are pretty powerful stuff, quite hard to learn.

Personally I think we have moved to an era where the browser can do alomst anything and the server just sits there for persistent data / facilitating multiple users and authentication.

I will post more links as and when I come across more such frameworks including examples of Pt. 3

EDIT: Here is something happening in PHP that effectively reduces JavaScript User events to nothing but network calls to the server. http://www.xisc.com/

0
On

I suggest using Oracle ADF.
It has reach set of UI components, and it has a built in ABC (ADF Business Componenet) which makes a good abstraction on data layer so you can fetch data from database or web service or file or ....

also you can use JHeadStart which is kind of code generator, it builds web pages and modules for you and you can build your web application very fast.

9
On

Use something with a server-side event model, such as:

Much of Blueprint's philosophy and syntax comes from XForms. We opted for a full declarative language because it was the only way we could effectively run on the wide range of devices out there, some of which have no scripting at all. By using declarative syntax, we can encapsulate and hide the scripting specifics. In some cases, the code could run on the phone, in other case, such as XHTML, we can put the logic on our servers. It's the perfect way to deal with the various environments and their capabilities.

And Orbeon forms has a command line interface using a pipe and filter implementation called XPL:

You can use Orbeon Forms to build standalone command-line applications running pipelines. Use cases include: creating a hardcopy of a web site, importing or exporting XML data to and from a relational database, testing pipelines, automating repetitive operations on XML files (selection, transformation, aggregation, etc.). Orbeon Forms becomes your "XML toolbox".

Orbeon Forms ships with a command line interface (CLI). The easiest way to run it is to use the executable orbeon-cli.jar file and pass it a pipeline file:

java -jar orbeon-cli.jar pipeline.xpl

In this case, a pipeline can use relative URLs, or, if using absolute URLs, can use either the file: protocol to access files or, equivalently, the oxf: protocol.

Sometimes, it is better to group files under a resources sandbox addressed by the oxf: protocol. This is the standard way of accessing resources (files) within web applications, but it is also useful with command-line applications. In such cases, specify a resource manager root directory with the -r option, for example:

java -jar orbeon-cli.jar -r . oxf:/pipeline.xpl

or:

java -jar orbeon-cli.jar -r C:/my-example oxf:/pipeline.xpl

References

0
On

i have built apps in this spirit mainly because i needed to support old versions of IE which did not handle heavy client side work. The basic approach is to you use server side partials and load them via ajax. Gives you RIA while keeps the logic on the server.

I have done this in asp.net webforms, asp.net mvc, rails and node/express.

An example would be a form that edits a record. Using knockout, angular, jquery, etc... your form would be part of the DOM and you would load the data via ajax and then perform binding if you are using something like jquery or let the framework do a two way binding in angular, knockout, ...

In this approach instead you would load a partial from the server, the DOM and the bindings will be done on the server and you would replace the div's content fully with the response.

The specifics depend on the language you are using but I have a commercial app in production written using asp.net mvc that does exactly that and an internal tool that we use in our company written in node/express/jade that does that as well. It is a lot easier to follow the code, and you get a lot more browser compatibility. None the less, that's not where the industry is heading. For newer code we are using knockout and angular.