Background

TQL queries and subscriptions consists of dynamic (user defined payloads) payload sent over HTTP or WEBSOCKET transports. Consuming TQL Queries in UIs (HTML/JS, Android, IOS and others) in this regards are similar to consuming any RESTful services.

In the tutorial we answer some of the following questions:

1. What is the role TQL queries play in an UI app
2. What are the 3-5 technical things I should know about using TQL Queries in my UI app?
3. Where and how in my UI app should I use TQL? What is the relationship of TQL queries with my UI app components.
4. How TQL queries fit into the development lifecycle of my UI app development?
5. Can I write more interesting apps with TQL queries (which I cannot do using conventional APIs or using conventional SQL queries?)
6. What are the design considerations of using TQL queries to make my app more <dynamic, scalable, extensible, future proof,..>
7. What are the common errors/exceptions and how should I diagnose?

Let's address some of these questions when building UI Apps using TQL Queries using a template HTML/JS App. You can download this app here

Role of TQL Queries in UI App

TQL Queries Vs REST Services

REST is an architecture style for designing networked applications and in virtually all cases, the HTTP protocol is used. In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. By this definition of REST coupled with the fact that TQL Queries are executed over an HTTP endpoint that is automatically generated when models are deployed to TQLEngine, make TQL Queries Restful in nature.

In the table below we note fixed REST pattern that is applicable to TQL Queries.

When does my role being?

Here is the typical Modeling flow of control:

• Right after initial Model is written, the UI App developer can start working closely to identify (or write) queries.
• Work with Business Analysts to create appropriate UI flows etc

Things you should be aware of?

As with building any UI app that interacts with backend serivces, you would always need:

• • Endpoint (HTTP or WS) to interact with backend
  • Request and Response Format
  • Ability to try out sample requests before integrating them into UI application

Design Consideration

• Never hardcode the TQL Query endpoint urls as they are subject to change.

• Instead the endpoints must be auto discovered given the project name. 

• The model developer (owner) will provide you appropriate project name to discover your query endpoints.

• You can test the queries and make sure they are working via Query Editor (TQLStudio or Local TQLEngine)
• Notification frequency and WEBSOCKET reconnect logic.
• Externalize the Queries as much as possible to the App. (Via some config file like: querys.cfg.xml)
• You can serve your UI app (in case of say, HTML/JS) via TQLEngine itself using TQLEngine's ThingSpace / Attach Application feature

Go build some cool app

One of the key difference between Atomiton's TQL platform vs any other middleware platform is that you have the power to write your own queries against the model that is delivered to you by the Model developers. 

• Model developers may provide initialization queries.
• You as an UI App developer can decided if you want to combine multiple Find's into one to optimize the rate of transfer.
• Use aliasing to change the output of TQL Query result.