Private GitHub Issues Have Public Images

By on April 11th, 2018

And you can’t delete uploaded images without contacting support.

  • Go to a private GitHub repository.
  • Create a new issue.
  • In the issue description or a comment, insert an image.
  • Save the description/comment.
  • Now click the image – it will redirect to the raw image URL in your browser.
  • Copy the URL and share it with your friends – it’s public.
  • Now delete the issue or comment with the image.
  • The URL is still public.

I reported this to GitHub support, and while they agree it is probably not optimal, they do not have a plan to change the behavior (as of 4/11/2017).

GitHub documents the behavior here.

Firebase Pros and Cons for a SaaS Company

By on April 6th, 2018

Why Firebase

  • Realtime / streaming updates are pretty easy.
  • Getting a whole app off the ground is fast – auth, email, versioning, hosting, monitoring, devops, uptime.
  • The data structure is JSON which maps perfectly to UI JavaScript.
  • Libraries across programming languages are similar and pretty good.
  • Cheap/free initially.
  • Easy-ish to integrate with analytics and crash monitoring.
  • All you need for the backend of a small mobile app.
  • While schemaless, it has some basic ability to validate data types.
  • It should scale very well with certain kinds of traffic (reads and writes are not on shared objects).
  • Minimal, or no, knowledge of devops/sysadmin is necessary.
  • They now have decent tools to migrate your data out of it.

Why Not Firebase

  • Not a boring established technology.
    • You only get so many innovation tokens.
  • Your entire backend is proprietary (BaaS), owned and run by another company. If they shut down Firebase, you have to rewrite everything on their timeline instead of moving it.
    • This happened with a nearly identical service called Parse.
    • Parse was purchased by Facebook, then shut down. (Google bought Firebase but seems to be investing in it, and its replacement).
    • Google shuts things down all the time.
  • Firebase is somewhat deprecated in favor of Cloud Firestore.
  • Exceptionally expensive at scale compared to REST.
  • Not really possible to expose an API spec (swagger) with cloud functions.
  • Proprietary – complete lock-in:
    • Migrating off means rewriting all backend tests and much backend code. This is more dangerous than “just” rewriting the code and not the tests, because the tests make sure you didn’t mess something up during the migration.
    • Firebase is pretty unique in the way you interact with the APIs and realtime components, making a frontend migration a massive ordeal also.
  • Impossible to develop the app without an internet connection.
  • Security and data validation setup is tricky, and it cannot be unit tested.
    • Security and data validations are strings in a JSON file.
    • Must run security integration tests against a deployed app.
  • Having your main database public is a highly discouraged practice.
    • This may not be fully fair, but it is very easy to misconfigure things and expose data that shouldn’t be.
    • Normally databases are only listen on private interfaces or at least use IP restrictions.
  • You must duplicate any business logic across all systems that interact with firebase.
    • Strong anti-pattern for architecture and maintenance
  • Cloud functions are good for one-off tasks:
    • good for formatting a PDF invoice and sending it
    • good for processing a batch job
    • good for individual tasks delegated by a message bus
    • bad for a bunch of similar data update routes
    • bad for structuring and testing a large REST API
  • Unit testing firebase backend functions is way more complicated than a regular REST API.
  • Querying and aggregating are limited compared to SQL or popular NoSQL databases like MongoDB.
  • Transactions have some odd behavior – they might get “rerun” in the case of conflicts.
  • Database migrations are not supported at all.
    • red flag – basic service development
    • few band aid 3rd party open source solutions exist
    • means hand writing a migration framework that works with unit tests
  • Firebase recommends duplicating data because JOINs are unsupported.
    • red flag – architecture
    • not a problem in other NoSQL databases
    • this is a core competency of relational databases (SQL)
  • Integration with outside APIs and maintaining good testing is not simple like a regular server
    • stripe for example: need to expose backend webhook routes, test them pretty well
  • You are at the mercy of Firebase’s upgrade cycle.
    • If they decide to change or break something and force you to upgrade, you do not have a choice on the timeline, if there is one.
  • Optimized for realtime apps.
    • Only a downside if you don’t have a realtime app.
    • Many of the realtime benefits of Firebase can be had with a plethora of popular open source technologies.
  • Later services you write will likely not be written using firebase.
    • It reduces the surface area of your tech stack to pick a more boring database technology that will scale a long way and can be used for multiple services.
    • If you built your tech stack on say, Node.js or Go, each service would have similar paradigms.
    • With Firebase, now you have all the Firebase paradigms (coding, testing, build and deploying), plus your second service’s paradigms (coding, testing, build and deploying).

All these complaints are probably acceptable when you have a small mobile, a basic website or small ecommerce store, or something that will not grow beyond one server.

Building the core of a SaaS on Firebase, though, is not going to work. There are many blog posts about companies who hit a wall with Firebase, and eventually migrated off it. If you are building a SaaS, the question doesn’t seem to be if you will move off Firebase, but when.