hybrid_apps:alternative_architecture_for_hybrid_applications
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
hybrid_apps:alternative_architecture_for_hybrid_applications [2016/07/22 21:45] – mithat | hybrid_apps:alternative_architecture_for_hybrid_applications [2017/11/06 16:54] – [A REST-based hybrid architecture] mithat | ||
---|---|---|---|
Line 7: | Line 7: | ||
{{: | {{: | ||
- | In this model, which to the best of my knowledge is used by [[http:// | + | In this model, which to the best of my knowledge is used by [[http:// |
- | The UI is tightly bound in a one-to-one relationship with the app engine.((I' | + | The UI is tightly bound in a one-to-one relationship with the app engine.((I' |
- | This architecture does a good job of leveraging Web technologies to create secure conventional desktop apps. In addition, frameworks like Electron | + | 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. |
===== A REST-based hybrid architecture ===== | ===== A REST-based hybrid architecture ===== | ||
Line 19: | Line 19: | ||
{{: | {{: | ||
- | In this model, the tightly bound user< | + | In this model, the tightly bound user< |
- | The other change in the above model is that the REST server | + | The REST server |
- | 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 |
- | + | ||
- | 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 | + | |
- | + | ||
- | --------------------------------------------------- | + | |
- | + | ||
- | ===== 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/ | + | |
- | * Persistence: | + | |
- | * Security model alternatives: | + | |
- | * Accept connections only from localhost? CORS? | + | |
- | * Password (in request) or API key (basic auth) property in app? | + | |
- | * Notify and accept (cookie/ | + | |
- | * 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:// | + | |
- | * [[https:// | + | |
- | * Bitnami? | + | |
- | * What PHP? | + | |
- | * Can " | + | |
- | + | ||
- | The above are not issues for embedded application as the machine' | + | |
- | * 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' | + | |
- | * 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/ | + | |
- | * Persistence | + | |
- | * Redbean | + | |
- | * ini and other format file (search Packagist for [[https:// | + | |
- | * [[https:// | + | |
- | * [[http:// | + | |
- | + | ||
- | ==== Node.js ==== | + | |
- | * Doesn' | + | |
- | * There is also a " | + | |
- | * Frameworks | + | |
- | * I don't see much reason not to use Express.js. | + | |
- | * Persistence | + | |
- | * My [[http:// | + | |
- | * My [[http:// | + | |
- | + | ||
- | ==== Python ==== | + | |
- | * 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 " | + | |
- | * Config files and sqlite are TODO. | + | |
- | + | ||
- | ===== Client ===== | + | |
- | * To be served or simply loaded from file? | + | |
- | * I suspect the former is better because of security/ | + | |
- | * If served, by a separate server or by the same server that's handling the API? | + | |
-------------------------------------------------- | -------------------------------------------------- |
hybrid_apps/alternative_architecture_for_hybrid_applications.txt · Last modified: 2022/06/16 19:57 by mithat