Typically, a complete integration for a client-side rendered site or single-page app would include some or all of the following five patterns:

• Standard Zephr Feature Rules – in some cases top level components are appropriate targets for Zephr feature rule, which can remove or replace the components if required.
• Transformation of API responses used by the client-side code – usually, a client-side app will be receiving data from the server; Zephr can intercept the responses to the AJAX requests using Request Rules.
• Public API for decisions and challenges – the Zephr Public API can be called from the client to retrieve access decisions and the results of entitlement challenges, the logic for how to handle these decisions needs to be applied by the client-side logic; it’s worth noting that replying on client-side access control logic may be easy to circumvent.
• Reading the dataLayer – Zephr can be set up to automatically push variables into a dataLayer object; these might include entitlement grants, meter counts, first-party data, etc.; that data can be used client-side to make the experience bespoke to the current user.
• Using Zephr Feature Rules to add custom Javascript objects – as well as wrapping visible features on a site – one may choose to use a (potentially empty) Zephr Feature comment to inject custom Javascript based upon a feature rule; this can take advantage of the built-in Mustache templating engine in Zephr to construct custom objects.