Mithat Konar (the wiki)

User Tools

Site Tools

You are here: Mithat Konar (the wiki) » Hybrid Apps » An Alternative Architecture for Hybrid Applications
hybrid_apps:alternative_architecture_for_hybrid_applications

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
hybrid_apps:alternative_architecture_for_hybrid_applications [2016/07/22 21:45] – mithathybrid_apps:alternative_architecture_for_hybrid_applications [2022/06/16 19:57] (current) – [The conventional hybrid architecture] mithat
Line 4: Line 4:
  
 ===== The conventional hybrid architecture ===== ===== The conventional hybrid architecture =====
 +
 +In the conventional hybrid architecture used by [[http://electron.atom.io/|Electron]], [[http://nwjs.io/|NW.js]] and others, the user interface is rendered as HTML using whatever HTML, CSS, and front-end JS frameworks you desire. The primary aim of this architecture is to facilitate the use Web technologies for the UI.
  
 {{:misc:conventional-hybrid.png|}} {{:misc:conventional-hybrid.png|}}
  
-In this model, which to the best of my knowledge is used by [[http://electron.atom.io/|Electron]], [[http://nwjs.io/|NW.js]], and others, the user interface is rendered as HTML using whatever HTML, CSS, and front-end JS frameworks you desire. The use of Web technologies for the UI is an explicit goal of this architecture.+Here, the UI is tightly bound in a one-to-one relationship with the app engine.((I'm using "app engine" generically here, not as a reference to Google's AppEngine.)) The app engine is implemented with Web back-end technology, typically Node.js. The app engine makes system calls through the engine's baked-in features or through generic ''child_process.exec()''-like calls. This means custom and platform-specific behaviors that the app may require will need to be implemented as external ''child_process.exec()'' callable units.
  
-The UI is tightly bound in a one-to-one relationship with the app engine.((I'm using "app engine" generically here, not as a reference to Google's AppEngine.)) The app engine is implemented with a Web back-end technology, typically Node.js. The app engine makes system calls through the engine's baked-in features or through generic ''child_process.exec()''-like calls. This means custom and platform-specific behaviors that the app may require will need to be implemented as external ''child_process.exec()'' callable units. +This architecture does a good job of leveraging Web technologies to create secure, conventional desktop apps. In addition, frameworks like Electron have matured to the point that developing hybrid apps that use many desktop app conventions is relatively easy.
- +
-This architecture does a good job of leveraging Web technologies to create secure conventional desktop apps. In addition, frameworks like Electron and NW.js have matured to the point that developing hybrid apps that use many desktop app conventions is relatively easy.+
  
 ===== A REST-based hybrid architecture ===== ===== A REST-based hybrid architecture =====
Line 19: Line 19:
 {{:misc:alternative-hybrid.png|}} {{: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 two changes outlined above are decoupled---meaning that either can be adopted in the absence of the other. +
- +
-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. +
- +
---------------------------------------------------- +
- +
-===== Server ===== +
-  * Create test case(s) using PHP and/or Node.js to get an idea of app responsiveness and interaction issues. +
-  * Attach WebSockets, Server-sent events, long polling, or similar to determine client scalability. +
- +
-==== Notes/questions/issues ==== +
-  * Persistence: config file or sqlite w/nice wrapper +
-  * Security model alternatives: +
-    * Accept connections only from localhost? CORS? +
-    * Password (in request) or API key (basic auth) property in app? +
-    * Notify and accept (cookie/session)? +
-    * Firewall +
-  * Embedded (i.e., one-and-only-app) vs. desktop app +
- +
-==== PHP ==== +
-  * Attractive because it facilitates a lot of web developers get into embedded development (i.e., lots of devs know PHP very well). +
-  * What server? +
-    * Is the built-in server good enough for a limited number of connections? +
-    * Is there a native PHP server that is good enough? +
-    * [[https://nginx.org/|nginx]] +
-    * [[https://www.lighttpd.net/|lighttpd]] +
-    * Bitnami? +
-  * What PHP? +
-    * Can "standalone" PHP be installed easily? Or is it best to use the global PHP? (Easy for Linux, dunno about Windows & MacOS.) +
- +
-The above are not issues for embedded application as the machine's global Apache (or whatever) server and PHP can be used. +
-  * Frameworks +
-    * Silex +
-      * Good community support. +
-      * Good Composer and module support. +
-      * Documentation is a bit obtuse. +
-      * Out of the box twig support. Redbean support is available. +
-      * Has a good ReST code structure but you wouldn't know it from the docs. +
-    * Slim +
-      * Slim 3 has removed some functionality that might be good to have. +
-    * Fat Free Framework +
-      * Compact, more than what's needed. +
-      * Excellent ReST code structure. +
-      * Twig and Redbean support are available. +
-      * Not sure Composer is well supported. +
-    * Check cookies/session (secure) support. +
-  * Persistence +
-    * Redbean  +
-    * ini and other format file (search Packagist for [[https://packagist.org/search/?q=ini%20|ini]] and [[https://packagist.org/search/?q=config%20|config]]). +
-      * [[https://packagist.org/packages/hassankhan/config|hassankhan/config]] looks good. +
-    * [[http://stackoverflow.com/questions/2015715/fastest-way-to-store-easily-editable-config-data-in-php|text file with native functions]] and [[http://psoug.org/snippet/How_to_write_a_config_file_234.htm|this]]. +
- +
-==== Node.js ==== +
-  * Doesn't have the "which server?" issue as the script is the server. +
-  * There is also a "persistence" advantage in that app vars can be used to deliver same data to many clients. +
-  * Frameworks +
-    * I don't see much reason not to use Express.js. +
-    * Persistence +
-      * My [[http://nodejs-configfile.saved.io/|config file bookmarks]] +
-      * My [[http://nodejs-sqlite.saved.io/|sqlite bookmarks]]+
  
-==== Python ==== +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.
-  * Python is attractive because RPi developers will know it. +
-  * Flask and Flask-RESTful are a good combination. +
-  * Has a development server that might be good enough for a limited number of clients. +
-  * Has the "persistence" advantage of Node.js (if run on development server?) +
-  * Config files and sqlite are TODO.+
  
-===== Client ===== +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.
-  * To be served or simply loaded from file? +
-    * I suspect the former is better because of security/CORS/whatever.  +
-    * If served, by a separate server or by the same server that's handling the API?+
  
 -------------------------------------------------- --------------------------------------------------
hybrid_apps/alternative_architecture_for_hybrid_applications.1469223902.txt.gz · Last modified: 2016/07/22 21:45 by mithat
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki