Building a RESTful API for enabling use of image sequencer on a remote server

[tech4GT]

Some Image processing steps can be resource intensive and it might be difficult for users with low powered devices to run them locally one the device, for this purpose we can setup an Express server with an api that can take an image in request and return the step applied image in response.
For this purpose we can use https://www.npmjs.com/package/express for building the server and imgur for hosting the images. The image at all steps will be uploaded to imgur. https://imgur.com
We can start very basic with support for a single step and later add functionalities add multiple steps and replace steps
The demo will have a choice if user want to run on local machine or remote server for each step, we can also limit this in the basis of user's computer specification to prevent overloading the server

[jywarren]

GitMate.io thinks the contributors most likely able to help are @ccpandhare, and @jywarren.

Possibly related issues are #173 (Building out a contributor community for Image Sequencer), #23 (Planning Issue for the Image Sequencer GSoC Project), and #99 (Make the API Documentation using Swagger).

[tech4GT]

@jywarren please have a look, this is pretty much what i had in mind, for summer maybe we can just start with support for single step in the server, it would be relatively simpler project and would take 1-2 weeks to implement?

[ccpandhare]

@tech4GT a very good idea indeed! But we need to ensure that only those steps which will take more time are routed to the server. We don't want the user to be waiting! And how will we decide which is faster? Local or server (based on internet speed, user configuration, etc.?) I think this will take more than a week or two... Including testing, bugfixes and improvements. Usually this takes more time than the development itself but it is very important! Maybe you can come up with a timeline?

…

On Fri, Mar 9, 2018, 22:38 Varun Gupta ***@***.***> wrote: @jywarren <https://github.com/jywarren> please have a look, this is pretty much what i had in mind, for summer maybe we can just start with support for single step in the server, it would be relatively simpler project and would take 1-2 weeks to implement? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#198 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AT0xnPLA8ua2ryOtUvmq1Af89lPheeU8ks5tcrcBgaJpZM4SkkrG> .

[tech4GT]

@ccpandhare actually i was thinking we can have the user decide if he wants to use local device or server but i get it, this can take a little more time now working on the timeline, thanks👍

[tech4GT]

@jywarren @ccpandhare would this be a priority or #190 for summer coz @ccpandhare you are right i cannot do both in the given timeframe, maybe we can work on one after the summer, so should i keep this one on #190 in my proposal? thanks

[jywarren]

I think it'd be really useful for example to implement a completely separate service-based MapKnitter back-end, which could receive full-size images and distort them remotely for people. https://github.com/publiclab/mapknitter/

But I think #190 and anything that can help onboard new people to grow this team is a higher priority -- i've written a bit about my reasoning for this here -- hope that makes sense!

https://publiclab.org/notes/tech4gt/02-19-2018/gsoc-proposal-image-sequencer-v2-processing-on-steroids#c18878

[jywarren]

Getting back to this one, esp after all the great improvements this last summer.

This could involve setting up a new repository in which we have a containerized/dockerized node version of image-sequencer which can accept commands via REST API calls.

The string syntax makes this MUCH easier, by allowing us to pass an image or url plus an instruction set. An image would be output.

Another thing we could offer is a callback url maybe!

So if we imagined what a POST request payload would look like, it might include:

// Request:

{
  img_src: "...",
  callback: "https://...",
  commandString: "blur,brightness..."
}


// Response:

{
  progress_url: "https://...",
  status: "success"
}

[tech4GT]

@jywarren This looks great! I didn't quite get the purpose for callback though. Also I was thinking of starting this one in my winter break.

[jywarren]

The callback is not necessary for most cases. But it could function like a push request back to an originating server which could replace polling for progress. Just thinking ahead to useful architecture.

…

On Thu, Oct 18, 2018, 9:52 AM Varun Gupta ***@***.***> wrote: @jywarren <https://github.com/jywarren> This looks great! I didn't quite get the purpose for callback though. Also I was thinking of starting this one in my winter break. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#198 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ2suLEVzmV_R3CJUII7sNyib3Q7fks5ul96ngaJpZM4SkkrG> .

[tech4GT]

Hmm, I am thinking rather than doing it this way maybe we can use web sockets for this kind of functionality, what do you think?

[jywarren]

I think websockets could be cool, but a basic API may be easier to implement and integrate -- the client may not be submitting from javascript in any case. So perhaps we could work on a RESTful approach first, but then consider if a websockets interface is a good follow-up! What do you think?

…

On Wed, Oct 17, 2018 at 9:58 PM Varun Gupta ***@***.***> wrote: Hmm, I am thinking rather than doing it this way maybe we can use web sockets for this kind of functionality, what do you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#198 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ6HneE8klxkyHB9mnC6E5zVCMTiLks5ul-APgaJpZM4SkkrG> .