maxthegeek1

Great!

Thanks for the kind words :) Temporal is a great technology for this use case.

Wow, our DSL even looks similar!

Your app has beautiful design, which I guess shouldn't come as a surprise given that it's Airbnb.

Would love to chat to discuss further.

max@dittofeed.com

One of our motivations for selecting Clickhouse, is that it's relatively simple to run as a single node. This makes things easier for people who are looking to self-host a small to midsized installation of Dittofeed. It's also IMO a better developer experience for Dittofeed contributors who are running Clickhouse locally.

As far as functionality I'm a fan of Clickhouse's swappable table engines.

+1. Wanted to jump in to say that the kafka dependency is strictly optional. It's used to batch writes to clickhouse, but for less intensive workloads Dittofeed can use clickhouse's asynchronous inserts for in-memory batching.

Our plan is to model loops by having journeys define re-entry conditions, allowing users to run through journeys multiple times on a schedule. Would love to talk, to learn more about y'all are doing.

My email is: max@dittofeed.com, or feel free to ping me on our community slack!

Offering a single executable binary is definitely great, but wouldn't be super practical given our choice of technologies. Tradeoffs.

We're working on our second channel right now (mobile push), which will have the flow you'd expect when released. Thanks!

Thank you! Choosing typescript was intentional on our part, because we want growth / marketing engineers to feel comfortable contributing.

We have authorization built into the app, but are using a simple auth proxy, with oidc for authentication. If you want to authenticate your own app, you can use something like ouath2-proxy with an oidc provider, and set the `AUTH_MODE` configuration in our app.

Happy to walk you through it if you join our slack.

It depends! If you're self-hosting you'll get your own clickhouse instance.

Our base cloud hosting currently uses a multi-tenant clickhouse instance, but we also optionally provide a single tenant instance as part of our enterprise cloud offering.

Currently we support sendgrid for email, and SMS is upcoming.

The best reason to use k8s is to take advantage of the wide array of open source k8s resources, including helm charts, custom operators, articles and tutorials etc. It's become an open standard.

Like with many other technologies, k8s' advantage is its ecosystem.

Pretty cool to see more db's built on top of modular components. Was first introduced to the concept in the context of FoundationDB and it's cool to see it here again!

Yes, but you also don't want to have to deploy in the middle of the night in order to avoid downtime during peak hours.

Not only is that a pain for whoever is monitoring the deployment, but now if the deployment breaks something you're going to have to go wake up all of the relevant stakeholders, if you even know who they are.

Not to say late night deployments are never justified, but definitely not something devs want to be doing regularly.

What? I've never worked for a company that would tolerate downtime during deployments. Downtime is ok for personal projects, but not for most business applications.

Snowflake is a pretty amazing piece of engineering. I suspect that solutions to problems of this kind, resource allocation given conflicting constraints and objectives, will only get more sophisticated over time.

Hi, this seems like a really cool project! Given your use of rust, have you considered providing the option to run this as an embedded datastore, like you might use sqlite?

Might bring more users onboard, for the better CI/testing ergonomics. Thanks!

There's a whole world of engineering that standard software dev work relies on, that we're isolated from. It's rewarding to have the curtains pulled back every once in a while to appreciate the complexity of it all.

Congrats! You all have a really great product and team.

Super interesting to read about the implementation details of IPFS. IPFS feels like one of those developments in the space of decentralized applications, that's more likely to stand the test of time.

I plan to use this the next time I write an operator. Honestly it's surprising to me that this didn't exist before!

If you want to enrich locals at the expense of tourists, the straightforward way to do that is just raise property/sales taxes and payout the revenue to locals.

AlphaFold, and to be honest, most of the software/research coming out of DeepMind. For better or worse, they're the Bell Labs of the modern era.

If you need to call blocking code from an async code just use spawn_blocking.

https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.ht...

Does async rust prevent the use of C FFI? A quick google shows me nothing there.

He's up there, but von neumann still beats him out IMO.

I could see this being very useful. The standard cache + db architecture has some sharp edges that end up biting people all of the time e.g. the thundering herd problem.

In this post, I describe how to effectively write integration tests for complex asynchronous workflows with external service dependencies, and some of the challenges we've faced at Braze.

If you're interested in working on problems like these, check out our open roles!

https://www.braze.com/company/careers

Looks pretty cool. As serverless compute gets cheaper, I imagine there will be implications re how structure applications.

Very cool to see more platforms which are unbundling various db components.