At Propeller we’ve found that the battle tested Cesium math classes can be useful for various applications outside of a Cesium viewer. e.g. NodeJS server side computation and rendering, in-house libraries that require some vector math etc. Pulling in Cesium as a dependency can be reasonably heavy (currently 90MB) which inevitably provides a lot of functionality that remains unused. It also ties in to the monthly Cesium versioning, where the core math classes in practice change infrequently.
To address this, and to help in space constrained environments (like AWS Lambda) we have developed an in-house compact library that is a drop in replacement for a subset of Cesium functionality and uses semantic versioning. At the moment it is already useful in providing functionality like…
Is this problem unique to us? Is anyone else doing similar? What is the level of interest in some sort of solution either managed by the Cesium team as part of the CesiumJS project, or open sourced by a 3rd party (e.g. Propeller)?
Although I’m not so deeply involved in CesiumJS or applications that could find parts of CesiumJS useful, I have one very high level comment:
If CesiumJS is split into multiple parts, then one could at least consider to align this with GitHub - CesiumGS/cesium-native . This does not mean that the mapping between “classes” and “libraries” has to match perfectly in both environments. But I think that from the perspective of consistency, documentation, and discoverability, it could be good to at least have similar “concepts” or “domains” being covered with these libraries.
As such, most of the classes from the list above would fit into some
CesiumGeometry library, but some of them could reasonably be moved into a
CesiumGeospatial library. The latter would likely depend on one of both of the former, but would only be required by applications that want to do more than pure vector math.
Thanks all! A few thoughts:
Within Cesium, we have our own use cases for a more compact or minimal Core CesiumJS library, such as in GitHub - CesiumGS/gltf-pipeline: Content pipeline tools for optimizing glTF assets., where we depend on CesiumJS for utilities but don’t use it for rendering. (Which is then a dependency back in CesiumJS - gltf-pipeline as an npm module? · Issue #9614 · CesiumGS/cesium · GitHub)
CesiumJS is already pretty modular, and having smaller cohesive modules is usually a best practice. So I don’t think there are many concerns from an architecture perspective.
If we were to introduce a solution like this, we would need to make sure it does not introduce an additional maintenance burden. For instance, it’s common to make changes to Core classes and non-Core class simultaneously in PRs, and we want to make sure there’s not more developer overhead to do so. As such, we would most likely want to maintain multiple modules from one “monorepo”.
Popular projects like Bablyon.js, Babel, React, and Angular all maintain a monorepo which publishes several packages with lerna.
If you are thinking to embrace a monorepo approach to the Cesium architecture at some point, you should check out Nx, one of the best monorepo implementations currently that also took stewardship of Lerna.
Awesome, thanks @Aristeidis_Bampakos! Nx looks like a powerful tool and may be a path to investigate further if we do go all in on the monorepo approach. It looks like we could migrate after setting up lerna, and would be able integrate with existing dev tools.
That’s great! If you need any help or want to get in touch with the Nx team somehow, please let me know
I’d love to see this, our current non-browser / non-visual approach is a hotch-potch of libraries and own code that we had to put together in fear of having to use the whole package in every little project, which is a shame as a lot of the Cesium code is really fast and good. +1 from us at 4DMapper. Happy to help out with whatever is needed.
We’ve been planning out an initial implementation of smaller npm modules with npm workspaces, starting by splitting off
Widgets into their own package. We chose to start with
Widgets since its a clear architectural delineation, is not needed by many web apps, and brings in dependencies which can be problematic for some projects. The idea is that we can then further break out smaller packages, like
Core, later using a similar structure.
Please comment in that issue to let us know if you have any thoughts!