Deno: wanted: tutorial/demo of using firebase in a server-side deno process

[ry]

The client side firebase code ought to work out-of-the-box on Deno.

If not we should address whatever issues arise.

[lucacasonato]

So I tried to get this working, but its pretty difficult - @firebase/app is no problem as it is on pika.dev.

@firebase/database and @firebase/firestore both are not easily doable because they aren't on pika.dev and I have not found any other easy way to import them.

@firebase/storage is on pika and can be imported, but it requires XMLHttpRequest to do anything useful so it doesn't work either.

@firebase/auth does not make sense in deno as it requires a DOM (or at least window.open). Also it doesn't really make sense server side. Same with these packages: @firebase/analytics, @firebase/preformance and @firebase/remote-config.

The Firebase JS Client SDKs are pretty unusable in deno atm. I don't think they should be the target anyway - it should be firebase-admin because that is the SDK meant for server side applications. The problem with that: it is very node dependent to run - so nothing for now. I am pretty sure it also uses a native module so that will be fun.

While trying this out I also realized that we should focus on having good tooling for all of the major editors (VS Code, vim, sublime, ect.). Currently none of them support the // @deno-types syntax which makes development very cumbersome for packages which ship with TS support, as I usually can't just import .ts files as no packager outputs .ts files and pika.dev only serves js and d.ts files.

[matey-jack]

@ry any idea on how to break this is up into pieces? any specific use-case to try first? One approach I see is to first patch up the libraries so they can be imported and used and then use the learnings from this to either code up some polyfills, propose upstream changes, or some combination of things that results in having Deno-importable @firebase/ libraries published at some URL.

[bershanskiy]

@matey-jack

first patch up the libraries

The proper way to patch up the libraries is just to export them with ES Modules syntax instead of CommonJS require(). This is something the upstream developers would need to do. Another approach is to make a tiny libraries that use the RESTful API provided by Firebase. Also, it's probably possible to make a polyfils that wrap around require() (albeit that would probably defeat all optimizations but into ES Modules).

[matey-jack]

I dived a bit deeper into @firebase/storage. It looks like the entire Firebase SDK is meant to be used on Browsers: not only does it use XHR, but they also offer rollups as ESM module, even a version for ES2017. For NodeJs they seem to recommend the full Google Cloud / Storage SDK, but this thing has a lot of dependencies on other NPM modules... which might be why we want to go for Firebase first.
I could have a closer look at the use-case "deploy a static Browser app to Google Cloud Storage Webhosting" if that would go into the direction intended by @ry ? I also wanted to look into doing the same for AWS S3 (where I am hosting an app) as part of moving my frontend-dev-toolstack to Deno.

[quantuminformation]

This is how I use firebase, albeit in node functions

https://github.com/QuantumInformation/svelte-fullstack-starter

[GideonMax]

the server-side SDK seems to be dependent on Node, but the source code is in typescript and it uses import/export, it shouldn't be that hard to port it over to Deno, though it will probably take some time as it is quite a lot of code.