Storing/representing a hierarchical tree used for navigation within an Amplify web app and AppSync GraphQL API layer.

Question

Hi,

**TL;DR: Can anyone give a recommend approach to storing customisable n-level hierarchy trees for grouping and navigating results via a frontend Amplify-powered web app (using DynamoDB or any other database solution that can be mapped to AppSync ideally)?**

**Some background**

I'm building an multi-tenant IoT analytics solution that takes data from some sensors out in the field, uploads to AWS, processes this data and stores in a DynamoDB table (i.e. a very "standard" setup). I'm planning on adding a web frontend (built using Amplify and an AppSync GraphQL layer) that will allow users to navigate a **customisable, n-level** hierarchy tree of assets, in order to view the sensor data we've collected.

Examples of valid hierarchies include:

Country -> Site -> Building -> Floor -> Room -> Sensor (6-level)
or 
Site -> Building -> Room -> Sensor (4-level)
etc.

The important thing here, is that this hierarchy tree can differ per customer, and needs to be customisable on a tenant-by-tenant basis, but we don't need to do any complex analysis or navigation of relationships between hierarchy levels (so, to me, something like Amazon Neptune or another graph database feels a bit overkill, but perhaps I’m wrong).

My first thought was to try and build a hierarchical relationship inside of a DynamoDB table, possibly making use of a GSI to provide this, but in all of the examples I’ve seen online, the focus is very much on quick retrieval, but not so quick updating of hierarchy trees – now, whilst it’s unlikely that these tree structures would be updated on a regular basis, it is something we need to be able to support, so the idea of possibly updating ‘000s of rows in DynamoDB every time we want to make a change to the hierarchy tree for a given control area doesn’t seem quite right to me.

Hence, my question above. I'm ideally looking for guidance on how to structure a DDB table to best support BOTH optimal retrieval of, and updates to, hierarchy trees in our application, but if DDB isn't the right answer here, then suggestions of alternatives would also be greatly appreciated.

Many thanks in advance.

Answer

There are different aspects to your question and I'll try to give my point of view on some of these aspects.

Creating a graph view using GraphQL is the most flexible way as you have both a schema that you can work with as well as the ability to connect different entities in a flexible way. You don't need to connect the data in the database such as the way that you do in a relational database with foreign keys or a similar way in DynamoDB. Once you start building the graph in GraphQL using AppSync you will add some indexes to make the resolvers work faster when building the hierarchical objects. Please note that you will be building the actual objects with their values and not only their hierarchy.

If you want to have multi-tenants in the account, the solution depends on the number of tenants. If you have a few large ones or many small ones, the solution should be different.

For a few large ones, you can create a dedicated AppSync API that will have a dedicated schema for each customer. Please note that the schema can be different, however, the data can point to the same DynamoDB tables using slightly different resolvers and GraphQL schema. Such multiple GraphQL schemas give you the maximum flexibility to customize the experience for each customer, as large customers expect.

For many small customers, you can store in DynamoDB the configuration of each customer. The configuration can have various types of data, from the hierarchy they want to graphQL queries they requested. Your application will look up this customer configuration table in DynamyDB, parse it, and use it to generate the specific interface requested by each customer.

Storing/representing a hierarchical tree used for navigation within an Amplify web app and AppSync GraphQL API layer.

Relevant content