Getting started offline, what to follow?

[donvi-bz]

So we're finally going to get started implementing iTwin, and while doing this were avoiding paying for services and making accounts. Since we're likely going to have multiple viewers active at once, I'm assuming the best way to set this up would be to develop a separate back-end and front-end system. For front-end, this looks like recommended starting point, but I'm not sure how to start developing the back-end, nor how it will eventually connect it. Any help would be appreciated.

Also, does the back-end server need to be running to query BIM related info?

Editing in another related question: If in the future we want to do a Unity project based on this data, would it require the same back-end service that the web client connects to?

[mgooding]

For Unity, take a look at https://github.com/imodeljs/imodel-unity-example. This includes an example backend service. You will use the same iModels that you'd use for your web applications, but it's a different backend service.

[Josh-Schifter]

It sounds like you are planning to target a web viewer workflow. It also sounds like you are only mentioning 'offline' in order to avoid paying for services during development. If I got that right, then you should be able to follow our typical web viewer starting point that you already found. There is no need for you to set up your own backends. By default, the viewer template targets a backend hosted by Bentley and intended for exactly this type of usage.

You will need to create an account, but that is just to give you an identity that can own the resources you will create. There is no cost and the only prerequisite is to provide an email address.

This tutorial walks you through the whole process.
https://developer.bentley.com/tutorials/web-application-quick-start/

[donvi-bz]

It also sounds like you are only mentioning 'offline' in order to avoid paying for services during development

So basically this, but with one extra 'offline' bit. Everything that we have been doing so far only talks on the local network. I haven't been told that its entirely necessary to air gap the system or anything, but I was trying to avoid letting any service outside the local network. All our monitoring, storage, display, etc is entirely offline and never will communicate on a public network.

Also, maybe this is just be expanding my general views on web projects to other things, but for the most part there is a back-end and a front-end to any web product. For things like a mobile app, I've done it where everything gets packaged together, but for any other system I've always had a distinct front and back. What I thought I got from other documentation was that the front-end was the displayer of the data, showing the actual model and putting on any sort of tags. In my mind that is also the only place UI elements lived. The back-end looked like it was for loading and serving the model information itself.

The Unity example uses a distinct front end (in unity of course) to display the data, and a Node.js back-end to serve it. My assumption was that we could host a single Node.js back-end to feed data to some Unity viewers and web viewers.

Is that not how it would be done?

[Josh-Schifter]

For the typical iTwin viewer web architecture, there is indeed a distinct front and back as you've described. But, there is more to it than that. Just as examples, there is routing, load balancing, identity management, and storage. Storage is the easiest to understand... we have a service called iModelHub that manages the entire change history of each iModel.

It is possible to do all of this stuff on a private network. However, that will be more effort. Again, I suggest getting started using the tutorial. You can worry about staying off the public network if/when you have a solid requirement.

[mgooding]

The Unity example uses a distinct front end (in unity of course) to display the data, and a Node.js back-end to serve it. My assumption was that we could host a single Node.js back-end to feed data to some Unity viewers and web viewers.

If it's your custom backend, you could have it serve data to both Unity and the web viewers, but I would recommend separate backends.