I would have loved to, but one of the sticking points was that the label file had to be serialized, saved, and later interpolated with data from a bunch of different records, which is why I used svg over canvas, wrote my own editor, etc. jsPDF seems great for imperatively generating a pdf, but not for editing/loading template files. Plus, since the pdf generation had to happen server side, I would have needed a headless browser anyway.
It's super weird, and I've been over it from every direction but I don't know how I could have done it differently.
1. Client creates a custom label and we store it in s3
2. They select x inventory items + click print
3. We retrieve and send the label file + inventory data to a service that interpolates the data into each template, renders to pdf, merges them, and forwards it to our printing service.
We certainly could do the work on the client, but they're making this request in a context where neither the label nor the libraries need to be loaded; in fact, in our server-side implementation, it could be done with a single api call. Doing it all client side would strongly couple the client to the technology.
Also, we re-used this api in two applications, one of which never loaded the editor (along with its dependencies).
TLDR; a weird hack was better than violating separation of conerns.
anyway i'm doing basically exactly this same thing except all client side (i send the serialized "label file" and data to the client) but printing is being done using the user's printer
Yep, the printing service is a third-party api (PrintNode) that routes the request to one of any number of desktop clients.
The reason we did it this way is 1. we have a web app so we can't print directly to their printer without a print dialog, and 2. we want to print to potentially a different device than the user is on.
