[lneves12]

We are actually bundling everything inside one big main.js file, compared to jupyter-lab app that loads each extension from a different file using webpack federated modules. We did some benchmarking and it was actually faster than having one file per extension. There is definitely still some room for improvement here, but we have some other places we would like to optimize first, like, optimising the fetching of the notebooks content.

You can take a look at the notebooks entrypoint network request: https://portal-notebooks.singlestore.com/

[jasongrout]

Nice. Bundling everything together was how JupyterLab used to work before version 3, but it required a compilation step to install extensions, which made it inconvenient for users. With JupyterLab 3 (and maybe 4?), if I recall correctly, you could have both worlds - compile some extensions into a base js bundle, then install other extension to be loaded as federated webpack modules.

[lneves12]

Thanks for the context, that makes a lot of sense. In our case since we have a more controlled and less generic environment we have a bit more flexibility/control in what we can do.

[canucker2016]

I don't see a Content-Encoding header on the response for the JS and HTML files, which suggests the 11.5MB JS and the HTML files aren't compressed.

Not much of a worry on the tiny HTML file, but the 11.5MB JS file should compress to a much smaller file on the wire.

[lneves12]

ah I thought I was going crazy (I was sure this was working at some point). The compression just stopped working because of a cloudfront limitation eheh

`CloudFront compresses objects that are between 1,000 bytes and 10,000,000 bytes in size.` - since the file became bigger than 10mb, cloudfront stopped compressing it...

[canucker2016]

Well at least you know you weren't lazy/ignorant.

It's just that your tools make you look that way... and cost you more money in extra bandwidth as well. I hope that's the last of the surprises in that area.

[lneves12]

ah that's an embarrassing oversight! we reuse the same cdn configuration for multiple projects and for some reason the compression isn't properly configured for our portal-notebooks.singlestore.com entry point. It's funny that I reconfirmed that before publishing the blogpost, but mistakenly looked at the request headers and not the response headers (facepalm). We are fixing that now, thank you! This will be helpful for cases where you access the notebooks UI directly. For cases where you come from other page, it shouldn't make that much difference, since the iframe is already pre rendered.

[paddy_m]

I take it that's supposed to be the pre-loading page to just look at the requests, not a full working UI?

After cursory googling I couldn't find one, do you have a public notebook gallery?

[lneves12]

Yeah, sorry should have made that more clear. This doesn’t really load anything, it’s just the entry point for our iframe. To try our notebooks you can create an account at portal.singlestore.com (we have a gallery of notebooks there)