6 ms·
As far as possible, I'm following a local-first methodology for a recipe search, meal planner, and shopping list application: https://www.reciperadar.com https
by jka 7y ago
As far as possible, I'm following a local-first methodology for a recipe search, meal planner, and shopping list application:
https://www.reciperadar.com https://www.reciperadar.com
There's a 'collaboration' mode which allows peer-to-peer sharing of a session via CRDTs over IPFS. My partner and I select our meals for the week, and then when one of us is doing the shopping, we can mark ingredients as found -- the other person's view reflects those updates in near-real-time.
If either of us lose connectivity, we can continue to use the app, and when data access is restored, those changes are synced with the shared session (with automatic conflict resolution). All data in the shared session is encrypted, and the collaboration link contains the keys.
Much of this functionality is thanks to peer-base, which is an experimental but extremely useful library:
https://github.com/peer-base/peer-base https://github.com/peer-base/peer-base
A side-benefit of this approach is that all user data can be stored locally (in browser localStorage) - there are no cookies used in communication between the app and server.
- jimpick 7y ago(peer-base maintainer here) This is really cool! I found the share link, and just tried it between two Chrome browsers, and it worked great! Thanks for using peer-base! There's a lot of great work happening with js-libp2p recently that would be awesome to incorporate ... I'm hoping to get active developing on it again in the new year. I've got so many ideas for improvements.
- jka 7y agoThanks a ton for developing the library :) If & when you're looking for any more contributors and/or testing, let me know; I'd be glad to pay it back. I'm hoping to open source the reciperadar application's stack soon and happy for it to be part of any ecosystem of examples (jbenet's peer-chess was a big help to me getting started).
- Fnoord 7y agoCool project! Some suggestions: * Allow "patchcables" with different hooks, so for example a different recipe database, or a different language. * Allow groups of ingredients, ie. tag ingredients. For example, if I say I don't want meat, I still get shrimp suggested which might be what I want but it might also not be what I want. * In line with that, allow to specify allergens or blacklist ingredients (in line with dietary preference). Allergens are more important than dietary preference. * Allow weighting of ingredients, such as "80% tomato and 20% bell pepper", or something like "tomato or bell pepper" or "tomato xor bell pepper". * Some kind of verification reading at store or fridge (bar codes / tags) to remove entries automatically. Been dreaming of this for a long time. The way I envisioned it stores would share an API, with price, and customers could use it to compare prices and order appropriately (including taking into account S&H). Then the smartfridge (and other smart storage) would read the incoming ingredients. It would also read outgoing ingredients, and it could detect when they don't reenter. It could read weight checking how full the package still is. I had this idea 20 years ago, but I never saw a viable business case in it. You'd need to sit between all these stores who already claim they have low margins. Plus, if you'd sit between them, how would you earn profit from such software? My take is that if you want to secure privacy, software like this would require an initial investment, and then being FOSS, or a subscription and it being partly FOSS.
- jka 7y agoThanks for using it and providing feedback; it's great to hear you've considered similar applications :) I really like the idea of being able to patch in an alternative recipe dataset. It strikes me that a default-offline, peer-to-peer search engine (i.e. 'distributed lunr.js') is technically feasible (even if no such codebase exists at the moment, afaik). That would, in my opinion, be the ideal pluggable data source in terms of achieving local-first behaviour, resilience, and privacy, with the option of fully offline & single-device operation. Shorter-term, once the application's backend code is open source, at least it'll be easier for anyone to run their own instance (it's a containerized set of Kubernetes microservices, FWIW). You're completely correct about ingredient searching and handling. There's a lot to do here. One of the upcoming 'large' work items on the roadmap is to build a true knowledge graph over recipes and ingredients, with relationships (like nutritional information, substitutions and pairings) between entities. I've started exploring this space, but it's going to take a while, and I want to do it carefully and thoughtfully. Allergies in particular are a sensitive topic and I don't want to give users any false sense of safety -- that said, it's also a very valid use case which the app should cater for. Almost every time we do our shopping here we discuss the pricing and stock-keeping problem you mention. In many ways the application would work best if it already knew what you have in the kitchen (and how fresh your ingredients are). There may be some use for image recognition and OCR of receipts -- or, perhaps better, at point-of-sale in stores. Keeping the application client-first is a goal, and feasible I believe - tesseract.js exists today, for example. The project roadmap (and changelogs) will be published on the site in the not-too-distant future, and I'd like to use an issue tracker to track bugs and rank feature requests. I'll keep a note to include items from your feedback and you'll get a credit against them once implemented. Cheers!
- mark_l_watson 7y agoThat is a very cool web app. I really like being able to type in several ingredients and get relevant recipes. I have a nutrient tracking oriented cooking web site (cookingspace.com) that I basically haven’t modified in ten years - seeing your site maybe will motivate me to give my own some attention.
- jka 7y agoThanks Mark - your philosophies around efficient use of ingredients and enjoying healthy meals match our own very closely. I'm having a read of your blog and will drop you a line via email soon.
- mark_l_watson 7y agoGreat!
- mtlynch 7y agoThis is neat. I developed something similar, but specifically for keto recipes: https://ketohub.io https://ketohub.io How are you parsing the ingredients? I went deep into the rabbit hole on that part and ended up spinning off a separate ingredient parsing SaaS: https://zestfuldata.com https://zestfuldata.com I wrote about the experience last year: https://mtlynch.io/shipping-too-late/ https://mtlynch.io/shipping-too-late/
- jka 7y agoAwesome, hello mtlynch :) It's great that you found this post; as it happens I'm using your fork of nytimes/ingredient-phrase-tagger (thanks a lot for updating and containerizing it!) in combination with 'ingreedypy' for ingredient parsing. How's zestful doing? It looks great and I did consider using it; the quantity of parsing I was doing led me to choose the container version just to keep my own operational costs down (albeit at the loss of any model retraining you've done).
- mtlynch 7y agoOh, cool! I'm glad it was helpful. Zestful's doing okay. It's in maintenance mode at the moment, but when I have spare time, I like to tinker with it to bump up the accuracy. Customers seem to mostly use it in big bursts, so it'll be a few thousand requests one month, then the next month, it'll drop to only a few dozen. If you ever have patches you want to push back upstream to the open source tagger, I'm happy to review. And if you ever want to do a bulk parse of ingredients on Zestful, I can certainly offer volume discounts.
- procombo 7y agoVery nice work. I like what I see on many levels! Let me also echo the idea of a "pantry inventory". Getting something like that working (well) would by itself be a very strong feature. Like others, I have been interested in that for a long time. I even took a stab at it many years ago, to some success, but abandoned it when we hired a nanny who took care of cooking. I had a dedicated optical scanner attached to the wall plugged in via USB to an Arduino microprocessor. It had a single button and a single RGB LED. Pushing the button would "wakeup" the system and it would resume previous mode. Two modes: check-in and check-out. (Pushing the button again toggles the mode. System reboots by holding the button down for 3 seconds. Auto "sleep" occured after a set inactivity.) The Arduino just sent a POST request via HTTP API upon a successful SKU scan, and flash a red or blue light depending on thr mode. And then a little CRUD interface I could access from my phone. There are many SKU datasets out there available, and some amount of management of that data (organization, categorization) would be what could really set you apart.
- jka 7y agoThanks! Having to experience the inventory management problem regularly certainly helps inspire & validate solutions :) The setup you had sounds extremely cool - did you hit any particular challenges around the SKU data wrangling? I've added a naive rules-based approach to categorizing products into supermarket departments (bakery, fruit & veg, ...) - it's really barebones at the moment, but already helps planning walking around the shops. I'm not sure where you're based but your Arduino setup reminds me a bit of supermarket self-service checkouts in the UK - you hold each item up to a scanner and get a little 'beep' confirmation for each one during checkout.
- procombo 7y agoYeah. I was definitely very AdHoc. A typical grocery store here in the US has about like, what, 20k SKUs? But I personally only really deal with maybe 200 of those, so at the time I just managed the data manually. (Plugged that USB scanner into a laptop and scanned every item into Excel --Scan, type. Scan, type. Then imported that into MySQL.) I looked into data providers mostly because I wanted item photos. (Ultimately I just scraped images from Target.com cause I could search via SKU and it was super easy.) Unfortunately that's my only experience with SKU data aggragators. My scanner was attached just inside my pantry to the left, and it worked well enough. Hands free. Funny you mention it, cause I'm not a big fan of self-checkouts here in the US. They are ergonomically incorrect, technologically unreliable, and impractical when purchasing more than 15 items. With traditional checkout the conversation is "how are you, did you find everything today?" and with self-checkout they make it clear they know you are a potential theif. shrug
- aeden 7y agoThank you for the peer-base link. I've been investigating data storage on IPFS for application interop and I love the idea about using an existing library rather than re-inventing one. I will definitely be taking a closer look at this project.
- dannyz3 7y agoyes, lots of good things happening on top of IPFS already. Also check out Textile & 3Box.
- copperpot 7y agoThis is really neat, thank you for sharing and developing! I plan to use this to simplify mealtime in my household. One note, as I have not used it much: the "Most relevant" sorting scheme (or perhaps just the search function itself) needs some love. I searched for "chicken" as the sole ingredient, and of the 10 results on page one, only the ninth result is a recipe containing chicken. Many of the rest are desserts. I'm guessing this works better when you include multiple ingredients, but I would think that if chicken isn't in a recipe, it wouldn't be included in the results at all. I'm curious to know if you have experienced this.
- jka 7y agoThanks for trying it out :) In response I've made some changes to search indexing for 'chicken'-related ingredients; I explicitly want some terms like 'chicken breast' to fall under the category 'chicken', but yep, 'chicken bouillon' and a few others don't seem relevant. Hope that helps - glad to keep on narrowing down on any extra cases you find too. There's a small 'feedback' button at the bottom-right-hand corner of the page which sends messages directly to my inbox.