Best practices for client communicating with TG

Coming from the MS world, typically an application communicates with the database via a web service call to a web server. The web server handles various things such as security and can validate what the user is allowed to do before touching the database. The database is securely locked down behind the web server. The web server makes a call to the database from its data services layer and can handle any exception handling if necessary. And finally, a response is sent back to the client from the web server.

How does this compare with best practices in the TG world?


I believe, the same concept applies.
While GraphStudio is a wonderful tool for database design, data load and exploration by data engineers and analysts/scientist, typical end users would not use it. I assume that there would be either a dashboard or web GUI for end-user usage (and the dashboard and/or web server would interact with TG via the REST API, mostly or only calling queries (our kind of stored procedures) developed by data analysts/scientist). Or a backend system (e.g. a credit check app or network monitoring solution, something without direct end-user access) would call the queries and use the result in automated decision making or alerting.
So, as I said above, the same 3-tier architecture would apply in case of TG.

@gpadvorac You can use a middle tier to interface with your TigerGraph database. Many people using React will use NodeJS to call to TigerGraph DB. Also, there are users using Firebase functions to call TigerGraph.