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
Looks like we'll have a search API exposed soon. I drafted up some Python code to cover a bunch of the use cases. Working on getting the developers here access to the internal docs (it's not released yet, and not announced yet).
Here's the draft of the code if you're interested in exploring...
We'll plan to move the design doc to GitHub once it's been more scoped out. Please feel free to post any feedback you have on the document itself (I've given the public comment access) or here on this issue.
Question: Should we aim to support Cloud Search through the RPC (protobuf) or REST endpoint?
RPC is more complex to implement but using it results in smaller payloads so potential for higher throughput. REST is easier to implement in node.js but results in larger payloads.
That's a good question. For now, I think the answer is "whatever gets us moving fastest". Once we have some usage, we can explore swapping out the lower-level code that does the transport + serialization stuff. Seem reasonable ?
Activity
ryanseys commentedon May 29, 2015
Initial DRAFT Design Doc for
gcloud-nodesupport for Cloud Search available here:https://docs.google.com/document/d/1jblFpy8-St-r2MNwt0IWXVwWdsy0IyQrIC2myvyY3Mk/edit
We'll plan to move the design doc to GitHub once it's been more scoped out. Please feel free to post any feedback you have on the document itself (I've given the public comment access) or here on this issue.
ryanseys commentedon May 29, 2015
Question: Should we aim to support Cloud Search through the RPC (protobuf) or REST endpoint?
RPC is more complex to implement but using it results in smaller payloads so potential for higher throughput. REST is easier to implement in node.js but results in larger payloads.
jgeewax commentedon May 29, 2015
That's a good question. For now, I think the answer is "whatever gets us moving fastest". Once we have some usage, we can explore swapping out the lower-level code that does the transport + serialization stuff. Seem reasonable ?
ryanseys commentedon May 29, 2015
That seems reasonable.
stephenplusplus commentedon May 29, 2015
Seems reasonable.
stephenplusplus commentedon Jun 9, 2015
Search implementation is underway: #648
chore(deps): update dependency jsdoc-fresh to v2 (#632)
chore(deps): update dependency jsdoc-fresh to v2 (#632)
chore(deps): update dependency jsdoc-fresh to v2 (#632)
build: add generated samples to .eslintignore (#632)
chore: release 4.3.2 (#632)
chore: release 4.3.2 (#632)
17 remaining items
chore: retry install go modules in integration test (#632)
build(node): run linkinator against index.html (#1227) (#632)
build(node): run linkinator against index.html (#1227) (#632)
migrate code from googleapis/cloud-profiler-nodejs (#7087)
chore(main): release 4.1.0 (#632)
fix: Reenable staleness bot (#632)
fix: Reenable staleness bot (#632)
fix: Reenable staleness bot (#632)
build: remove verbose logging from cleanup.sh (#632)
build: ignore proto files in test coverage (#632)
docs: clarify in docs, the meaning of ASIA and coldline (googleapis#632)
build(tests): fix coveralls and enable build cop (#632)
build(tests): fix coveralls and enable build cop (#632)
build(tests): fix coveralls and enable build cop (#632)
build(tests): fix coveralls and enable build cop (googleapis#632)