5

Like most people, we're pretty impressed with BigQuery. We're willing to put up with it being based on proprietary "Dremel" in exchange for not having to configure a ton of servers in our LAN, on EC2, or anywhere else.

The REST API is excellent, and we're incorporating that into our apps, but we still find ourselves using the BQ Browser interface as well. We'd like to incorporate something like a 'generic SQL window' into our app, without divulging that the backend is BQ or that data is stored in Google at all, for that matter. Does Google provide a way to use their BQ browser tool in a white-label manner?

Note also, that even extending access to the existing browser tool is problematic. It relies on user-accounts existing in one's own domain - something that can't be done, in our case, with a customer's email address. The REST interface solves this with service-level accounts, but that doesn't get you to the SQL window/browser tool.

If the folks at Google are listening (and I know that you are), consider the benefits of white-labeling the browser tool: I think you'd find a lot of software companies integrating it into their suites of products and, then, running circles around any Hadoop/CDH/EMR/Impala/Hive combination.

So, to summarize: How does a software developer import or emulate the BQ browser tool (with all it's autocompletes, query histories, etc..) in their own web-based app?

pmueller
  • 313
  • 2
  • 7

1 Answers1

5

The initial version of the BigQuery web interface was considered just an 'example' UI that anyone could create themselves. It uses only the public BigQuery API to talk to BigQuery.

There are a couple of Google-internal things we've added since then, such as the current design of 'saved queries', and an auth shortcut so that users don't have to explicitly grant permission to the UI to access BigQuery data. But it is still mostly plain-ol-javascript talking to BigQuery via the REST API the same way anybody else does.

The javascript is obfuscated, however, but my understanding is that this is just for compression purposes so that it downloads more quickly.

The SQL highlighting is done by CodeMirror with special configuration for the BigQuery SQL variant.

I'll talk to the other members of the BigQuery team about open-sourcing the javascript code in the Web UI. It may be difficult to do at this point, but it doesn't hurt to have a conversation about it. I'll bring this up with the team and update this thread. The most likely answer will be "We'll think about it", but hopefully we can also think about it and start working on it too :-)

Let me know if that sounds like it would meet your needs. It might not solve the auth problems you mention, since your users likely won't have BigQuery accounts, but you may be able to solve that by proxying oauth2 access tokens.

Jordan Tigani
  • 26,089
  • 4
  • 60
  • 63
  • Thanks Jordan for the thoughtful answer. Yes, it would help our needs. My own vantage point is that of a Software-as-a-Service developer in a particular vertical (telecom), where there's a reluctance to have proprietary data reside in the 'public cloud'. Having said that, working apps tend to trump ideological concerns, and I think you guys have a killer product in BQ.... (I really believe "SQL as a service" will beat managing your own servers - Hive, Redshift, etc.. - over time.) Still, would be nice to extend BQ ad-hoc querying to customer without divulging it's Google-powered. – pmueller Jun 05 '14 at 14:48