Introduction

CUE Front is a collection of web services that together serve content to client applications such as browsers and native mobile/tablet apps. The CUE Front web services are:

Cook: A back-end service that retrieves content from the Content Engine and serves the content to clients as JSON data via an HTTP-based content API.
Cleaver: A back-end service that retrieves, crops and resizes images for the Cook.
Waiter: A front-end service that responds to requests from browsers and other HTTP clients. The Waiter passes on incoming requests to the Cook and is responsible for rendering the JSON data returned by the Cook as HTML.
Fridge: An optional caching service that can be used in several different ways together with the other CUE Front components.

The CUE Front services (or microservices) are not embedded in the Content Engine. They are free-standing entities that only communicate with the Content Engine and each other via HTTP. Although they will often be installed together on a single machine, they can, if required, be run on different machines in different locations, or in the cloud.

The following diagram shows how HTTP requests and responses flow between the Waiter, the Cook, and the Cleaver:

Both the Cook and the Waiter satisfy incoming requests by sending requests either to the Content Engine's REST API or to a Fridge caching layer.

CUE Front is intended to serve as a more modern replacement for the Content Engine's existing built-in presentation layer. It offers a number of advantages over the old presentation layer, including:

Technology independence: Escenic's old presentation layer required the use of Java Server Pages (JSP) to build web pages. The Cook's content API, on the other hand, supplies page content as language-neutral JSON data, freeing you to use whatever language and technology you prefer for your front-end component. The Waiter that we supply with CUE Front is written in PHP, but use of this component is entirely optional. You can replace it with software written in any language you like. And in the case of mobile/tablet apps, you can dispense with a Waiter altogether, and serve JSON content directly to the app.
Scalability: Scaling web sites built with the old presentation layer involved installing multiple instances of the entire Content Engine, and required complicated caching strategies to avoid overloading the database. The CUE Front components are completely decoupled from the Content Engine and can be scaled separately. A complete copy of all the content in the Content Engine's database can be stored in one or more Fridges and all the other CUE Front components configured to get their content from a Fridge rather than directly from the Content Engine. Fridge contents are kept up-to-date by pushing changes from the Content Engine when they occur. This means that you only need enough Content Engine instances to support your editorial operation, and web site scaling is a completely separate issue.
Upgradeability: CUE Front is designed to support blue/green deployment for frequent upgrades to the published web site. Since CUE Front is completely decoupled from the Content Engine, such deployments have no effect on the back end. Conversely, upgrading the Content Engine has no effect on the front end, if all web site content is being served from a Fridge. It is possible to take all Content Engine instances offline simultaneously without affecting published sites in any way (other than the lack of updates to the content).

Breaking the presentation layer into separate services encourages separation of concerns: front-end developers/designers can work exclusively with the Waiter (or some other front-end service), and do not need to know anything about Cook or Cleaver. Similarly, back-end developers can concentrate on ensuring that the Cook delivers the required content to the front end, and need not concern themselves with how it is presented.