This exists to interact with the backend of workflow (which is not public facing, but instead this lambda is given access to the VPC/subnets which workflow backend uses) for retrieving the list of available pinboards (for the moment, a pinboard is just a workflow stub) and to lookup specific workflow items based on composer ID (used in the 'preselected' pinboard feature in composer).
This lambda is configured as a 'data source' in AppSync, which means if we ever store 'pinboards' elsewhere, such as our own table, the client won't have to change one bit! In general this approach also avoids us having to either connect AppSync directly to workflow tables (bad practice, as they could legitimately have their shape change, and thus break Pinboard) or connect AppSync to workflow-frontend via HTTP, which would require panda cookies (messy to forward from client, or would need to set-up panda-hmac). Lastly this also means the lambda can transform the responses however we need them (all in nice TypeScript, not nasty 'Velocity' which is the language of the AppSync resolvers).