frontend VS infrastructure

Thank you for the response!

> support splitting ingredients by typing a comma

That sounds sensible, yep; filed as https://github.com/openculinary/frontend/issues/210

> "Are there any ingredients that are not available?" ... I knew what you meant, the search will exclude recipes with those items, but it felt weird to read

That makes sense too. If I remember correctly, that prompt was most-recently rephrased during a pandemic-related lockdown (with subsequent unpredictable ingredient shortages), and so that context may have affected the choice of language; but I agree that it's odd phrasing and should be updated.

Hopefully that'll be a relatively quick correction, although it will require internationalization (currently machine-translated without review by native language speakers, not ideal); it's filed as https://github.com/openculinary/internationalization/issues/...

> box around the search form has a huge gap to the right of the form inputs

> I'd probably expect to see filters for vegan/veggie/pescatarian / low gi etc but then maybe not

Two good points here, and possibly combinable. Perhaps those dietary recipe filters could be placed in the excess space available next to the search controls.

Today the search API does theoretically support filtering[2] on a few dietary properties -- but that functionality isn't yet visible and available to the user.

Feature request filed as https://github.com/openculinary/frontend/issues/211

- Shopping list feature ... your icons seem too small and fiddly, and I'd want a few buttons on screen of common things - so I can tap those instead of typing

That sounds smart. This feature (and the meal planner) are under-attended relative to the recipe search/explore components, in my opinion. Let me think about this for a while, there are a few considerations and I'd like to be concise.

[2] - https://github.com/openculinary/api/blob/72075f66cd6fda5b809...

I've been developing a recipe search engine and meal planner at https://www.reciperadar.com/ -- all the code is free and open source.

I think the two largest challenges it has at the moment are:

- Developer experience / infrastructure setup: the service is Kubernetes-based, composed primarily of Python+Flask microservices, and although the setup steps are documented[1], they're not yet automated.

- User interface: my lack of user interface design skills are fairly apparent, I think. Having some clear UI goals to work towards would be helpful - there's likely some overlap with product design questions here (what should be the range of functionality that the the app offers?)

Any and all feedback welcome, from discussion comments to pull requests to business model questions/critiques :)

PS: Don't forget to mention one or two of your own side projects if there's anything you're looking for help with, too.

[1] - https://github.com/openculinary/infrastructure/

Hi folks,

I enjoy developing and maintaining the RecipeRadar[1] project's infrastructure in a truly open fashion.

Since the project itself is AGPL-licensed, that means I like to -- ideally -- push infrastructure documentation and changes before the associated administrative commands are run. That means that the code to the system itself is already published and available (in a chronological sense) to anyone using the service over the network at any given point in time.

However, it does introduce a set of strange risks: what if there changes expose security vulnerabilities that are _not yet_ introduced, but will be when the commands are run.

In a typical system administration scenario, generally the 'home team' acts carefully and is primarily only aware of their own actions - aside from monitoring for any externally-initiated or unexpected system behaviour during maintenance.

If a mistake is made, sometimes they'll backtrack and clean up, but for some kinds of system change, it's hard to know whether an exposed vulnerability was exploited, because the exposure window may have been very brief.

I have a sense that the best overall solution to this kind of problem (in this kind of open environment) would be an 'adversarial' system administration approach; perhaps involving some kind of mirroring.

Two (or more) systems would walk through the same series of administration steps, each with one (or more) red teams attempting to exploit the process -- already armed with the knowledge of the steps to be applied in advance.

Does that make sense to anybody, and/or can anyone provide thoughts or reading material about research into this kind of area?

[1] - https://www.reciperadar.com/

[2] - https://github.com/openculinary/infrastructure/