Ayagikei / LifeUp-SDK

Provide LifeUp SDK, and expose LifeUp APIs as HTTP services!
22 stars 4 forks source link

Run LifeUp Cloud from Server not phone #8

Open douglasg14b opened 3 months ago

douglasg14b commented 3 months ago

For various reasons I do not wish to run an HTTP server from my phone. However, running this from a server, or a docker container, would be valuable.

This would also allow for more integrated "cloud like" functionality if the app can point to a hosted cloud instance that can push tasks, task completion, updates, config...etc This could also enable DIY handling of "join task lists" for partners or families.

This can also enable usage of a DB like CouchDb which is well suited for direct client websockets as well as handling document diffs and conflicts for applications like multi-device sync or a family of LifeUp apps.

Essentially, inverting the client-server relationship to follow a more typical pattern so the mobile device is a client which may receive update from the server. Instead of the mobile device being the server, and custom servers/code being the "client".

Why:

  1. Battery life
  2. Reliability
  3. Easier to manage & govern
  4. Enables multiple devices to point to a single server
  5. Easier to distribute new server-side functionality and integrations. Like automations or IFTTT like behavior. Allowing the community to pick up some burdon on features they can write behavior for themselves.
  6. SECURITY
    • Security posture of API on phone is unknown
      • Is data protected during transit?
      • Is the API auth protected? Is that auth vulnerable?
      • Is the HTTP server used out of date and has known vulnerabilities? How is the HTTP server configured?
        • A self-hosted server can have these problems mitigated to some degree by sticking a bastion in front of and reverse proxying.
    • Risk associated with vulnerabilities goes up for a mobile device hosting an HTTP server (there's a lot of shared fate). As opposed to a server only running this app's SDK.
    • Generally, this is asking for someone, or bots, on the same network to fiddle with and try and break/attack/expose data from the API
    • Difficult to add monitoring or control layers in front of such an API.
Ayagikei commented 2 months ago

Hello, thanks for your thoughts and detailed suggestions!

It is indeed more reasonable for the server to manage and control data. However, because LifeUp did not have such a plan at the beginning, the current Android logic is difficult to change and abstract the data processing logic applicable to the server.

Nowadays, using Android apps as servers is a tricky way - Android apps rarely need to be modified, and existing API capabilities can be reused.

We will also consider whether we can make changes in this direction in the future, but for now, we can only say that the workload will be very huge and can only be regarded as a long-term goal.

We may also consider redesigning a new project based on the new architecture.

douglasg14b commented 2 months ago

Thanks for the reply, I really appreciate it. It'd good to hear that we're on the same page, but incredibly disappointing that it may not be possible for a long time 😢

There's a whole ecosystem that can integrate automation into task management. I hope someday we either have an app that has deep API integration, or LifeUp Pro gains API capabilities.

I intimately understand the difficulty in redesigning architecture or application design that was not built with such extensibility in mind. That can be a daunting task, and sometimes re-designs can be easier than remediation. I assume the android app is written in Java? I've done similar remediation's on other projects, and tend to go for a local client/server approach to ensure the UI is detached from the actual logic behind the app itself, easing in the transition or extension of an external API. This is a tedious process however, and probably 1/2 times ends up with the platform being rewritten.

Anyways, good luck!