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...

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.

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.

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)

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/