I was on this team at SingleStore and I can vouch for how hard this team worked on this project. I just opened a couple notebooks in production and they loaded *instantly*, so kudos to the team for seeing this project through.
(If you're not familiar with SingleStore's Jupyter Notebooks, they're similar to Databricks Notebooks[1] or Azure Synapse Notebooks[2]).
I appreciate the write-up, it's very insightful. But I was quite concerned about the amount of response mocking being used as a solution. Did the team ever consider instead making upstream changes to jupyter-lab (which is FOSS), so that these requests are either deferred or can be configured to not run? That seems like it would benefit everyone, including your company - and might even uncover further optimizations.
Hi, I'm one of the co-authors of the blog post. You raise a valid point and, in large part, I agree with you. To offer some explanation, there are essentially 2 main reasons for us taking this approach:
1. Contributing to an open source project, especially one the size and complexity of jupyter-lab, is generally going to be a slower process than finding a solution "in house". Improving the load times became a priority once we realized our notebooks were bringing value to users, and we wanted to deliver a better experience as soon as possible;
2. It's not always apparent if the changes you are looking for from an open sourced project are useful to a more general audience or if it's very specific to the way you are using the project. A lot of the requests that were mocked could only be so because we either didn't use them in our implementation (for example, users and workspaces) or because we know the response won't change (for example, some extension settings which we don't allow users to change). Is this a common situation for others or is it a niche circumstance of how we are using jupyter-lab? If it's not common, then adding these options in jupyter-lab itself could just increase its complexity while not bringing that much benefit (not saying this is necessarily the case here);
To your point though, a good example of this is the checkpoints feature. There is an open issue requesting the option to disable checkpoints[1] as it is not always useful for people. We had the same issue, since we are not using checkpoints, but the requests were always being made. Ultimately, we just mocked the checkpoints requests, but it's probably the case that making the changes to jupyter-lab to disable this would benefit us and other people as well.
Thanks for the clarification, that's fair enough. But I hope you do look into upstreaming, maybe even just by opening an Issue to guage community interest. Like the pre-existing checkpoints Issue you linked to, opening some for your functionality might show others what is possible.
(If you're not familiar with SingleStore's Jupyter Notebooks, they're similar to Databricks Notebooks[1] or Azure Synapse Notebooks[2]).
[1]: https://docs.databricks.com/en/notebooks/index.html
[2]: https://learn.microsoft.com/en-us/azure/synapse-analytics/sp...