Maria O’Connell contact me by email to set up a web session with you but I first prefer to discover the product on my own in order to have a sound list of doubts
I saw an interesting video here Dockerizing 3D Web Applications - YouTube, Dockerizing 3D Web Applications by Tony Tyrrell where I can see the separation of Hoops Server and the front end in two separate docker containers.
It will be nice to see the source code of this web app. I have searched for it in your GitHub repositories without success.
I want to separate my web app completely from the backend and by backend I mean Hoops Server and Stream Caching Sever instances.
But unfortunately the quick starts and examples provided, tend to assume that we run the Hoops Web Viewer instances and the Hoops server together, and in the reality/production this will be not the case I think.
I did not saw a tutorial with that information. The best I discovered was this doc Connection to the HOOPS Server, that explains how the web app can connect to the Hoops Server in order to make a request to create a new stream caching server.
I also discovered in this doc the reference to /service endpoint. But this endpoint is not documented here REST API Reference, the only endpoint I saw to request a new stream caching server is /api/spawn.
Is the /service endpoint only to be used with websockets (ws)? Where I can find documentation about it?
Attached we can see an image that shows the use of /service endpoint in communicator_server_integration.js, with your samples that comes with Hoops Web Platform installer (…\HOOPS Installer\HOOPS_Web_Platform\web_viewer\src\js). But its difficult to understand the source code of communicator_server_integration.js
Hello,
I already discovered on how to, from a web application, contact Hoops Server in order to request it the creation of a new stream caching server:
I only have to use a URL like this: endpointUri: “ws://localhost:11180”
Connecting to 11180 using websockets, Hoops Server will create the stream caching server
Now its easy to have 2 separate docker containers, one running the web app and another running Hoops Server and Stream Caching Server instances.
I think it is important to understand that there is a one to one relationship between an instance of the stream cache server and a client-side viewing session. In short, for every viewing session that uses streaming one instance of “ts3d_sc_server” needs to be running. The HOOPS Server is a different beast, its basically a node based application that spawns and manages those viewing sessions. It’s useful to get something quickly up and running but in a production deployment you most likely want to control the spawning of that executable yourself.
My suggestion would be to have a look at the tutorial below which outlines how to develop your own streaming service. I think it helps understand the concept behind our streaming server a bit better:
Just to be clear though, you can deploy the HOOPS Server on (for example) an AWS instance with minimal modifications and serve multiple viewing session to clients from different machines, all connecting via port 80. It has a built-in proxy that handles dispatching the connections automatically.
With regard to the /service endpoint, this endpoint is deprecated in favor of the api/spawn endpoint.
Hi Alberto, actually if you read through the documentation about /api/spawn, you will notice a blue pararapgraph with the description:
This endpoint has replaced <service_broker_url>/service from the old HOOPS Server. That endpoint has been deprecated but is backwards compatible with the new HOOPS Server. We strongly recommend you consider updating to the new api/spawn endpoint.
For your initial question regarding infrastructure, you will also find different scenarios depicted here that might help you with getting a good overview of possible setup: Deployment Scenarios
The question I would have for you, and that could save you some headache about infrastructure and maybe give you a hint of the benefits of a supported evaluation: Does your workflow or the type of models you want to view justify having the need of streaming?
Effectively, we also provide a conversion to file (.scs) that can be served like any other files from a web server, simplifying greatly the server infrastructure needed.
