Architecture
The printer system is designed to operate without a central server, and without a single source of printer content. It achieves this by using printer URLs to identify and send content to printers.
First, some terminology:
- A backend server is the server that manages rasterisation of content for printers, and serving that content for printers
- A content service hosts (and
POSTs) the URLs of pages that contain content to be printed - A printer is really the combination of the actual printing device, and whatever electronics (like Arduino) are connecting that to the backend server.
Here's how it all basically fits together:
In its simplest form, there is a single printer, connected to a single backend server, with a single content provider:
The printer polls the backend server at regular intervals, checking for content to be printed. If there is none, the backend simply sends an empty response (Content-length: 0), which the printer will then ignore. The URL that the printer polls is composed of the base URL of the backend server (http://backend1) and the printer's unique ID (abc123 in this case) -- http://backend1/printer/abc123
At any point, a content service can post to the printer's print URL, which is also composed of the backend server's URL and the printer's ID -- http://backend1/print/abc123.
When a content service sends a request also contains a url parameter, which points at the content which should ultimately be printed. In this case, the full url parameter is http://content/789xyz. This URL should contain as much information as the content service requires to properly determine the content for that printer. For example, it could also contain the printer ID, or a user ID, or any other parameters that might be necessary.
(Normally, this URL will be served by the content service itself, although that's not strictly necessary; what's important is that the URL is accessible to the backend server.)
The backend server then asynchronously makes a request for that URL, and once it receives a response, the backend is responsible for rasterising it.
When this process is completed, the next time the printer polls the backend server, the response will not be empty -- it will contain the printer data which the printer can finally print.
Because the printers have unique IDs, more than one printer can be maintained by a single backend server. As long as the content service knows the unique printer URLs for each printer, it can reliably send specific content to each printer individually.
In this example, the content service sends the content at http://content-a/789xyz to printer abc123, and then sends the content at http://content-a/715jkl to printer bcd234. The backend server is responsible for offering the correct content up to each printer, based on the URL that they are polling.
Naturally, many completely unrelated content services can send data to a single printer.
In this example, there are two content services, at http://content-a and http://content-b respectively. If they both know the URL of the same printer (http://backend1/print/abc123), then they can both send content to it.
The backend server doesn't really care that the two content requests are coming from different services; because the url parameter sent also includes the host, those URLs could be served from any host, on any network that is accessible to the backend server.
To really demonstrate the distributed, federated nature of this architecture, consider the example below, where there are multiple printers and multiple backend servers.
The content service has been informed about two printers: http://backend1/print/abc123 and http://backend2/print/def456.
In a similar way to the service-agnostic backend server described above, the content service is also backend-agnostic. Each printer URL includes a fully-qualified host, and when the content service is sending its POST request, it does not have to care which backend server is ultimately servicing requests to that printer URL.