There are some side projects that I have tried to work on in only twenty minutes at a time. This is an interesting constraint because software is notoriously time-consuming. The result is interesting too. I spend a lot of time distilling my next step down into something that is 1) an improvement and 2) complete.
Today, I’ll be deploying one such app to Firebase. This is my first blog post on this project, so I’ll catch you up real quick.
I have an app that I’m calling “TaskJournal” because it’s a journal for tasks and I’m about as good at naming things as Microsoft. The idea is that you can create tasks inline with a journal. This is how I do things on paper. It helps me clear my head and get things organized.
“Hmm. It’s a word processor. You type a lot of words in it. Let’s call it… Word.”
Bill Gates (1990), probably
So far, the development has been going well. It’s an interesting OOP experiment because I have to manage an Array of Totally Different Things (“ATDT” – tasks and paragraphs) and make them play well together.
Previous twenty-minute sprints have added the ability to serialize and deserialize the ATDT in anticipation of saving it to… something. Probably a REST API. But currently just a local JSON file.
But where would the actual data live? And what would get it there? I could whip up a Docker container with Node and Mongo. Heck, I could whip up a Docker container with ASP.NET Core and SQL Server. But then I have to deploy it, and I don’t think anything gets done in twenty minutes on Amazon Web Services. SeCuRiTy.
Another consideration is cost. I don’t think this is going to be a huge blockbuster. It’s a side project for my personal use. This is really sounding tailor-made for Firebase.
What is Firebase?
Up to about a year ago, I had never heard of Firebase. Basically, Google gives you a “free” serverless infrastructure complete with authentication, hosting, and database services. I say “free” in scare quotes because 1) it’s only free within some (generous) limits 2) if you want to do anything without outside APIs, they will make you put in a credit card, 3) you can find horror stories of people who accidentally churned up way too much usage and got huge bills, and 4) Google is an evil company premised on spying on you and controlling the flow of information and there’s probably some hidden cost to your immortal soul for dealing with them.
But once you’ve come to terms with all of that, you’re all set to get started!
Back to my existing app. It’s a silly little thing written in Typescript and React. I bootstrapped it with create-react-app and just started coding. Just looking at this project I realize… I have no idea where the generated .js files live.
Wait. What am I going to deploy?
My project just contains my Typescript files. If I run npm start, then create-react-app will do some kind of magic behind-the-scenes build and serve up my compiled site. But I don’t see those files anywhere. Those are the files I need to deploy.
One does not simply serve Typescript files to the browser.
Me, 2019
Guess it’s time to eject. When create-react-app first creates your project, it tells you that you have the option to “eject” with npm run eject. This will jettison all the handy bootstrapping tools and leave you with some scripts and a plain old web project. Since I’m ready to send this into production, that seems like the thing to do.
When you run npm run eject, they warn you that you might not have to do it and that’s it’s irreversible (that’s not true if you’re using source control like you should, but OK). After reading about it for a minute on the link that the command provides and a quick bit of Googling, I changed my mind. create-react-app can stay. For now.
Instead, I ran npm run build and got a nice, neat production build in my ./build folder. Great. Let’s test that out.
Serving Up My Build with the Live Server Exension
I’m writing in Visual Studio Code. There’s a cool extension called “Live Server” that will let you right-click on a file and serve it up from a local web server. I’ll try it on my new build.
Right-click. “Open with Live Server.” *BZZT* Nope. It can’t find any of the files associated with my new index.html. The reason is that it’s looking for absolute paths and I’m just operating out of a build directory. Live Server, by default, is using my workspace root as the document root of the server.
So now I’m in the Live Server documentation. I find a setting to change the root. I change mine (Code > Preferences > Extensions > Live Server) to “/build” and try again.
*BZZT* Still no. Now it just says “cannot find index.html” So what is going on? I delete everything off the URL and get a directory listing. It’s my root workspace directory. Apparently the file-reading part of the Live Server didn’t get the message on the configuration change.
Right-click. Stop Live Server. Right-click. “Open with Live Server.”
Success!
Well, sort of. I never made it to deploying with Firebase. And I’m sure I’m well over twenty minutes. Software, amirite? Next time.