Hi all, I’ve recently been through the exercise of developing and deploying some game leaderboards using the record layer, which have now seem some use, and I can reasonably say they work. This actually uses the TimeWindowLeaderboards (which I appreciate are marked experimental). The purpose was to learn about this (fdb + record layer) before using it for anything more serious.
A few things came up which made me wonder if I’m doing it right.
Firstly, the architecture is that there is a golang edge server, a Java server (which has the fdb client) then the fdb cluster. The Java piece is a grpc server for interfacing with the go, which is the only part publicly reachable. That grpc server is written to use async style patterns. Is anyone actually deploying code using the synchronous methods in the Record Layer? All the examples I saw seemed to do so, yet my assumption (and it is only that) is that async would be preferable. A consequence of this is I made it to about one day before going live before noticing I had copy/pasted the example recordStoreProvider function and it was blocking! Assuming async is preferable is there an even trivial example of production style Record Layer code?
From that, this Java code has the oddest performance characteristics I’ve ever seen, with a ridiculously long warm up time. (Hours). I have been tempted to use another key space on the prod fdb cluster to exercise all the grpc methods on startup. Is there a more proper approach? (I appreciate this may not be a pure fdb question, but did wonder if there is something specific going on).
Right now all of my transactions occur within a single record store (per environment test/dev/prod etc.) but I am assuming that transactions across record stores are allowable without nasty side effects? (Within usual limits for space and time) If you try to use multi tenancy is that impacted?
I was slightly surprised by managing to make UUIDs work in records so easily (meaning com.apple.foundationdb.record.UUID fields convert silently to a java uuid in tuples when they’re indexed). This is obviously welcome behaviour, but I did not see it documented.
A more general observation is I found reading the unit tests to be surprisingly educational, particularly with respect to learning how to write keyexpressions for secondary indexes. I wish I had been kicked that way earlier.
I am absolutely willing to make PRs against the client repo to address, for example, the UUID documentation, however, I just want to make sure I’m not missing something.
Thanks a lot!