Is it safe to depend on .glb provided by backend API?


We are using ShapeDiver both for illustration and computation in our SaaS service. We run a React SPA and a HTTP REST backend, where the integration with ShapeDiver is currently located mostly in the SPA.

As per new customer requests we our clients want to integrate with our API and skip using our UI entirely. Now we are facing the challenge of providing all of our features via the backend API only. One option for this that we see is that we help them integrate directly with the ShapeDiver viewer in their own UI, but that creates a need for firewall configuration which our client dislikes. They want to allow only one URL through, ours.

So we are thinking like this: We have noticed that we can use ShapeDiver backend APIs /output endpoint to receive both computation outputs and also .glb file references, which we seem to be able to render in any .glb-compatible viewer. That way we could potentially “forward” ShapeDiver graphics via our API and solve the firewall issue of our client.

I have not been able to find so much documentation about this particular “style” of implementation. Asking the team directly here, what are your strategy/commitment for these .glb files? Are they considered a stable and supported method of interacting with ShapeDiver? What do you think of these integration plans as a whole?

Do you have any documentation references relating to this which I may have missed?


My apologies for answering with a delay.

The implementation your are describing is of course possible and the recommended way to implement a ShapeDiver application with a different viewer than the SD one. When using the glTF 2.0 Display component of the plugin, each instance of this component generate its own glTF 2.0 asset which can be rendered in any viewer according to the glTF specification.
You can read more details about the glTF 2.0 Display component here. This article includes some details about the structure of the resulting glTF files.