misc:alternative_architecture_for_hybrid_applications
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
misc:alternative_architecture_for_hybrid_applications [2016/04/27 20:15] – [The conventional hybrid architecture] mithat | misc:alternative_architecture_for_hybrid_applications [2016/07/06 13:44] – mithat | ||
---|---|---|---|
Line 7: | Line 7: | ||
{{: | {{: | ||
- | In this model, which as far as I understand | + | In this model, which to the best of my knowledge |
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' | ||
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. | 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. | ||
- | ===== An alternative | + | ===== A REST-based |
- | In what follows, I present what I believe | + | One alternative to the conventional hybrid approach |
{{: | {{: | ||
- | 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 is implemented in C++. When this is the case, interacting with the host system | + | The other change in the above model is that the REST server is implemented in any high-level language on which a REST server |
The two changes outlined above are decoupled---meaning that either can be adopted in the absence of the other. | The two changes outlined above are decoupled---meaning that either can be adopted in the absence of the other. | ||
- | One downside to using C++ (or Java, or Python...) for the server part of this approach | + | One obvious requirement |
+ | |||
+ | --------------------------------------------------- | ||
+ | |||
+ | ===== 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: | ||
+ | * 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 ==== | ||
+ | * What server? | ||
+ | * Is there a native PHP server | ||
+ | * [[https:// | ||
+ | * [[https:// | ||
+ | * Bitnami? | ||
+ | * What PHP? | ||
+ | * Can " | ||
+ | |||
+ | The above are not issues for embedded application as the machine' | ||
+ | * Frameworks | ||
+ | * Silex | ||
+ | * Slim | ||
+ | * Fat Free Framework | ||
+ | * 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:// | ||
+ | |||
+ | ===== 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? | ||
misc/alternative_architecture_for_hybrid_applications.txt · Last modified: 2016/07/22 21:42 by mithat