You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using this issue to try and get the BigTable API rolling, I started a rough draft and received some great initial feedback from @stephenplusplus, now I'm hoping to pull in more thoughts/criticisms/etc.
Ideally, it'd be super nice if we could use one of the existing libraries and swap out the transport layer. For example, in Python, we're trying to make it be something like:
fromgcloud.bigtableimporthappybase
which would then act like the happybase library but send requests to Cloud Bigtable.
If we could do similarly with Node, that'd be really cool. Take a look at #707 also
Going to throw this out here to avoid spamming everyone in #707. It doesn't really seem like hbase is very popular in the node world (some one correct me if that's wrong), however the BigTable variant LevelDB seems fairly popular.
There's a LevelDB node library called levelup that allows you to easily swap out transport layers and even offers an abstract class to help create your own. While BigTable and LevelDB aren't really 1:1, I feel like this might be something worth looking into.
edit: for stuff like zones/clusters/table admin we could require gcloud-node-bigtable directly and offer APIs specifically for that - this would be nice for helping us manage the different clients as well.
have our own Bigtable API that people can use if they are new to
Bigtable/hbase
provide adapters for gcloud node so that people who use existing hbase
libraries can change an import and some config, and their existing code
will work (for example, in Java, we just have a separate jar you pull in
for Bigtable, but the api methods in code are the same)
Not sure how popular leveldb is and if we will be attracting the right
userbase with it, but worth exploring.
...and if we will be attracting the right userbase with [leveldb], but worth exploring.
I don't know about this, but it will at least be an API Node devs could have used before.
Now that grpc can be installed with only Node dependencies, we shouldn't have to spawn this Bigtable stuff off into a separate module. @callmehiphop with your plan, will our library wrap level_(up|down)_ and provide a complete solution for doing lookups, puts, etc? Or do we just offer an adapter that can be plugged into level_(up|down)_ which the user has to manually install?
@callmehiphop with your plan, will our library wrap level(up|down) and provide a complete solution for doing lookups, puts, etc? Or do we just offer an adapter that can be plugged into level(up|down) which the user has to manually install?
I think we'd want to just offer the adapter and allow the user to install levelup on their own, that looks to be the levelup way of doing things.
Activity
jgeewax commentedon Jul 15, 2015
Ideally, it'd be super nice if we could use one of the existing libraries and swap out the transport layer. For example, in Python, we're trying to make it be something like:
which would then act like the happybase library but send requests to Cloud Bigtable.
If we could do similarly with Node, that'd be really cool. Take a look at #707 also
callmehiphop commentedon Aug 6, 2015
Going to throw this out here to avoid spamming everyone in #707. It doesn't really seem like hbase is very popular in the node world (some one correct me if that's wrong), however the BigTable variant LevelDB seems fairly popular.
There's a LevelDB node library called levelup that allows you to easily swap out transport layers and even offers an abstract class to help create your own. While BigTable and LevelDB aren't really 1:1, I feel like this might be something worth looking into.
Code could maybe look something like..
Thoughts..?
edit: for stuff like zones/clusters/table admin we could require
gcloud-node-bigtabledirectly and offer APIs specifically for that - this would be nice for helping us manage the different clients as well.jgeewax commentedon Aug 9, 2015
@maxluebbe
The goal here would be....
have our own Bigtable API that people can use if they are new to
Bigtable/hbase
provide adapters for gcloud node so that people who use existing hbase
libraries can change an import and some config, and their existing code
will work (for example, in Java, we just have a separate jar you pull in
for Bigtable, but the api methods in code are the same)
Not sure how popular leveldb is and if we will be attracting the right
userbase with it, but worth exploring.
stephenplusplus commentedon Jan 4, 2016
I think @callmehiphop's idea is 👌. Our alternative is hacking over the pre-stable, CoffeeScript lib https://github.com/falsecz/hbase-rpc-client.
Let's let npm stats do the talking:
Downloads in the last week:
hbase-rpc-client
levelup
I don't know about this, but it will at least be an API Node devs could have used before.
Now that grpc can be installed with only Node dependencies, we shouldn't have to spawn this Bigtable stuff off into a separate module. @callmehiphop with your plan, will our library wrap level_(up|down)_ and provide a complete solution for doing lookups, puts, etc? Or do we just offer an adapter that can be plugged into level_(up|down)_ which the user has to manually install?
callmehiphop commentedon Jan 4, 2016
I think we'd want to just offer the adapter and allow the user to install levelup on their own, that looks to be the levelup way of doing things.
stephenplusplus commentedon Jan 4, 2016
Should we offer something that's complete, or nbd?
callmehiphop commentedon Jan 4, 2016
I'd think it's nbd, but that's just me. What are your feelings on it?
stephenplusplus commentedon Apr 15, 2016
We're trashing this idea and just going with our own API, right?
chore(deps): update dependency linkinator to v4 (#722)
chore(deps): update dependency linkinator to v4 (#722)
fix(build): set default branch to main (#722)
feat: added support for regionalization for document API (#722)
11 remaining items
build: track flaky tests for "nightly", add new secrets for tagging (#…
fix(deps): update dependency delay to v5 (#722)
fix(deps): update dependency delay to v5 (#722)
chore(main): release 5.1.1 (#722)
chore(main): release 5.1.1 (#722)
migrate code from googleapis/cloud-profiler-nodejs (#7087)
build: track flaky tests for "nightly", add new secrets for tagging (#…
build: track flaky tests for "nightly", add new secrets for tagging (#…
build: add Node 12 remove Node 11 (#722)
build: add configuration for automated doc deployment (#722)
chore: release 4.3.0 (#722)
fix: use process versions object for client header (#722)
feat: add optional projectId override in service object (#722)
chore(deps-dev): bump tmp from 0.2.3 to 0.2.4 (#722)
build: add configuration for automated doc deployment (googleapis#722)