How Did We Design File Converter?
I'll be honest with you. I'm not a great designer by any stretch of the imagination. I'm an engineer through and through.
What's funny is that if you look at a lot of engineer's pages, you'll find their design sucks too. Here's two examples: Dan Luu and Peter Norvig. Peter Norvig in particular has some high pedigree. He was a professor at MIT and was Director of AI Research at Google. But anyway, we're getting off track here. Back to the post.
For a long time a lot of my projects sucked in design because I didn't know "how to design properly". I was just too damn lazy with styling. And Bootstrap? That's like this monolithic thing. Such a pain to download that and learn it all.
Then one day I discovered no-class CSS. That was really insane. What was so insane about no-class CSS is that you didn't need to use any classes to make your pages look passably OK. It was so simple to use. You just needed to learn HTML.
So you can see how I fell in love with no-class CSS. It was perfect for what I wanted to build, where my focus was on building insanely cool things and not insanely beautiful things.
Ah I'm too lazy to link to the no-class CSS stuff but there's a whole bunch of them out there. Google for "no-class CSS".
How did We Build The Core Functionality of File Converter?
I knew I wanted to build a service that can convert between video and image files. I wanted to build a big service.
The interesting thing about WebAssembly is that that only got stable in the last couple years, 2017 I believe. So I thought there was a lot of opportunity here to bring C++ apps to the web. Online file conversion services looked like a good target.
The other consideration was asm.js. That is the other C++/C to JS possibility. However it is nowhere near as good as WebAssembly. WebAssembly has performance characteristics of a JVM, while asm.js is still just interpreted JS (albeit very condensed and very fast).
Generally speaking, WebAssembly performs far quicker than asm.js. It does this because WebAssembly is literally an entirely different runtime environment. The browser runs WebAssembly apps in a sandboxed VM. It's basically like a Java VM if you know what that is.
To get WebAssembly working, it's literally just adding a compiler target to g++ or gcc. Once I got that working, a *.wasm file was outputted and I wrapped that in a JS file and Web Worker so that the long-running file conversion process doesn't block the UI thread.
How did we run File Converter without any backend?
The primary problem is logging, since we need to know when and where bugs are. We need to know what people are trying and where they're running into trouble. The main web app is already done using WebAssembly (problem solved).
To log events, we used Google Analytics API. I didn't know about this before doing this contract with some Google engineer. Apparently you can log custom events in Google Analytics like when they click a button, or in my case, when they upload a file. That certainly takes care of the logging problem.
Then we just stuck a CNAME ALIAS on the domain that pointed to the CDN, and served everything off the CDN.
What are the benefits of running File Converter without any backend?
There's quite a lot. First benefit is that it's automatically scalable. Since everything is just hosted off a CDN, I don't have to worry about scaling to 1 million users. It's the exact same setup for 10 users as it is for 100 users. It is very nontrivial to scale to 1 million users. You have to deal with stuff like Load Balancers, an Elastic IP, giving the load to several VMs...
Second big benefit is security. Since a potential attacker doesn't know the IP of the original server (all content is served off the CDN. At no point can anybody figure out the originating IP), it is impossible to DDOS the server or to hack into it.
The only drawback is it is a little harder to set this up. You have to learn how to serve everything off a CNAME alias. Then you have to learn how to automate CDN invalidations and Google indexing.
Automations at File Converter
There are a couple big automation wins I'd like to touch on because I'm pretty sure almostnobody is doing this. Even though it's not even that hard.
The first big automation win is invalidating CDN pages every time we want to push a new update. I didn't do this for a couple weeks because I thought digging into the AWS Cloudfront documentation would be too much work. Later I looked into it and turns out it was just 10 lines of Python. The primary package you want to google for is import boto. The invalidation call is one line of python. I leave this as an exercise to the reader.
The second big automation win is automatic invalidation of Google Search Console to update the page on a new update. This is about 40-50 lines of NodeJS. They have a good tutorial. You can follow it here: https://developers.google.com/search/apis/indexing-api/v3/quickstart
Would you like me to set up this automation for you and your team? Drop me an email at contact@fileconverter.digital and I can do it for a flat fee of $500.
How Did We Test File Converter?
I learned from a previous contract of mine with some high-up Google engineer how important it is to test things. "It obviously looks correct" is not good enough. It is so easy for software projects to break. Software projects are so fragile. It only takes one thing...
In that contract, he tested the crap out of his app. He had test cases for everything. My project is a lot more simple for the time being. It doesn't justify that kind of engineering level...yet.
At a minimum, I needed test files of each file type I was going to support. I found these by googling for "