in MealMind

Making MealMind #2: The Tech Stack

When it comes to building the actual bits behind MealMind, I’ve been experimenting with a few options and think I’ve settled on my initial tech stack. For now, I’m only focused on the web UI and backend API. No mobile apps. For a 1.0 launch, I think a mobile app is a critical requirement, but for the initial MVP to get some early access users providing feedback, I don’t think it’s where I should spend too much time.

Web API

ASP.NET Core with C#

This isn’t a sexy choice since most people associate .NET with enterprise type apps, but the reality is, it’s a fantastic language for startups as well if you already have experience with C#, not because it’s a bad framework or language, but because it’s easier to me to get started with something else like Node + Express, Ruby on Rails, or Python + Flask if you already know any of those. For me, I’ve been doing .NET for a long time, so it’s probably the one framework that I’ll have the least friction using for this product.

Web UI

Angular 6

This one may change as I get into it. I like Angular. I’ve worked with Angular since v1 and I’ve seen plenty of the benefits of using it. That said, this UI isn’t incredibly complex, isn’t (today) going to have tons of developers working on it, and the app itself just isn’t that large. I’m going to start with Angular 6 because that’s the framework I know the best today, but don’t be surprised if this changes to React (less likely) our Vue (more likely) as time goes on. Maybe it’ll even end up being Blazor eventually depending on how that project progresses. Today though, I can get the most value out of using Angular since it’s what I know.

Server

Linode VPS w/ Linux + Nginx

Which distribution? Probably Ubuntu for now, but that’s again because I’m familiar with it. I know it’s not the best choice for a server, but it’ll definitely be great for getting things online initially.

Why not Windows? Cloud? Containers? Cost, cost, and headache in that order. I can get plenty of performance out of cheap $5-$10/mo Linux machines at Linode and I’ve used them for years. I love Azure and AWS, but I’m nowhere near ready to take advantage of enough of their services that the cost-benefit analysis would work out. I don’t think I’d get enough benefits out of containers at this point to justify the headache of working with them. I have nothing against the technology itself, but I don’t feel like many of the benefits are going to help me get this into customer’s hands any faster today.

To be honest, if I could spin up the initial service with Azure’s “app service” using a custom domain name + SSL certificate for $20 or less per month, I probably would. Unfortunately, you can’t use SSL certificates until you’re on the $55/mo service level (and that’s for machine resources that are $10/mo at Linode). I’d pay a premium for some of the infrastructure management Azure does behind the scenes, but it’s not worth that much to me at this point in the product’s lifecycle. Yes, I could get a VM cheaper than that on Azure, but I can get more performance in a VM with Linode. I haven’t had a great experience with the lowest end Azure VMs either – they are incredibly slow.

Database

PostgreSQL

Why not SQL Server? Honestly, it’s the cost down the line. Yes, I can use the Express version which would make SQL Server essentially free for quite a long time, however, it’s still much cheaper to get up and running on Linux vs Windows. SQL Server 2017 does have a Linux version, but SQL Server’s licensing costs as you scale get crazy. As soon as you want to go over 10GB of storage, the price goes from free to over $7K ($3717 per core, minimum 2 core purchase1). That’s not a problem I’ll have to worry about for a long, long time, but I’ve seen enough people burned by that pricing that I’d like to avoid it.

This is probably the only area where I don’t have that much experience. I’ve worked with PostgreSQL for a couple of smaller experiments, but I’ve never really worked with it for a full app. I’ve been using SQL Server forever. I’m not worried about PostgreSQL having the features I need, but it’ll definitely be a learning curve for me. In particular, the management tools don’t feel as “nice” to me as SQL Management Studio, but I’m pretty sure that’s simply because I’m not super familiar with them. I’m going to stick to the latest pgAdmin for now as well as learn the command line way of doing things. The good news is plenty of the basic SQL syntax is the same between SQL Server and Postgres, so it’s not exactly starting from nothing.

Boring Right?

I know none of these choices are exciting. At this point though, my focus is on getting something into customers’ hands so I can start getting feedback. The technology really isn’t that important. Whatever lets me move fast is the best. If this takes off and needs to scale to tons and tons of users, will this stack stay the same? No, of course not. It may evolve to be totally different.

Today, I’m focused on solving my problem. Then other customers’ problems. When/if those problems bleed over into a technology problem, then and only then, will these choices get bumped up the priority list enough that a different choice might make sense.

It’s worth noting that all of this may change at any time. This is what I’m starting with. If it starts creating too much friction for me, then I’ll switch to something else. Today, getting started on something is the most important thing I can do.