Applications developed with Zetapush are made of two main components :
- The Client software (a web page, an app on a smartphone, an IoT device...). You develop and deploy client apps as you see fit.
- The Server part, which allows interaction between users, data storage, etc... The Server is made of Zetapush-hosted services and authentications.
Clients communicate with to the Zetapush servers thanks to our SDKs. For clients with low resources, simple HTTP requests are also possible.
Most classical APIs out there follow the request-response paradigm, where the client code initiates a request and receives, synchronously or not, the response.
The Zetapush APIs, on the contrary, use a publish-subscribe paradigm : this means that, sometimes, the connected clients can receive messages even if they did no request them.
A Zetapush cluster, however, does not behave as a generic message broker : each and every API call is subject to fine-grained access control and is properly routed.
Note that the ZMS language totally hides this paradigm for most API verbs, which can be called in your macro code in a classical synchronous way.
Services are ready-to-use server-side components that you can deploy in your sandbox. A service offers a consistent set of APIs for a particular feature such as data storage, task scheduling, etc...
APIs offered by deployed Services come in two flavors:
- Administrative APIs allow you (the application developer) to configure the service. They can be scripted with your recipes (that's the recommended approach), or used with standard HTTP calls. The admin web UI makes use of them for example to let you manage your GDA tables.
- Real-time APIs allow your client applications to use the service. They can be called directly from the client, through our SDKs, or from ZMS server-side scripts.
For example, the GDA service makes it easy to store and retrieve data in a non relational database.
- Administrative APIs let you create tables, add columns.
- Real-time APIs let you insert or retrieve data.
All interactions from your clients to your Zetapush app need some kind of authentication (If you feel you do not really need to bother with authentication,
the weak authentication
is what you need).
Clients always authenticate first, before being able to use the APIs.