Best way to handle Searchable Product Tags

Good afternoon,

I have recently started working with DGraph and I am very pleased! I have recently come across an obstacle with building out my Schema.
I am working with types that have a:
tags: [Tags!]!
property. I set the Tags as ENUM types and there are many of them. The problem I am coming across is that the Tags sometimes have multiple words, for example:

enum Tags {

When using ENUMs I understand that you can’t have spaces, so that’s why I put the underscores. However, when displaying this on the Client-side, we can not have the underscores, we need to have the actual spaces. We can make a formula that removes the underscores and replaces them with a space on the front end, but I want to know if this is the best solution.

Is there a better way to manage these tags in Dgraph? For example, should there be a Tag type that has a property named: productTitle: String! like so:

type Tag {
   id: ID!
   productTitle: String!


This way we can have the spaces be a part of the actual tags:

  1. alcoholic beverages
  2. non-alcoholic beverages
  3. aluminum canning beverage

That way we get better search options than we would if we used the ENUMs (anyofterms, allofterms). I understand this might take up way more memory in the database. Right now I don’t know if it would be substantially different in its memory usage.

For clarity, the product tags are how the frontend users would search and find the entities in the database. They type a product in a search bar and we would search through the database for any nodes that have that Tag in their “tags” property. Then we display a list of all the nodes that have those tags.

Do you have any tips on the best way to have these tags be a part of the Schema and database?

Should I go with ENUMs and deal with the underscores on the frontend?


Should I create a type Tag{ “…”}, and have the product tags live as strings in a product title property?

Any help or tips would be greatly appreciated!

You could make a new type instead of an enum… but there are trade-offs because filtering by child properties is not an easy feat in Dgraph.


Consider that if you go with the second approach, you won’t be able to sort your products and filter on ProductTag because of this issue. I think we might have to do something similar to your first approach since the Dgraph Team just refuses to acknowledge that this issue exists.

1 Like

I think the conversion of the enum on the client side is the correct way to do this. Enums in SDL follow the convention found in most programming languages (no spaces).

…and to further expand upon Anthony and Daniel’s responses, making a single edge type for the simple purpose of string formatting can introduce new problems.

1 Like

I appreciate you guys. Thanks for the quick reply.

I am definitely leaning towards the first approach: handling the conversion client side. I do not want to introduce any new problems :sob:
I am also checking out the Issue that @danielhr shared and I can see that causing trouble later down the line.

The Enums make searching and sorting through the different tags much easier, especially when there are over 300 tags. I’ll stay away from filtering by child properties for now :sweat_smile:

thanks again!!!

Yeah, I will check out this issue some more. This is interesting.

I don’t know why I even thought it would be easier than dealing with the string on the frontend. :sob:

But without a tag type you also don’t have a good way to programatically add new tags or rename tags without then modifying the schema.

1 Like

300+ tags: sounds less like an enum and more like a regular attribute. If I ever came across an enum set in code that was over 300 entries long, I’d probably raise an eyebrow.


I agree should be a type not an enum… but… then Dgraph is just a pile of :poop: when trying to filter/sort/paginate in regards to these tags when nested. I’ve been there; done that; and flopped.


I understand what you’re saying, but it’s important for our product that we can filter/sort/paginate these tags. Should I look elsewhere for a solution? (Neo4js or another graph database)

So the Tags will rarely get changed or renamed when the app is launched. But you raise a good question. Because we do want to add tags as the network grows. So, this brings me right back to the original question :sob:

So pretty much I have to choose my poison OR go to a new Graph database solution.

At this time. Yes. Dgraph it’s not the answer for everything, but the same is true for other products and services as well that fail in other areas. There are always pro/cons

1 Like

@thelovesmith For the version of dgraph current running, this is a problem. If you can wait a bit for that version to be updated, or plan to run your own cluster, then your requirement of filter/sort/etc on ‘embedded types’ can be accomplished.

1 Like