Reckoner's Tech Stack

If your thinking of building a piece of software for yourself, congratulations, best of luck, and try not to over engineer it. With that said, I thought I’d take a little bit of time to talk about how I came to develop my tech stack for Reckoner.

What I Knew Beforehand

People don’t choose the technology they use in isolation. They are highly influenced by the technology they used in the past. I’ve had a quite unusual history for a software developer. Primarily that stems from the fact that I went to college for Electrical Engineering. I did flirt with Computer Engineering or Computer Science minor, but dropped that as I didn’t like the professors. Up till I had graduated college the most I had done programming wise was some scripting and a few toy programs in Basic or C++.

In my first job, I joined a government contracting organization. They had a fledging simulation department which I was quickly snapped up as part of. In there I was exposed to quite a bit of FORTRAN as a lot of simulation code was still written in it. At the time it was sill the fastest language for doing matrix operations. However, I was also exposed to some C++ simulation code and wrote some integration code in C++.

My next job was actually a bigger step backward in technology stack (and that’s saying a lot with FORTRAN). It was health IT where they were using Visual Basic (v6.0 not .NET) and M/MUMPS. This was largely because they had a large amount of legacy code. I did that for a long time and eventually did a little bit of C# for some server only data interoperation.

While the money at that job was good, I did end up burned out by the workload of the job. Searching for another job was awkward though as I had a lot of IT experience in technologies few people cared about. Taking a moment for a ranting aside, software technology interviews at most companies suck. Most of them ask you to solve largely academic problems like reimplementing sorting algorithms or array/string manipulations. I hate doing problems for the sake of doing problems, so I’ve never been great at these questions.

Anyway, I eventually got a new job doing a variety of work in C# and SQL for on-premises services and Node.js in AWS later. In the next two jobs (including my current one), I have been using Python to program AWS Lambda serverless functions along with other cloud infrastructure.

Reckoner’s Stack

As you can see, I had a lot of backend coding experience with relatively little on the frontend. What experience I did have with frontend development was with a deprecated language (VB 6.0). So how did I decide to use Flutter for Reckoner?

I actually initially was building this as a Python application. I was evaluating Django as a possible candidate, but at the time was enamored with Flask and created a simple synchronization CRUD service. However, this was putting the cart before the horse and I still had not settled on what to use for the frontend application. I was actually in the process of ruling out Django and other strongly coupled web frameworks as it is very difficult to program them with zero knowledge. To do so, you basically need to download the entire database to each device. Thus I looked into solutions which focused on a standalone client experience.

I did investigate using some of the standard cross-platform development tools; namely Javascript (React Native and Electron), C#/.Net (Xamarin), and Dart (Flutter). Xamarin was ruled out due to the fact that it doesn’t support Linux or look like it planned to do so. Thus between JS and Dart (the programming language for Flutter), I chose Flutter. The biggest decider was the fact that Flutter applications are more performant than JS counter parts on number crunching (source). That and I do prefer static strongly typed languages over dynamic weakly typed.

Having a standalone frontend application means that I don’t strictly need a backend application. With that said, I always planned to have a backend service to do client syncing and creating cloud functions to download data from financial aggregators. With the first planned release for Reckoner, I plan to allow for self-hosted sync using the Pocketbase BaaS. The future plan is to utilize either Supabase or Appwrite as the cloud host BaaS to handle a turnkey cloud synchronization service and the financial aggregator support. And then there’s finding the best financial aggregator to use for a privacy focused application.