August 2018

There were 5 posts published in August 2018 (this is page 2 of 2).

Making MealMind #3: Proof of Concept

I’ve been working on a proof of concept version of MealMind that I can use myself while I build the “real” version. It’s not really meant to do anything other than let me test out the general features/flow before I have to build out a more polished version with a more traditional architecture.

In this case, I’m still using Angular and ASP.NET Core, but it’s all super quick & dirty. The web UI is terrible, but it lets me get a better feel for what is and isn’t needed much better than a paper prototype or even a higher fidelity design mockup. I realize this approach wouldn’t work for everyone, but it’s faster for me to actually do my rough initial design with “real” code. I think the craziest thing in this proof of concept is that all of the data is stored in a handful of JSON files – no traditional database at all. It makes it surprisingly painless to save & load data, but it certainly isn’t something I’d ever do in a multi-user application. Skipping the database for this test version was definitely the right choice though. I’ve been able to skip so much plumbing code and get right to testing out the general features/flow.

I’ve put maybe 30 hours into the proof of concept at this point. It’s more or less usable for what I need, so I’ll transition to just using it for a few weeks. I may put a couple more hours in here and there if there is another feature I want to test, but I think it’s nearly “done”. I expect to start building some of the “real” app out while I’m testing (things like login, registration, setting up the base project files and tests, etc). I did think about opening it up for a few people to check out as-is, but I think it’s a bit too rough for that. I could clean it up, but I’d rather start the public product with a better technical foundation.

Overall, I’m really happy with this proof of concept. Even though I’ve just started using it, I’ve already found a couple of items that I should address when I rebuild it.

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.

  1. SQL Server—Pricing and Licensing | Microsoft ↩