Is there interest here?
C, Go, Java, Python, and Ruby have APIs. It surprised me to not see any for Node.
There are unofficial bindings for Node maintained by @josephg
They are high quality, but they are not “official” if that is relevant to you.
Doesn’t look like it has Directory Layer support. Trying to get started with using FDB but it’s slow going.
There’s also some NodeJS bindings from Openland. (But I see you found the Openland chat already.)
Haha yup, but idk how to get my Mongo data into FDB. I’m not used to being super early to a technology.
I’ve been really hoping someone will make a decent pull request adding directory layer support to the node bindings. Lots of people want it, and it would be really useful for a bunch of us. It just requires porting a few hundred lines from python/ruby/callback oriented javascript/etc across to javascript.
I’d also be quite happy if Apple wants to make them official bindings. It’d be nice to hook the node bindings into the standard bindingtester system. (Right now I run those tests by patching the bindingtester through a script). Also apple engineers - if there’s money for FDB development, it might be mutually beneficial to funnel some of that into nodejs. Just sayin’ 
1 Like
Have you made any sample web applications using your module? Or know of anyone else who has?
I have several questions that I feel could be better answered by just looking at a demo app.
That’s a good idea! I don’t know any simple public projects off the top of my head. I’ve been using it with real-time editing in mind, so my code is going to look a bit unusual.
Can you give some examples of things you find confusing about it at the moment?
Querying a database for specific things. One flow I have is to check for an admin user on app boot and if one doesn’t exist, create one.
Currently (in Mongo), I search for { role: "admin" } and I get back a user object.
I’m not sure how to create/delete databases either.
EDIT: Basically, anything a dev who only knows Mongo would normally do.
I see, thanks for sharing!
In foundationdb you don’t create / delete databases - though you would create & open a directory using the directory layer once we have that implemented from javascript.
As for users, you’d do something like this:
await db.doTxn(async txn => {
const adminUser = await txn.get('/users/admin')
if (adminUser == null) txn.set('/users/admin', {...})
})
… but obv, you’d need to think about your data model, since content in foundationdb isn’t automatically searchable in the same way it is with mongodb. (Well, if you aren’t using the record layer).
But yeah, good shout about having a few example projects kicking around. I wonder if anyone would be interested in making stuff like this.
Interesting.
So, there’s no way to query a user via their username, for example?
There is. You could store all users under the key “users/$USERNAME”. But if you do that it’ll be harder to efficiently answer questions like “are any users an admin?”. You can solve that problem by storing a separate list of all the admins (with links back to the users) and by keeping that list up to date as the database changes. Or you could use the record layer to solve this for you.
This is not a nodejs-specific concern. Have a read of the foundationdb data modelling guide for tips on how to do this sort of thing. - Or if you want an easier API, you might want the record layer.
Seems like I should just wait for example projects to gain a better reference on how to interface with data.
Hey again! We are working on releasing our Entity Layer that will allow to do exactly this, but it will take a week for a proper release.
Our (Openland) library have limited support for directories (can create, open and move directories).
We actually have several micro-layers to work with FDB that can be very useful too (distributed locks, migrations, singleton workers, work queues, pubsub). Everyday i am working on releasing this features in a safe to use production way.
You can try to start playing with our libraries to be able to hook entity layer once it will be ready.