openculinary / blog Goto Github PK

Is your feature request related to a problem? Please describe.
Originally https://blog.reciperadar.com was envisioned as the home for content related purely to RecipeRadar engineering.

There is now a desire to make this a consolidated place to post updates relating to company, product, and other business areas.

Describe the solution you'd like

• Change the theme to something lighter and easily-readable
• Re-tag existing engineering posts as #engineering
• Rename the blog

Describe alternatives you've considered
Hosting an alternative blog is an option, but seems like it causes unnecessary fragmentation and duplicate maintenance effort.

Additional context
The blog currently looks like this:

• Handling both HTTP and HTTPS requests with minimal client impact
• Configuring aggressive squid caching policies
• Thanks to the nlnwa for their veidemann-cache configuration which was a useful starting point

• Parsing product names
• Indexing into Elasticsearch, including mappings & field types
• Autosuggest and determining whether to display singular vs plural descriptions
• Canonicalization and search-time queries
• Expansion of recipe contents (and the future of the knowledge graph)

• Conceptual idea to backfill empty search results
• Design considerations and implementation

Relates to openculinary/recrawler#1

• Setting up a cri-o backed Kubernetes cluster
• Building container images using buildah and podman
• Deployment using labels and image versions

Is your feature request related to a problem? Please describe.
An architecture-level blog post that explains the key components and dataflows that comprise RecipeRadar could be useful to help educate people - including potential contributors - about how the system works.

Describe the solution you'd like
A diagram could be fairly key for this. Something that indicates where recipe data is retrieved from (multiple websites - with squid on the outbound path to reduce load on those), the component that acceses them (the crawler, perhaps with an indication that it encapsulates recipe-scrapers), the lookup/parsing that occurs on the results, and how those are stored and indexed in the database and search engine -- before the api serves those to the frontend web application.

Boundaries in the diagram to indicate the client web browser context, server-side Kubernetes cluster, and external web content could be useful.

Describe alternatives you've considered
N/A

Additional context
N/A

This was a tricky problem to solve and it is now documented in the code -- it would make for a good engineering blog post.

Is your feature request related to a problem? Please describe.
We'd like to populate the blog with more content, and we have fortnightly update emails that have been shared with the company's volunteering group over the past year or so. From the first of these updates, the stated intent was to make them public. The blog seems like a good place to put them.

Describe the solution you'd like

• Download the originally-sent RecipeRadar fortnightly update emails
• Convert the messages (including inline images and media) into the markdown format used by our other blog posts so far
• Perform any editing necessary to make the content suitable for a more general audience
• Publish the resulting blog posts

Describe alternatives you've considered
For a long time, an alternative plan to migrate to a 'public to everyone' mailing list was considered. This may still be a good idea; it works well for a lot of free and open source projects. However there is a lot of careful infrastructure arrangement to consider, as well as moderation and safety considerations.

Given that we have a web-based blog already available, this is a good way to allow more people to read about the project, even if it is less interactive than might be ideal in the long-term.

• peer-base
• recipe-scrapers
• hashedindex