instances.texi (1119B)
1 @c Section from ``advanced topics'' introducing the concept of instances 2 3 @node Instances 4 @section Instances 5 @cindex instances 6 7 Taler's design allows a single backend to manage multiple frontends. 8 In other words, we might have multiple shops relying on the same backend. 9 As of terminology, we call @emph{instance} any of the frontends accounted 10 by the same backend. 11 12 The backend's RESTful API allows frontends to specify which instance they are. 13 However, this specification is optional, and a ``default'' instance will be 14 used whenever the frontend does not specify one. 15 16 Please note that in this stage of development, the backend's REST call @code{/history} 17 returns records for @emph{any} instance. The rationale behind is to allow grouping 18 ``public'' business entities under the same backend. 19 20 This way, a single frontend can expose multiple donation buttons for multiple 21 receivers, and still operate against one backend. So in this scenario, there is no 22 harm if the operator of instance `a' sees history entries related to instance `b'. 23 24 See @code{https://donations.demo.taler.net/}, which uses this functionality.