One of the mistakes I saw a lot of when Agile was taking off as “the hot-new thing” was people declaring that they didn’t need to do design anymore. Of course there was no big-upfront design - the kind from the waterfall days where people first analyzed and designed a system in full before punting it to the next team to build (which rarely worked out well) but some planning and design is important, even if you’re just creating a small hobby project.
Part of the process should often involve prototyping to help decide or prove which technologies you’re going to use as these will also factor in to the design of the app. It also gives you an opportunity to kick-the-tires of some technologies if they are things you haven’t used much before prior to building too many things around them. Making late-stage switches can be costly.
This isn’t going to be an exhaustive comparison of every possible client-side framework, storage technology or hosting option. Of course I have some technology choices in my head before I even begin based on my current skillset and experience (isn’t it an amazing coincidence that the “best” technology to build any app with is always the one the developer likes to use?!) But I’ll try to go through the reasoning behind some of the choices I came up with.
Firebase is great and makes serverless apps very easy to spin up but there’s always going to be times you need to access the Firebase data and / or user accounts from your server code (e.g. to sync accounts with a legacy system while we move to a Firebase auth enabled client).
There is an Official Admin SDK for Node.js, Java and Python but not all of them support user administration and poor Go doesn’t even get a mention (sad face).
But it turns out, we don’t need an official Firebase SDK for Go to be able to access the database and / or manage user accounts - all the packages to do it are already available and it’s very easy to use.