Differences

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

--- misc:alternative_architecture_for_hybrid_applications [2016/07/06 13:11] – [REST-based hybrid architectures] mithat
+++ misc:alternative_architecture_for_hybrid_applications [2016/07/17 03:34] – [Notes/questions/issues] mithat
@@ Line 13: / Line 13: @@
 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.
-===== REST-based hybrid architectures =====
+===== A REST-based hybrid architecture =====
 One alternative to the conventional hybrid approach is a REST-based architecture. A REST-based approach requires more carefully considered design but offers the potential for greater flexibility.
@@ Line 27: / Line 27: @@
 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.
-===== Future work =====
+---------------------------------------------------
-==== Server ====
+===== 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/question ===
+==== Notes/questions/issues ====
   * Persistence: config file or sqlite w/nice wrapper
-  * Security model:
+  * Security model alternatives:
     * Accept connections only from localhost? CORS?
     * Password (in request) or API key (basic auth) property in app?
@@ Line 41: / Line 42: @@
   * Embedded (i.e., one-and-only-app) vs. desktop app
-=== PHP ===
+==== 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?
+    * 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]].
-The above are not issues for embedded application as the machine's global Apache or whatever server and PHP can be used.
+==== 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]]
-==== Client ====
+==== Python ====
-  - To be served or simply loaded from file?
+  * Python is attractive because RPi developers will know it.
-    - I suspect the former is better because of security/CORS/whatever.
+  * Flask and Flask-RESTful are a good combination.
-    - If served, by a separate server or by the same server that's handling the API?
+  * 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 =====
+  * 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?