Decimal numbers in Optimizely Graph

When working with a commerce website, having a price concept is a must-have. There is no commerce without the price. In the world of .Net, the price or rather the amount of price is represented by the type of decimal. This is also how it is done in Optimizely Commerce. Decimal numbers can be seen everywhere in the catalog content types.

Hence, it’s completely natural to assume that we also should use decimal type when exposing commerce content through Optimizely Graph. But when actually doing it one can be unpleasantly surprised.

This is exactly the case I was facing recently. After pushing decimal numbers to the Graph, what by the way was done without any problem, it happened after trying to fetch the data. The response to the GraphQL query showed an error:

"message": "Float cannot represent non numeric value: { Scale: 9 }"

This was completely strange. After hours of investigation, I finally found a reason. It appears that Optimizely Graph before sending data to the GraphQL server and before serialization is changing data by deconstructing properties into a dictionary - unless the type is primitive. Since decimal is not a primitive type and contains one property named “Scale”, it was deconstructed into the dictionary with one entry, hence the error.

But the site still needs to work. What are the alternatives?

Alternative number one:

Convert decimals into double types. This is how Optimizely does it in its Graph properties. It might be okay, but there will always be a question of whether there is no problem with precision that might be hard to find in the software's future cycle.

Alternative number two:

Return the decimal number as a string. This approach is good for showing data, but it might not be efficient enough when the same property must be used as a facet or sort order factor.

And finally, number three:

Use a concept of Financial Integers. It’s about multiplying the decimal number by a hundred and storing the result as integer type. For example, $10 becomes 1000, and $20.25 converts into 2025. This way we can have all the filtering/sorting done with numbers. The frontend application, however, needs to remember that this integer number must be converted into a decimal substitute in FE technology by dividing it by a hundred before showing it to the end user.

Which one is the best option? As always, it depends on the actual use case. I’m pretty sure though, that one day, support for decimals will be part of Optimizely Graph.