These nodes essentially expose this call to "set" DNS records and this call to "read" DNS records.
Notes:
I've only covered this limited subset of the full DNS API because they're probably the most frequently used bits, and selfishly because they're the only bits I need for my personal project :)
The other nodes have special icons - I've omitted icons for these because I can't find a similarly-styled icon for GCP DNS.
The API for these nodes is a bit weird: having the node inputs and outputs be the same as the underlying DNS Javascript API would be easy to write, but it's hard for users to find that API (I had to read the source to work out what the objects are), and the use of toJSON overrides in that library means users would essentially have to use JS function nodes to include the library and create those objects before passing them in, rather than just construct JSON objects with the same structure which is pretty conventional for node-red.
The REST API has some nice JSON-compatible parameters/responses which makes it easier to use in node-red, and is very easily discoverable. But then we need to translate between REST- and JS-style values in the nodes in order to use the client library :(
This implementation finds a middle ground by translating the "necessary" (all input parameters) and "useful" stuff (the records returned by the Record List node) and exposing the "raw" JS-api responses in msg.response. It's not very neat, but it's easy to use. Open to suggestions on changes to this approach.
This is the first JS I've written, it's mostly tweaks on existing files in this repo, so please recommend improvements if you find any.
These nodes essentially expose this call to "set" DNS records and this call to "read" DNS records.
Notes:
The API for these nodes is a bit weird: having the node inputs and outputs be the same as the underlying DNS Javascript API would be easy to write, but it's hard for users to find that API (I had to read the source to work out what the objects are), and the use of
toJSON
overrides in that library means users would essentially have to use JS function nodes to include the library and create those objects before passing them in, rather than just construct JSON objects with the same structure which is pretty conventional for node-red.The REST API has some nice JSON-compatible parameters/responses which makes it easier to use in node-red, and is very easily discoverable. But then we need to translate between REST- and JS-style values in the nodes in order to use the client library :(
This implementation finds a middle ground by translating the "necessary" (all input parameters) and "useful" stuff (the records returned by the Record List node) and exposing the "raw" JS-api responses in
msg.response
. It's not very neat, but it's easy to use. Open to suggestions on changes to this approach.