Differences

This shows you the differences between two versions of the page.

--- hybrid_apps:alternative_architecture_for_hybrid_applications [2017/11/06 16:32] – [The conventional hybrid architecture] mithat
+++ hybrid_apps:alternative_architecture_for_hybrid_applications [2017/11/06 16:54] – [A REST-based hybrid architecture] mithat
@@ Line 19: / Line 19: @@
 {{:misc:alternative-hybrid.png|}}
-In this model, the tightly bound user<->app engine connection is replaced by a REST API. Thus the app engine becomes a REST server, possibly embellished with whatever superpowers are needed for accessing host resources. When the app interface is API driven, //any// REST client technology can be used for the interface, including HTML/CSS/JS clients, native mobile clients, terminal clients, etc. In addition, the client need not be local, making remote-controlled apps almost trivial to implement. Adequate measures must be taken to assure secure and authorized communication with the REST server.
+In this model, the tightly bound user<->app engine connection is replaced by a REST API. The app engine becomes a REST server, possibly embellished with whatever superpowers are needed for accessing host resources, and the UI is supported through a client. Because the app interface is API driven, any REST client technology can be used for the interface, including HTML/CSS/JS clients, native mobile clients, terminal clients, etc. In addition, the client need not be local, which makes remote-controlled apps almost trivial to implement. As with any network-based communication, adequate measures must be taken to assure secure communication with the REST server.
-The other change in the above model is that the REST server is implemented in any high-level language on which a REST server can be built. The ideal server language will be one that also supports the necessary system manipulations the application requires (file access, etc.)
+The REST server can be implemented in any language on which a REST server can be built. Thus the "app" language can be one that also supports the necessary system manipulations the application requires (file access, etc.) or is otherwise best-suited to the app's requirements.
-The two changes outlined above are decoupled---meaning that either can be adopted in the absence of the other.
+One obvious requirement is that the language chosen for the REST server language must be able to run on the target host platform. This isn't a significant issue for desktop deploymen. However, it does currently present a problem for mobile deployment as few mobile platforms provide native support for more than one blessed development language.
-One obvious requirement is that the chosen language must be able to run on the target host platform. This isn't a significant issue with desktop deployment: typically, at most reconfiguring and/or rebuilding the REST server for each target platform is all that will be required. But it does currently present a problem for mobile deployment as few mobile platforms provide native support for more than one blessed development language.
 --------------------------------------------------