KitchenOS Development Blog: Choosing Dynamo DB

Not having to wake up in the middle of the night to feed a bottle to a baby has given me more time to continue to work on my side projects.  I also realized that now paying full price for a nanny here in New York is getting expensive, so I should be focusing on ways to cut expenses.  One of those ways for me is to actually plan out my breakfasts and lunches and bring them to work instead of spending about $30 a day on food.  Combine these things, and it makes me want to get KitchenOS working even more.

Last night I started to look at what I had and had not done.  Simple answer: I haven't done much.  I have a quick recipe parser done for the Food Network sites.  But of course when I went to use it, they changed their site and I had to update it.  

After that, I needed to persist it somewhere to access it from everywhere else.  Since I don't know the full structure of every recipe I will see, I decided to make sure that I can change the structure if needed and decided to use a document based database, specifically Amazon's DynamoDB versus leveraging a SQL-based database.  The only hiccup I sort of had was understanding the new API for DynamoDB, but it was relatively straightforward even though building the value map seems a little bit verbose.

As an example, here is creating a simple String attribute

itemValues.put("title", AttributeValue.builder().s(title).build());

I know there are some benefits to this, but this seems excessive.  I would have liked to be able to just put a String in here.  But then when I went to needing to add in the ingredient list, it made more sense when I could combine the different builders and get the AttributeValue object which would have been much more difficult without this structure in place.

itemValues.put("ingredients", AttributeValue.builder().l(
                        .map(ingredient -> AttributeValue.builder().s(ingredient.fullText()).build())
Now, all I had to do to push this content to the database was building a simple request and executing it.

The one thing I am still looking at with this is if I have the code structured in the way I want to have it.  Right now, I have a save() method on the Recipe class which allows me to simply call to save this current recipe instead of invoking a whole other data access layer.  But what if I need that in the future?  Though last night I decided that if I needed that in the future I can change.  That is the joy of not having to plan everything out.

Open Question from Last Night

  • How will I structure my shared code across my different modules?  Right now, that is future John's problem.  I can pull things out of the recipe scraper when I need them in a different application.