# FoundationDB .NET Standard **URL:** \ **Category:** Using FoundationDB\ **Created:** [April 22, 2018, 2:00am UTC](https://forums.foundationdb.org/t/foundationdb-net-standard/193 "2018-04-22T02:00:08Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![KrzysFR](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/krzysfr/32/43_2.png) [@KrzysFR](https://forums.foundationdb.org/u/KrzysFR)\ **Post date:** [April 22, 2018, 2:55pm UTC](https://forums.foundationdb.org/t/foundationdb-net-standard/193/9 "2018-04-22T14:55:47Z")
I think bindings are expected to be the base library that enable other Layers or applications to be build on top of it (for each language). If you need something more complex like a SQL Layer (or Document Layer), either you will have to re-implement it in your favorite language, OR people will need to decide on some REST API or wire protocol so that only one need to be written (in whatever language) and benefit everyone. In that sense, it would be _as if_ PostgreSQL or MongoDB or Redis would use FDB as their internal storage engine, but you as the user wouldn’t know and use the usual client library and existing ecosystem for that db. Specific to .NET, it would be as if you wanted to emulate a RavenDB server (using FDB as the storage engine), but still be able to use their own Client (or at least wire protocol) to connect to the cluster (_not that I’m saying it’s a good idea! 😉_) I think there are some discussions on this subject as well: [Coprocessors or modules](https://forums.foundationdb.org/t/coprocessors-or-modules/183), [SQL layer in FoundationDB](https://forums.foundationdb.org/t/sql-layer-in-foundationdb/94), etc… --- _[View the full topic](https://forums.foundationdb.org/t/foundationdb-net-standard/193)._