Making MealMind #7: Still Holding

I’ve got several other projects I’m working on at the moment, so I still haven’t made any new progress on MealMind. I’m still toying around with some things like AWS Lambda as well as working on some totally unrelated projects. I think I’ll make some new progress on MealMind next week, but it depends on how the other projects go.

I have been thinking about the UX for MealMind though. I’m not at the point that I’m doing mockups or building out the “real” UI yet, but I’ve been thinking more about how it should work compared to the proof of concept app I have now. I’m considering taking a month or so to try working through some design books to see if I can up my UI/UX skills a bit, but I don’t know if that will be enough to make a difference. I’d love to have a real designer and UX expert to work with on this, but I think that’s a post-launch (and post-profit) thing. I expect I’ll try to find a decent HTML template that already exists and try to adapt it a bit for the initial version. I definitely like Bootstrap + some customized themes on top. It’s not perfect, but at least it helps to get things off the ground quickly.

We’ll see what happens this week, but hopefully, I’ll have something more interesting to share next week.

Making MealMind #6: Holding Pattern

Not a lot has happened in the MealMind world this past week. I’m still using the proof of concept to prepare my grocery shopping list and it’s still working great. I haven’t made any updates, but I have a little list of items to knock out. I’ve been playing with AWS Lambdas using C# with .NET Core 2.1. It actually works really great, so I’m thinking through whether I want to actually build each API call as a Lambda and then wire up an API Gateway in front of it to make it feel RESTful.

Lambdas aren’t anything magical, but I do like the idea of building very focused little functions. Additionally, for a small developer, it should be possible to host the service very cheaply with lambdas since you only pay for the actual time the code is running. It also makes it easy to automatically scale up individual parts of the app as needed. At the moment, there isn’t really a technical reason to do anything other than a normal ASP.NET API, but in theory, a set of lambdas would be more future proof and wouldn’t cost much. The huge downside is managing the deployment of a suite of lambdas. If I have, say, 50 different lambdas, it would be a bit of a bear to publish all of them vs deploying just a single ASP.NET API website.

At this point, I think I’ll just take a couple of weeks to experiment with a couple of different things while tweaking the proof of concept a bit. I don’t want to be stuck in an analysis phase forever, but I’m learning more and more with my proof of concept so waiting a little longer to build the “real” thing won’t hurt. I also want to make sure I build on a foundation that I won’t regret 6 months from now.

Making MealMind #5: Sync Thoughts

I’ve been thinking a lot about how to synchronize data between the MealMind server and clients. The proof of concept app I have is a web app and there isn’t any persistent state once you navigate away from the app. For the “real” version, I feel like it has to be a mobile app. For shopping, I’d rather have the shopping list on my iPhone and for planning, it’d be easier to actually drag and drop on an iPad. Some people may prefer a web interface, so it’ll likely exist as well, but I think this is definitely a good case for a “mobile first” approach to getting the thing launched.

I wouldn’t mind making it a progressive web app (PWA) since that would certainly solve the issue of needing to build for iOS AND Android, but I’m not really convinced that PWAs are ready for prime time when you’re talking about an app like this. I can definitely see the app being used on multiple devices for the same account. I don’t know if people will use the app simultaneously though. Would a couple each open the app on their devices, sign in, and start meal planning together? Or would one person make the plan and the other may view it, but only one is really making changes. Same for the shopping list – if a couple goes shopping, will they split up and each mark things off the list or will one manage the list and the other focus on getting the item in the cart? Those sound like small differences, but it changes how the API has to work.

In the scenario where only one person is really making the changes at any given time, a “normal” REST-style API would work just fine. You don’t have to worry about multiple conflicting changes coming in at the same time since only one device is making the changes. That’s not to say it’s impossible to cause trouble – it’s still possible, but you can handle it by letting the server decide which change to keep (last one in, etc).

If, on the other hand, multiple devices can make changes at the same time to the same items, then you really have to think about keeping deltas for every change. For example, if a couple is entering recipes and one person is adding the ingredients and another person sees a typo in the recipe description, you would (responsibly so) expect the final recipe to have the correct description AND the correct list of ingredients. If you don’t track deltas for each piece of data that can change, you might end up either throwing away some of the ingredients or throwing away the typo correction.

The bad thing about all of this is syncing is really hard. I personally haven’t had to build out a true synchronization system, so I’ve been reading up on it. I’ve always been aware it’s one of those things that sounds easy but is incredibly hard. I’ve also heard (and can see how) it’s not something you can really do generically – so there isn’t an off the shelf sync solution you can just plugin in. That said, I’ve found Brent Simmons Vesper Sync Diaries to be incredibly enlightening. Brent has a handful of posts describing his thoughts as he worked out the sync process for the Vesper iOS app. It’s not the same data I would need to sync with MealMind, but many of the considerations & gotchas still apply.

At this point, I’m torn on how to proceed. On one hand, I kinda want to build out a shopping list app that uses a real sync so multiple devices can work with the data at once. I feel like the shopping list is the main place this scenario would happen so it would make sense to try to solve the hard problem first.

On the other hand, I’m tempted to start building out the app as a web app, almost like the proof of concept app, just so I can get it running and in the hands of other people. If I do that, it’ll be harder to later come back an integrate syncing though because you need pretty specific data structures to keep up with this stuff.

I think I’m going to stick with the web app initially and not deal with the real sync support initially. If I go down the mobile app + sync route right now, it’ll be months before I have anything to show. If I go the web app route, I can have something running in just a couple of months at most.