Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents
minLevel3
outlinetrue
stylenone

 

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.

...

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.

...

TQL QueriesRestful Services

XML Oriented (Request & Response)

(Note that TQLEngine supports both JSON & XML;

the recommended guideline is XML for TQL Queries

readability)

Restful Services are JSON oriented

TQL Queries are sent as payload, therefore the HTTP Method to be used

always POST.

Method can be: GET/PUT/POST/DELETE

 

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. 

...