Extending CUE Front

Most CUE Front-based sites have some requirements that cannot be satisfied by CUE Front and the CUE system alone – either because CUE does not provide a particular service or because the customer needs or wishes to make use of a specific third-party service. Typical examples include access to external data sources such as sports results services or stock market information, user login, paywall systems, cookie management and so on.

It is not always obvious what approach users should take when implementing such extensions: what technology to use, where to extend CUE Front and so on. This section is intended to provide a few guidelines to follow when making decisions of this kind.

First of all, here is a list of some of the possible ways in which you can add functionality to a CUE Front installation:

Extend the Cook by creating a recipe extension that retrieves content from an external service such as a stock ticker service.
Extend the Cook by creating a recipe extension that restructures or extends content retrieved from the Content Store in some way.
Create your own service that generates interesting information of some kind, and then create a recipe extension that retrieves content from it.
Create an extension to the Waiter that generates or retrieves content of some kind, or provides some kind of service to site users.
Create a front-end component that sits alongside the Waiter and provides some kind of content or service directly to clients. In this case, the nginx web server that fields incoming requests must act as a router, forwarding requests to the Waiter or to your service depending on the request URL.

The question of how and where to implement an extension should be determined by the following considerations:

What kind of extension is it?

One of the objectives underlying CUE Front's design is to keep business logic separate from presentation and layout. The general idea is that the Cook should handle all business logic, and provide the Waiter with all the information needed to construct web pages. So the general recommendation is to implement extensions in the back end as recipe extensions. This is particularly the case for extensions that are primarily concerned with content (such as sports results services or stock market information services). Implementing content-rich extensions as recipe extensions means that the retrieved or generated content can be merged into the JSON data structure returned by the Cook, allowing all layout to be handled by the Waiter (or your alternative front-end solution) in a uniform way.

However, extensions that are primarily concerned with user access are probably best handled in the front end (whether that is CUE's Waiter, or your own alternative front-end). For example, user login systems, paywall systems, cookie management systems and so on. Cookies in particular are best dealt with in the front end. By default, the Waiter does not pass cookies on to the Cook in order to ensure the "cacheability" of the Cook's responses.

What kind of front end do you have?

If you are using CUE's Waiter as your front end and you want to extend the front end, then you might want to create a separate component that sits alongside the Waiter rather than to directly extend the Waiter itself. This will:

Give you complete control over how you implement the service: you can make use of the languages, tools and libraries of your choice without having to conform to any limitations imposed by the Waiter.
Give you the freedom to upgrade the Waiter without needing to merge updates from Escenic with your own changes. The Waiter is a very small, simple application that is unlikely to change much in the future, and CCI Europe does not officially maintain it. It is provided "as is" as a starting point for development projects. Nevertheless, if you want to ensure that you will be able to easily replace it with Waiter versions included in later CUE Front start packs, you can do so by implementing any front-end extensions as separate components.

What are your preferences, strengths and weaknesses?

The answers to the two previous questions is general advice that may not necessarily apply in all situations or for all organizations. For example, implementing an extension as a recipe extension because it is "content-rich" may make sense in a general way, but not if your development department is a PHP shop with very little experience of node.js development. In such circumstances, sticking to what you know may well be the best strategy.

Routing

When implementing front end extensions, you need to ensure that routing is correctly handled and that there is no possibility of your components duplicating URLs. If you implement your extensions as standalone applications running alongside the Waiter, then this should not be a problem: you just configure nginx to route requests to the correct component based on the first part of the URL, and then each component is thereafter responsible for its own URL space.

If, on the other hand, you directly extend the Waiter or alternative front end, then the recommended approach is to let the Cook do the first part of the routing for you by passing all incoming requests to the Cook in the usual way. Any URLs that are not recognized by the Cook are returned in the JSON output's remainingPath field, from which point your extension can continue the routing process as required, and deal with the requests.