Client-side API #353

surma · 2018-11-29T10:04:16Z

Here’s the current, rather hacky implementation of the client-side API so we can start discussing the implementation approach.

The basic approach is to define an API and expose it to window.parent via Comlink, this way squoosh can be embedded using <iframe> and the API methods can just be invoked.

Here’s the code for an example batch processing app.

src/components/App/index.tsx

src/components/compress/index.tsx

jakearchibald · 2018-11-30T12:43:00Z

This is a 12% increase to our first-interaction bundle. Is there anything that can be done to avoid this?

What does usage look like? How does the user know when they can make calls to the API?

surma · 2018-12-03T15:17:07Z

@jakearchibald PTAL! Lazy-loading the API now :)

I also updated the example batch app, which actually looks really nice in terms of code now. I’d love to bundle squoosh.api.js with our project and serve it as its own bundle from squoosh.app, but I couldn’t get webpack to do that lol.

jakearchibald

Coming along nicely. I agree that we should use this for the share target stuff.

src/components/App/index.tsx

src/components/App/client-api.ts

src/components/compress/index.tsx

jakearchibald · 2018-12-07T10:16:14Z

We need to decide if the API is solely for computation, or if it's a UI driver. From this PR it seems like the latter, and I think that's the right direction. That works for things like a share target API, it works for creating a glitch that opens a particular image with particular settings (once we expand the API to include settings). But that means the API needs to cope with user interactions that might happen during its driving, so calls should AbortError if the user interrupts.

I don't have a strong opinion if this is done with events, or promises stored on the instance.

Some things to think about:

If the user changes some compression settings on the left, then the API changes settings on the right, should the API returned promise wait on both sides to finish compressing, or just the right?

If this is a UI driver, should we separate the setting of things from the completion of things? Eg, if I setFile, should that resolve once the image has been set from the UI point of view, as in before it's decoded? We could have other methods for observing things like decoded, and compression complete.

What's our backwards compatibility story here? Should the API involve some sort of version check? We could change our major version when the API breaks compatibility.

surma · 2018-12-07T11:13:45Z

We need to decide if the API is solely for computation, or if it's a UI driver. From this PR it seems like the latter,

The more I think about it, the more I agree it’s what we should aim for.

But that means the API needs to cope with user interactions that might happen during its driving, so calls should AbortError if the user interrupts.

I’ll see if I can add a got way to add that.

If the user changes some compression settings on the left, then the API changes settings on the right, should the API returned promise wait on both sides to finish compressing, or just the right?

I don’t think it should. setFile() just waits for the state change to happen. getBlob(side) waits for the selected side to finish encoding. This is where I’d need to add error handling for when that job gets aborted. I think that model works.

If this is a UI driver, should we separate the setting of things from the completion of things? Eg, if I setFile, should that resolve once the image has been set from the UI point of view, as in before it's decoded? We could have other methods for observing things like decoded, and compression complete.

It’s mostly how it works right now, but I think you are right that more explicit events (?) for intermediate steps would be nice.

What's our backwards compatibility story here? Should the API involve some sort of version check? We could change our major version when the API breaks compatibility.

It’s probably a good call to add a the major version to the handshake and just abort on mismatch.

jakearchibald · 2018-12-07T11:29:01Z

but I think you are right that more explicit events (?) for intermediate steps would be nice.

I'm leaning towards promises being better, but I'm not awfully sure. After driving the UI, you could get a promise for "image decoded" (which is when you could get width/height & format if we offered it), and a promise for the complete encoding of a particular side.

Edit: When I say "get a promise", I mean it'd be an additional call to get that promise. The methods themselves would resolve once the state is set.

It’s probably a good call to add a the major version to the handshake and just abort on mismatch.

Error I think.

surma · 2018-12-17T16:46:46Z

@jakearchibald PTAL

src/components/App/client-api.ts

src/components/compress/index.tsx

surma · 2018-12-19T14:44:40Z

@jakearchibald PTAL

jakearchibald

Caught a few more things.

Also, there should be docs for this, which we can link to from the main README.

src/components/compress/index.tsx

src/components/App/client-api.ts

src/components/compress/index.tsx

surma · 2019-02-11T16:05:56Z

@jakearchibald PTAL

jakearchibald

Only nits.

Add some docs and a demo, and we're good to go I think.

src/components/App/client-api.ts

surma · 2019-02-25T12:53:32Z

This is ready for final review and hopefully a merge :D

I pushed the small batch processing demo to a glitch, using the real SDK file exposed from this PR endpoint.

@jakearchibald PTAL

developit · 2019-02-27T05:54:23Z

package.json

@@ -4,9 +4,10 @@
  "version": "1.3.3",
  "license": "apache-2.0",
  "scripts": {
+    "build:sdk": "microbundle --compress -f es -o build -i src/sdk.ts",


I think --compress is the default and -i is optional.

Suggested change

"build:sdk": "microbundle --compress -f es -o build -i src/sdk.ts",

"build:sdk": "microbundle -f es -o build src/sdk.ts",

This seems to be adding a load of definition files into the build.

True. Do you think that’s a problem? There’s technically no harm in emitting them and I have no easy way to teach microbundle to not do that.

surma · 2019-03-05T10:25:52Z

@jakearchibald ping :)

jakearchibald

Does this create a privacy problem?

Eg, evil.com contains a link "Check out squoosh.app!" which, when clicked, opens a new window. To the user it looks like a regular tab with "squoosh.app" in the address bar, but if they drop any private images onto the site, evil.com can read it.

It seems like we need to limit usage of this API to cases where the source of control is obvious, eg iframes, as the URL bar will display evil.com rather than squoosh.app.

jakearchibald · 2019-03-07T11:13:36Z

_headers.ejs

+# Module imports need CORS, so we enable it for the SDK file.
+/squoosh.mjs
+  Access-Control-Allow-Origin: *
+


Add the header to all responses. May as well.

This resource has a max-age of 31536000. Feels like it should be no-cache right?

In general, what's the benefit of self-hosting this rather than providing it as a separate package? I'm worried about making changes to this resource that breaks people's sites.

I thought that this way at least SDK and Squoosh stay in sync in terms of versioning. We can also not host it and publish it as a package, but not sure it’s that different in terms of breakage.

jakearchibald · 2019-03-07T11:24:33Z

package.json

@@ -4,9 +4,10 @@
  "version": "1.3.3",
  "license": "apache-2.0",
  "scripts": {
+    "build:sdk": "microbundle --compress -f es -o build -i src/sdk.ts",


This seems to be adding a load of definition files into the build.

jakearchibald · 2019-03-07T11:31:00Z

src/sdk.ts

+          }`,
+        );
+      }
+      ev.stopPropagation();


Maybe we already discussed this, but what's the benefit here? What other kind of listeners do we expect?

The idea was that there could be a scenario where an squoosh iframe is reused and the next user might send a new READY? message. It’s mostly me playing it safe.

src/components/compress/index.tsx

surma · 2019-03-20T17:54:40Z

Hopefully this limits it to iframes only.

mbrevda · 2019-06-18T20:22:40Z

Is this blocked on something?

vroussel35 · 2019-08-28T12:12:03Z

Hi guys,
Can you let us know when you plan to deliver this request?
(no pressure but having a little bit of visibility on this client-side API functionality would be great to plan on our side)
Looking forward to hear from you.
Thanks

usualoma · 2019-12-25T03:05:21Z

Great PR!
This PR only works on Google Chrome or Firefox, but it is still useful enough.

This is an example of integration with a CMS created based on this PR.
https://github.com/usualoma/mt-plugin-Squoosh/

I hope this PR will be merged into master.

mbrevda · 2020-06-15T17:36:43Z

Any context on why this was closed?

dgrammatiko · 2020-06-15T18:05:35Z

Any context on why this was closed?

Pretty sure this was due to moving the branch master to live and in order to remove the first one this was necessary. I've faced that on my own repos. I'll guess @surma will reopen it again at some point

mbrevda · 2020-06-15T18:12:24Z

Pretty sure you can just select a new branch for the PR without needing to close it

developit · 2020-06-15T21:02:54Z

Changing the master branch on GitHub auto-closes all PR's targeted at that branch.

surma · 2020-12-10T10:58:20Z

Closing this for now in favor of the CLI for batch processing (and also Share Target fulfills most of the purpose).

mbrevda · 2020-12-10T11:45:45Z

Can Share Target be used to programmatically compress images client side (without user interaction)?

surma added the DO NOT MERGE label Nov 29, 2018

surma requested review from jakearchibald and developit November 29, 2018 10:04

surma commented Nov 29, 2018

View reviewed changes

src/components/App/index.tsx Outdated Show resolved Hide resolved

surma commented Nov 29, 2018

View reviewed changes

src/components/compress/index.tsx Outdated Show resolved Hide resolved

surma force-pushed the api branch from ec55744 to a61b066 Compare December 3, 2018 15:14

jakearchibald requested changes Dec 6, 2018

View reviewed changes

jakearchibald requested changes Dec 18, 2018

View reviewed changes

jakearchibald requested changes Jan 9, 2019

View reviewed changes

surma mentioned this pull request Jan 17, 2019

mac/windows/chromeOs...etc app with extended features like optimize all pictures in folders #429

Closed

jakearchibald mentioned this pull request Jan 18, 2019

instruction on how to embed squoosh into H5 webpage #416

Open

surma force-pushed the api branch from 4065df6 to bb74773 Compare February 11, 2019 15:49

jakearchibald mentioned this pull request Feb 19, 2019

Add share target #469

Merged

jakearchibald reviewed Feb 19, 2019

View reviewed changes

src/components/App/client-api.ts Show resolved Hide resolved

src/components/App/client-api.ts Outdated Show resolved Hide resolved

surma force-pushed the api branch 2 times, most recently from 0c805c4 to 57eb2dc Compare February 25, 2019 12:51

surma removed the DO NOT MERGE label Feb 25, 2019

surma changed the title ~~WIP: Client-side API~~ Client-side API Feb 25, 2019

developit reviewed Feb 27, 2019

View reviewed changes

jakearchibald requested changes Mar 7, 2019

View reviewed changes

surma and others added 14 commits March 20, 2019 17:12

Create a SideEvent

0041d24

Another fix from rebasing

7998cf2

Use MAJOR_VERSION from package.json

efad4f6

Jake code review

3315188

Rename loading event

cb3c66f

fix prerender-loader with multientry

f24d41b

Trying to bend webpack to my will

2e478b3

Fixup sdk.js deployment

7dd842a

Revert wepack changes

915f4cd

Use microbundle for SDK

9008d1c

Add CORS to sdk file

9b87960

Remove that stupid async from setFile()

3005098

Fix caching headers for sdk

5270553

Only allow iframe embedding

956e064

surma force-pushed the api branch from acb70ef to 956e064 Compare March 20, 2019 17:53

surma requested a review from jakearchibald March 20, 2019 17:54

surma closed this Jun 15, 2020

surma reopened this Jun 16, 2020

surma changed the base branch from master to dev June 16, 2020 10:59

surma closed this Dec 10, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Client-side API #353

Client-side API #353

surma commented Nov 29, 2018 •

edited

Loading

jakearchibald commented Nov 30, 2018

surma commented Dec 3, 2018

jakearchibald left a comment

jakearchibald commented Dec 7, 2018

surma commented Dec 7, 2018

jakearchibald commented Dec 7, 2018 •

edited

Loading

surma commented Dec 17, 2018

surma commented Dec 19, 2018

jakearchibald left a comment

surma commented Feb 11, 2019

jakearchibald left a comment

surma commented Feb 25, 2019

developit Feb 27, 2019

jakearchibald Mar 7, 2019

surma Mar 20, 2019

surma commented Mar 5, 2019

jakearchibald left a comment

jakearchibald Mar 7, 2019

jakearchibald Mar 7, 2019

jakearchibald Mar 7, 2019

surma Mar 20, 2019

jakearchibald Mar 7, 2019

jakearchibald Mar 7, 2019

surma Mar 20, 2019

surma commented Mar 20, 2019

mbrevda commented Jun 18, 2019

vroussel35 commented Aug 28, 2019

usualoma commented Dec 25, 2019

mbrevda commented Jun 15, 2020 •

edited

Loading

dgrammatiko commented Jun 15, 2020

mbrevda commented Jun 15, 2020

developit commented Jun 15, 2020

surma commented Dec 10, 2020 •

edited

Loading

mbrevda commented Dec 10, 2020

	"build:sdk": "microbundle --compress -f es -o build -i src/sdk.ts",
	"build:sdk": "microbundle -f es -o build src/sdk.ts",

Client-side API #353

Client-side API #353

Conversation

surma commented Nov 29, 2018 • edited Loading

jakearchibald commented Nov 30, 2018

surma commented Dec 3, 2018

jakearchibald left a comment

Choose a reason for hiding this comment

jakearchibald commented Dec 7, 2018

surma commented Dec 7, 2018

jakearchibald commented Dec 7, 2018 • edited Loading

surma commented Dec 17, 2018

surma commented Dec 19, 2018

jakearchibald left a comment

Choose a reason for hiding this comment

surma commented Feb 11, 2019

jakearchibald left a comment

Choose a reason for hiding this comment

surma commented Feb 25, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

surma commented Mar 5, 2019

jakearchibald left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

surma commented Mar 20, 2019

mbrevda commented Jun 18, 2019

vroussel35 commented Aug 28, 2019

usualoma commented Dec 25, 2019

mbrevda commented Jun 15, 2020 • edited Loading

dgrammatiko commented Jun 15, 2020

mbrevda commented Jun 15, 2020

developit commented Jun 15, 2020

surma commented Dec 10, 2020 • edited Loading

mbrevda commented Dec 10, 2020

surma commented Nov 29, 2018 •

edited

Loading

jakearchibald commented Dec 7, 2018 •

edited

Loading

mbrevda commented Jun 15, 2020 •

edited

Loading

surma commented Dec 10, 2020 •

edited

Loading