search

chaiNNer-org / chaiNNer

A node-based image processing GUI aimed at making chaining image processing tasks easy and customizable. Born as an AI upscaling application, chaiNNer has grown into an extremely flexible and powerful programmatic image processing application.
https://chaiNNer.app
GNU General Public License v3.0
4.58k stars 283 forks source link

Support remote backends #1875

Open RunDevelopment opened 1 year ago

RunDevelopment commented 1 year ago

Motivation We have been getting a lot of requests to run chainner on a server, so this issue to intended to track progress towards that.

The main goal of this is to support offloading the heavy computational cost of some operations (e.g. upscaling) to cloud servers such that low-end and mid-range devices can use the full range of chainner's features. Users would be able to use the frontend to connect to some remote backend and use chainner as normal while the remote server does the computations.

Description Remote backends should support the following:

  1. Running the backend without the GUI.
  2. Supporting Docker.
  3. Supporting Google Colab.
  4. Allowing the backend to connect to remote servers that host a backend.

As I see it, the main technical challenges will be the following:

  1. File paths. Right now, the backend and frontend assume that they have access to the same file system. This obviously isn't the case with remote backends, so we have to send over files to share them between the backend and frontend. \ This mainly affects the Load Image, Load Model, Save Image, Save Model, and View Image (External) nodes.
  2. Authentication. With chainner being a visual programming language, we are essentially running untrusted code on those remote backends (not even accounting for third-party plugins). We need to be able to authenticate users such that only allowed users can connect to a backend.
  3. Multiple tenants. There might be multiple users connected to a single backend at once. This is currently not supported at all. \ It should be noted that this problem is equivalent to supporting multiple chains (#607).

Note: We may be able to get away with not supporting multiple tenants at first.

Splendide-Imaginarius commented 1 year ago

It seems like one stepping stone on the way to this goal would be to change how the --no-backend flag works. Currently, it takes no arguments (it's just a boolean flag), and if specified, it assumes the backend is at http://localhost:8000/. It might be helpful to allow specifying the backend address as an argument, e.g. chainner --remote-backend http://localhost:8000/ would be the equivalent of the current behavior of chainner --no-backend. (This would also be independently helpful for use cases where the user wants to run the backend on a different port or different loopback address, e.g. if the current default port is already in use.)

Would such a change be welcome?

joeyballentine commented 1 year ago

Yes that would be a welcome addition for sure