Firebase Go Libraries

[Eddy Reyes]

Hi folks,

If you want to work with Firebase in your Go program and you're looking for a Go binding to help you out, check out the one I've been building and using for my projects: https://github.com/ereyes01/firebase

The Firebase REST third party page lists a project called Go Firebase as one of the solutions for the Go language. However, this library hasn't been maintained in about a year and a half and has some serious unresolved issues. I've taken this library as my starting point, resolved most of its issues, added support for Event Source / SSE streaming, and made it much easier to unit test / mock your code that relies on Firebase, while totally revamping the tests for the library itself.

There's another Go binding called FireGo which is also well done. The library I've made has a couple of differences:

• The ability to automatically get Go native types from REST streams if you provide a parser callback.
• Support for mocking out calls to Firebase in your own tests.
• Configurable HTTP connection pooling, timeouts, and retries via Facebook's httpcontrol library.

FireGo also appears to be a well-maintained and fine solution, though I haven't personally used it in my projects.

Either way, if you consider using the other Go Firebase library listed in Firebase's list of third party REST wrappers, I wanted to let people know about the one I've been maintaining in case they run into any of the outstanding issues with the original library.

Please star if you like my project, and of course, feel free to open issues or send a PR if you find any problems, or need a new feature.

Thanks, Eddy

[Thomas Bouldin]

Hi Eddy,

I'm a long-time fan of Go and I love seeing people make Firebase more approachable in Go. At some point I might get to a 1st party library with caching and all the other subtle things our clients handle for you. I love that your library works well with marshalers too--far too few libraries handle strongly typed models.

Out of curiosity, what are the params in Push/Set/Update/Remove/Rules/SetRules? There are a few cases where I see boolean parameters or nil values. In these cases I personally prefer to use a parameter struct or provide multiple functions. This lets developers omit params that are often unneeded and makes code self-documenting when they're provided.

Like you, my first approaches at the Watch function also used channels. The "Go Way" is to not expose channels (the only library I can think of that violates this is time.Timer), but I struggled to do any better. Your clever EventUnmarshaller gave me an idea though: what if the return type for Watch was an object with a Cancel() function and a json.Decoder (which supports multiple JSON docs)? Then the developer wouldn't need to ever type interface{} and there are no dangling channels. You'd use it like

func DoSomethingSillyWithProfile(profile string, timesToDoSomethingSilly int) error {

  watcher, err := root.Child('profiles').Child(profile).Watch();

  if err != nil {

    return err;

  }

  updatesPublished := 0

  for {

    if updatesPublished > timesToDoSomethingSilly {

      return watcher.Stop()

    }

    var profile Profile

    if err := watcher.Decode(&profile); err != nil {

      return err

    }

    doSomethingSilly(profile)

    updatesPublished++

  }

}

All in all, this is really cool. Thanks for contributing to the community!

--Thomas

[Clement Wehrung]

+1 — by the way, the idea of "on" call returning a promise you can cancel() is something I've been dreaming of for a while on other platforms (web, mobile, ...). I think it's way easier to manage than the current implementation.

[Eddy Reyes]

Hi Thomas,

Thanks for the great feedback!

The params struct takes keys/values that map directly to the query string's "key=value". They are just converted as supplied into the query string, with the exception of "auth", which is autopopulated if you provide an auth token. Using a struct does seem like a much cleaner way to do this, especially since the possible query parameters are quite static, I think.

I had toyed with the idea of the Watch object with the intent of simplifying the error handling as well as hiding the channels. I had abandoned it because it didn't seem to simplify the error handling and the usage as designed with the EventUnmarshaller looked pretty much the same. However, your idea of using the json.Decoder I think is what I was missing to make it look nicer. Next time I'm hacking on this library, I'll try this approach out.

I'll open issues for these 2 suggestions. Thanks again!