I’ve spent the last few hours building a Node.js library called DiggyDB as a proof of concept.
First, I should briefly explain some database definitions and how they are used:
- Database: This is essentially the main hostname of the domain.
- Table: This is part of the subdomain.
- Row/Key: This is the last part of the subdomain, and allows you to query for a specific row in the “table.”
- Value: In its raw form, this is the actual TXT record value that corresponds to the FQDN as shown above. This is split into what is essentially a column and its value.
If we know the Key and the table, we can use
dig to look up the value:
$ dig -t txt 3a7b68cf-686a-4135-b48b-6471deb3643a.frameworks.diggydb.example.com +short"name=gatsby"
So with that in mind, let’s see what it might look like if we use DiggyDB to:
- Query all rows in a table called “frameworks” (via AWS SDK)
- Query for a specific item in the table (via DNS)
- Add a new item to the table (via AWS SDK)
- Query all rows in the table again to show the new item (via AWS SDK)
Pretty powerful, and you’ll notice that it’s actually quite fast to perform these actions, especially if we are querying for a specific key in the table as this is done via the DNS lookup, so only takes ~55ms. DiggyDB uses the AWS-SDK in order to modify the DNS records, which takes about ~1s.
Here’s how it is stored in Route53 (i.e., raw format):
Here’s the actual code for querying a table:
As we’re using the AWS-SDK, we need to include the
secretAccessKey in the config.
And here’s the code for querying a specific key in the table:
Notice how we didn’t include the AWS access key configuration? That’s because we’re using the DNS lookup method for this, so it’s not needed.
Lastly, this is how we would add a row to the table (again, using the AWS SDK for this):