tylertreat

Basically personalized meal planning and grocery integration. Since the Show HN I posted a couple months back I've been incorporating user feedback to add things like meal prepping, better ingredient reuse across meals, and cooking style preferences.

One of the biggest points of feedback has been adding more grocery stores but I'm really limited by who has APIs to actually integrate with, which is basically just Kroger and Instacart. Walmart has an API but ignored my API access request. Would love to hear if anyone has ideas on how to approach this.

Honestly, I wasn't sure if the AI recipes were going to meet her standards when it comes to food, but so far she's been quite happy overall with the recipe quality. She often will request replacements or customizations, so the first pass suggestions are not always what she's looking for.

I realize it's definitely not for everyone though.

The second big value prop for us has actually been the new "Quick Bites" feature which generates recipes based on ingredients you have on hand (either tracked in your pantry in the app or simply input manually). For instance, we'll often have some ingredients we want to use up but need suggestions on what to make. In this case, there's no grocery integration at all since we're using entirely stuff we already have.

Good question on the meal calendar. You CAN share meal plans (as well as recipes), though there isn't a calendar as such beyond the weekly meal plan view.

Preferences are primarily handled via the AI (uses Gemini on the backend) and this is the primary driver in how recipes are constructed and recommended.

The meal plan generation does take a bit, _typically_ it's around 90ish seconds but it does vary a lot. That's odd the images are loading slowly, I'll need to look into that.

You can ask for meal replacements (with or without input instructions) from the meal plan view. The replacements are not particularly snappy though. Trying to balance efficient usage of AI with a snappy UX is tricky.

Also 100% on messaging to differentiate from just using an LLM to do this yourself. This one feels a bit harder to me because I think it perhaps is not obvious until you get into the product and use it for a bit, though the integrations are a pretty good concrete example.

This is really not my experience with Cloud Run at all. We've found it to actually be quite cost effective for a lot of different types of systems. For example, we ended up helping a customer migrate a ~$5B/year ecommerce platform onto it (mostly Java/Spring and Typescript services). We originally told them they should target GKE but they were adamant about serverless and it ended up being a perfect fit. They were paying like $5k/mo which is absurdly cheap for a platform generating that kind of revenue.

I guess it depends on the nature of each workload, but for businesses that tend to "follow the sun" I've found it to be a great solution, especially when you consider how little operations overhead there is with it.

The irony is how would this have played out if it _did_ turn into a thriving project under CNCF? In that scenario, the NATS brand would have substantially more value and equity. That would have made a relicensing even more impactful, made it even more difficult to claw back from CNCF, and even more controversial. Because NATS remains relatively niche, I suspect the thinking is that not enough people will really care for it to matter, but if that's the case, why not just make a proprietary fork under a new name?

I don't know how this situation doesn't result in a fork. Either the BSL will be a fork or the OSS will be a fork. But because nearly all of the contributors are Synadia employees, I don't know what this will mean for the longevity of the project.

Koreo would also allow you to implement a workload spec such as Score rather easily for the same reason. https://score.dev

Only in cases where the values are statically known, however. If you have resources that depend on the output of another resource, then we can't know that at "template time" as you pointed out.

One difference is just in how the two approach doing this. Koreo takes an approach of providing primitives that can be composed or reused and, importantly, are actually testable (since testing is a first-class thing in Koreo). This lets you more easily validate automations but also makes it easier to provide "building block" like components that can be shared between Workflows.

Another difference is in how Koreo solves configuration management. Rather than relying on string templating or unstructured YAML overlays, Koreo treats configuration as structured data. This allows you to specify and tweak configurations in a predictable and typesafe way by transforming, validating, and composing them programmatically. Koreo is very much modeled after functional programming principles, so we can, for instance, define functions that validate preconditions or apply standard tags to resources in an environment. This model also enables configuration reuse and overrides across teams and environments without introducing tight coupling or duplication. Instead, we can apply configuration "layers" to build up a resource. Kro really focuses more on resource orchestration and leaves the configuration management up to the user.

But I guess there is an actual preview implementation now? https://docs.crossplane.io/v2.0-preview/

The comparison on Kro would definitely be good to include as there are quite a few similarities. I can write up more on how it compares in a bit.

- Written in Go rather than Java/Scala (big benefit here IMO is getting a small static binary rather than having to run a JVM)

- Doesn't rely on Zookeeper

- Is integrated with NATS (can extend NATS with Kafka-like semantics, but in the future will allow for abstracting NATS away entirely)

- Uses gRPC for its API

- Supports "wildcard topics" - e.g. a stream can listen to the topic "foo.*" and will receive messages published on "foo.bar", "foo.baz", "foo.qux", etc.

- Allows for streams to be paused and subsequently resumed automatically when published to - on the roadmap is "auto-pausing" of sparsely used streams

- Exposes an activity stream that allows you to respond to events such as streams being created, deleted, paused, etc.

One advantage Kafka currently has is its consumer groups, which are on the roadmap for Liftbridge but not implemented yet.

There's a more complete comparison available here: https://liftbridge.io/docs/feature-comparison.html

Looking at Akka Streams, it appears to be more in line with Liftbridge, though I'm not totally sure. Liftbridge (like Kafka), is a message log, so messages do not get acked or removed from a stream (unless removed due to retention limits or compaction). I'm not sure if that's the case with Akka Streams.

I'm curious what your needs are around exactly-once delivery. From what I can tell, Akka only supports at-least-once semantics and is of the opinion that exactly-once isn't really possible as such (which is an opinion I agree with, but that's a more nuanced discussion). https://www.lightbend.com/blog/how-akka-works-exactly-once-m...

Longer term, I'd like to take advantage of the recent work in NATS around superclusters and geo-aware subscribers to provide better geo-replication primitives directly inside Liftbridge (https://www.slideshare.net/nats_io/deploy-secure-and-scalabl...).