RecipeRadar is a free recipe search engine and meal planner that respects your time, privacy, and ability to contribute feedback and improvements. RecipeRadar aims to help you: Plan, cook and share meals

Discover healthy and economical eating habits

Reduce food wastage

Improve food safety and hygiene We are registered as a Community Interest Company in the United Kingdom and our goals are legally aligned with community benefit rather than to maximize shareholder profit. In order to provide the greatest possible value to the community and respect user values, the application is developed under the following leading principles: The app should provide the simplest and most distraction-free recipe planning and preparation assistance possible

The app should support internationalization and localization of content, weights and measures

The app should follow accessibility and usability best practices

The app should enable collaboration between multiple users during all stages of recipe planning and preparation

The app should continue to be useful in low bandwidth and offline environments

The service should not collect or store any personally-identifiable information

All data transmitted by the app - whether to the service or to other instances of the app - should use secure encryption

The code to the app and service should be made freely available for inspection and modification under the AGPLv3

The app and service should not rely on any proprietary software or development tools There's a lot still to do in order to deliver on all these principles, and we intend to be transparent and accountable as we progress towards them.

RecipeRadar aims to be a faithful and trustworthy companion for individuals and groups during all stages of meal preparation. We're building the application as free (or 'libre') software because we believe that developing the project in the open and with the ability for our users to inspect it, modify it, and collaborate on it produces significant additional value for everyone involved. RecipeRadar's vision is to help anyone discover recipes that make best use of the ingredients they have available - bearing in mind factors such as shelf life, cost and availability, dietary requirements, flavour profiles, nutritional value, and seasonality of the produce in their local area. To put it another way, it's a constraint satisfaction problem over a multi-dimensional domain of recipes, geography, time, and social networks. We are strongly influenced by information retrieval concepts, and view recipe search as a relevance optimization problem. Our corpus of documents is a set of recipes, and our queries are ingredients and constraints. By carefully tokenizing, indexing and scoring our documents and queries we can provide blazing-fast search results and improve our recipe recall and result precision over time. The application should allow people to plan ahead and arrange the meals they'd like to prepare, and automatically create shopping lists that help them track the ingredients they need to find. RecipeRadar should provide an intuitive list of instructions for preparation of meals, including diagrams to illustrate the steps required and time-based reminders of kitchen tasks. We aim to transform text-based recipes into an open digital format that can be used to display the ingredients, steps, and progress of a meal. For example, given a free-text recipe for 'Vegetarian Spaghetti Meatballs' as input, we'd like to produce an output something like this: All of this should be enabled collaboratively - with a preference for other users to 'opt-in' to any meal planning and preparation, rather than being assigned duties.

Contributions We're grateful for all of the feedback and ideas that have been incorporated into RecipeRadar. This page will soon include a list of contributions and credits (including any anonymous benefactors). RecipeRadar is dedicated to the memory of Paul Addison, whose patient guidance with a BBC Micro computer led to the founding developer's interest and career in software development. Technology RecipeRadar is built on top of the best open source software we can find for each of the specific problem areas we've encountered during development. We recognize the effort and hard work that goes into building these tools, and the value we derive by using them is a big factor in our decision to provide the source code for RecipeRadar itself to the public. Included below is a list of some of the key software we use at various layers of the RecipeRadar technology stack. Infrastructure GNU/Linux on our self-hosted server

Kubernetes to orchestrate our microservice containers

Project Calico to provide our container network fabric

CRI-O as our preferred container runtime

nginx to terminate inbound requests and as an ingress controller

Squid to cache outbound requests

PostgreSQL to model, persist and query relational recipe data

Elasticsearch to index and efficiently match ingredient and recipe contents

RabbitMQ as a background task queue Services Apertium for first-pass automated translation of language strings

lighthouse to assess site performance, accessibility, and other best-practices

imageproxy for image thumbnail generation Libraries flask as a base for Python microservices

hashedindex to build in-process inverted indices

ingreedypy (a Python port of ingreedy) to parse ingredient text

recipe-scrapers to extract content from public recipe websites

pint to parse and standardize ingredient quantities

i18next as an internationalization and localization framework

workbox to streamline delivery of the frontend application

select2 to render input selection autosuggest fields

feedback.js (and the html2canvas library that it depends on) to gather user feedback Formats RecipeML to represent recipe metadata We're keen to hear of any alternative technology recommendations. Whenever possible we contribute fixes and modifications we make back upstream; ideally even before deploying them ourselves. We believe it's important to write software contributions in a way that offers reusable value to others, provides backwards-compatibility when possible, and that is optional to use unless it provides a clear benefit (with few negative externalities) to the vast majority of existing use cases.