Using MVC on both Client and Server - how would you approach this

[grokmvc]

Hello all,

Im new here, but been fairly interested in this framework.  

Heres my question:  Using MVC on both Client and Server - how would you approach this?  

Background - I've been increasingly frustrated with designers who think they can program and vice versa.  Seems the natural answer is utilizing frameworks and begin delegating out the responsibilites both from a programming descipline and application structure.

Heres my Goal - similar to this:  http://www.javacodegeeks.com/2013/12/project-avatar-the-next-java-ee-feature.html?ModPagespeed=noscript

Client
has an PUREMVC JS based port on web server (maybe apache reverse proxy)
-- hosts the Client Side delivering only the static images and static HTML
-- (DIVS for content layout and empty HTML5 TEMPLATE for content)
-- reverse proxy passes client commands back to application server VIA AJAX formatted as JSON

Server
has an PUREMVC JAVA based port hosted on J2EE App server (maybe Glassfish)
-- hosts the Server application
-- No JSP's or content handlers to output html
-- App Server only accepts data requests from client via AJAX and returns formatted JSON

Trying to avoid
URL Params
REST as it's to tightly coupled to HTTP
WEB Services (wsdl or soap) as its XML is  too verbose

Trying to use
JSON natively to avoid decoding and encoding issues
HTML 5 without excessive libraries
WEBSocket as server endpoint

Got the Idea when I was looking through the TODOS when comparing JS application frameworks... and began wondering how a server side app would run in parallel.  Ideally adopting a framework which supports multiple platforms will eventually lead to an agnostic approach on technology.

Anybody willing to share ideas of how both the server side and client side MVC's could work together?
PROS and CONS?
Anyone willing to look at the TODOmvc JS and create a server side Java port for it using those goals above?

Thanks!

[puremvc]

Running the same framework on client and server can definitely be a good if developers are called upon to work both sides of the fence. And for the system architect to design.

With a long-running server process (not a CGI request where the program gets run each time a request is made):
* Model classes (Proxies) communicate with databases, other processes, remote servers, etc.
* View classes (Mediators) maintain individual client sessions
* Control classes (Commands) perform logic such as transforming an HTML template with data, or format a JSON or XML response
* Facade handles startup of the server app, as well as creating Mediators for new client sessions. In some languages this interprocess communication would be handled with forking and pipes, in Java it would be via threads and synchronized objects.

Client
has an PUREMVC JS based port on web server (maybe apache reverse proxy)
-- hosts the Client Side delivering only the static images and static HTML
-- (DIVS for content layout and empty HTML5 TEMPLATE for content)
-- reverse proxy passes client commands back to application server VIA AJAX formatted as JSON

Server
has an PUREMVC JAVA based port hosted on J2EE App server (maybe Glassfish)
-- hosts the Server application
-- No JSP's or content handlers to output html
-- App Server only accepts data requests from client via AJAX and returns formatted JSON

Sounds like a reasonable setup (although I believe AJAX that returns JSON is now commonly referred to as AJAJ).

Trying to avoid
URL Params

So, your request parameters would go as HTTP headers? If you're not passing the request info via URL params or the path, then headers is all that's left.
 

REST as it's to tightly coupled to HTTP

This seems directly at odds with your spec above. AJAX/AJAJ implementations typically build upon XMLHTTPRequest, which is intimately coupled to HTTP. REST is just a way of letting you think about your request space in a tree form. It's a simple way to pass information to your service about what you want. As are URL params. Again, you have to pass that info some way, and the only way you've left is HTTP headers, which is as tightly coupled to HTTP as you can get.

WEB Services (wsdl or soap) as its XML is  too verbose[/quote]
I agree, although most browsers and servers are capable of gzipping requests and responses now, so it's less of an issue than it once was.

I look forward to hearing about your progress.
-=Cliff>

[grokmvc]

Thanks for reply - to a few of the posed questions:

Trying to avoid
URL Params

So, your request parameters would go as HTTP headers? If you're not passing the request info via URL params or the path, then headers is all that's left.
 

most practically in the optional request body using XHR2 post or put., though Headers is an option as well

REST as it's to tightly coupled to HTTP

This seems directly at odds with your spec above. AJAX/AJAJ implementations typically build upon XMLHTTPRequest, which is intimately coupled to HTTP. REST is just a way of letting you think about your request space in a tree form. It's a simple way to pass information to your service about what you want. As are URL params. Again, you have to pass that info some way, and the only way you've left is HTTP headers, which is as tightly coupled to HTTP as you can get.

Valid point - maybe a further explanation would help.  It seems as if I would be forced into numerous REST endpoints as REST at any given endpoint will wind up processing only one method for each get/post/put... etc.   In addition, I can do away with the endpoints all together by controlling the path with the reverse proxy..  I was more referring to how each REST endpoint relied on the HTTP request method itself more than the overall usage of HTTP overall.  And avoiding browser variations - a request body or header would be processed consistently (unlike form-data etc...) and avoid the built in encoding.
 
And to the observation of gzipping - Its a bit odd for me to use an XML based XHR2 request and to put down how verbose XML is at the same time. 

Did the NON GWT JAVA port get posted - looks like the standard has missing references (perhaps with map and java util) and the multi core still relies on the GWT kits?


Any thoughts?

[grokmvc]

So I have a working version of this, which is (very) rough around the edges - but it accomplished my goals for now.  I have to say this was my first attempt at making

Heres what I have:

Simple Login Application

Client:  
Framework: PureMVC JS version
FrontEnd: HTML5 with Jquery-LoadTemplate Plugin
Communication:  JSON via Websocket

Server:
Framework:  PureMVC Java version
Backend:  Java Application Server (Glassfish4  running Tyrus)
Communication:  JSON via Websocket

Framework Implementation:
Client:  View and Controller
Server:  Controller and Model

Basically - I have been able to accomplish:
Clear separation of the Client (VIEW) from the Server (MODEL) processing
Utilization of Common Framework with differing languages

What I need for many smarter than me....

Before I post anywhere - I want some feedback regarding how I've set it up and whether there are better ways of handling this.

I ran into a few issues:
0.  Seeing what was really happening (I added a bunch of logging on both client and server to what the framework and socket server in action)
1.  Java Websocket relies of session to be able to send back to the client (I created an REMOTEENDPOINT.ASYNC proxy on each incoming message)
2.  JSON notifications - It was possible to create a notification in which BODY was JSONOBJECT instead of POJO (in reality there is very little difference in how they are processed)
3.  Creating Java objects which are JSON rather than worrying about converting to Java primitives.


Would anyone be willing to provide feedback and possibly some help with the challenges above by taking a look at the code?

I've attached just the index gif so you can see what I mean about the template concept as well as a gif of the application structure.