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.
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.
[1]: https://github.com/jupyterlab/jupyterlab/issues/11826