Callicles

Done

I added runtime by adding a resolver and removing it. I also made the map responsive.

ha that could be less handy but cooler

I added the ability to specify a config file for the resolvers definition. This is not runtime, though. I will keep that in mind for another release.

Thanks for the follow-up :)

Addressed the feedback

Released a new version with the suggestion ;)

Thanks for the feedback!

This was 100% vibe-coded with Claude Code and Fable.

https://x.com/thatsFrScience/status/2073741209592295866

Thanks for the feedback, though, and for taking the time to look at the code. I can ship a round of cleanup.

Yeah, I used to use https://www.whatsmydns.net/. I wanted it in the terminal without ads.

That's what the tool is doing - querying a bunch of public resolvers around the world to see the state of what they resolve to. Since end users usually use DNS servers close to their location, this gives an idea, around the world, of who sees what.

Agreed, this is a cache that expires and refreshes from the source DNS server. It just looks like a virus that propagates when the cache expires.

Hey,

We went from the get go to that infrastructure for multiple reasons in the first place:

* Having a durable buffer before ensures if you have big spikes that gets eaten by the buffer, not OLAP which when it is powering your online dashboard you want to keep responsive. Clickhouse cloud now has compute/compute that addresses that but open source users' don't.

* When we shipped this for the first time, clickhouse did not have the async buffering in place, so not doing some kind of buffered inserts was forwned upon. * As oatsandsugar mentioned, since them we also shipped direct insert where you don't need a kafka buffer if you don't want it

* From an architecture standpoint, with that architecture you can have multiple consumers

* Finally, having kafka enables having streaming function written in your favorite language vs using SQL. Definitely will be less performance to task ratio, but depending on the task might be faster to setup or even you can do things you couldn't directly in the database.

Disclaimer I am the CTO at Fiveonefour

Not yet, but we have that on the roadmap!

MooseStack maintainer here. I helped author the post. Happy to answer any questions, but very curious to get feedback. We’ve been thinking a lot about developer experience for the OLAP stack.

I believe I am saying child processes can write to stdout as the main process is shutting down. Also, if the child processes are not shut down properly and are left dangling, and the child processes were set up as 'inherit' to be able to write directly to stdout/stderr then yes.

Not sure if this is what you are asking about, so if I misread feel free to correct me. You don’t have to install moose first on the deployment machine, in the tutorial I go through that to generate a dummy moose application to be deployed.

It is the same idea as a nextjs application you deploy through docker, you have your application and then you build your docker container that contains your code, then you can deploy that.

I tried to limit the port bindings, we usually expose moose itself since one of the use case is collecting data for product analytics from a web front end, which pushes data to moose. And then usually people want to expose rest apis on top of the data they have collected. The clickhouse ports could be fully closed, this was an example of if you want to connect PowerBook to it

Hi!

We are built on top of them. Right now the techs above are what’s backing the implementation but we want to add different compatibilities. So that you can eventually have for example airflow backing up your orchestration instead of temporal.

You can think of moose as the pre-built glue between those components with the equivalent UX of a web framework (ie you get hit reloading, instant feedback, etc…)

Interesting. How do you do dependencies between those pieces of infrastructure if there's any? For example, in our Docker Compose file, we have temporal that depends on progress and then moose depends on temporal. How is that expressed in Insta-Infra?

I put this Docker-Compose recipe together to make kicking the tires on Moose—our open-source data-backend framework—almost friction-less.

What you get:

• A single docker compose up that spins up ClickHouse, Redpanda, Redis and Temporal with health-checks & log-rotation already wired.

• Runs comfortably on an 8 GB / 4-core VPS; scale-out pointers are in the doc if you outgrow single-node.

• No root Docker needed; the stack follows the hardening tips ClickHouse & Temporal recommend.

Why bother?

Moose lets you model data pipelines in TypeScript/Python and auto-provisions the OLAP tables, streams and APIs—cuts a lot of boilerplate. Happy to trade notes on the approach or hear where the defaults feel off.

Docs: https://docs.fiveonefour.com/moose/deploying/self-hosting/de...

18-min walkthrough video: https://www.youtube.com/watch?v=bAKYSrLt8vo

;)

Not yet, but if you are interested in using we could chat and add support for it. We want to expand support eventually for all major OLAP provider.

We are currently in Production on Boreal https://www.fiveonefour.com/boreal, our hosting solution for Moose with F45 https://f45training.com, a global studio fitness studio brand. We wrote a case study with them here: https://www.fiveonefour.com/blog/case-study-f45. So we Have a 24/7 consumer facing deployment that we have been running for the last 5 months.

We are going towards 1.0 from an API perspective, we have just landed what we internally call DMV2 which is the latest iteration of the abstraction level for the api. Think SST / Terraform CDK vertically integrated for Data.

If you are looking to work with Moose in production we would love to chat with you :)

Founder here. Thanks for the interest! We built Moose because we were tired of the complexity involved in setting up and maintaining data pipelines.

What makes Moose different is how it simplifies the entire workflow - from ingestion to processing to serving data through APIs. We've found teams spend too much time wiring together different tools rather than focusing on the actual data insights.

The local development experience was a big focus for us. You can instantly test your changes with real data without waiting for deployments. And we've made sure the same code runs identically in production to eliminate those frustrating "works on my machine" moments.

Happy to answer any questions about our technical approach or how we're handling specific use cases. We're particularly interested in hearing about pain points you've experienced with existing data systems or any feedback you might have on Moose.

Probably not what the people are asking for but it is what they need

How does that compare to writing tests and checking code coverage?

The docs says that it tries to explore all the branches of the AST, isn't that what coverage is doing?

I might be missing something.

In addition of having your friends and colleagues being a reference, we want to also give you hard data about the libraries you are (considering) using like issue tracker stats, stack overflow answer rates, mailing list activity ... This is just a glimpse of what we want to build. We have a vision that we want to build with our users. As a result, the product will certainly be different from what initially intended.

We are beta testing with some customers right now. We plan on rolling out progressively as we improve the product and make our first users happy. Sign up to be kept int the loop !

It is not live yet for everyone, we are testing it as we are building it with a subset of users.

The demo is available at the end of this page http://linkurio.us/product/

For Linkurious.js there are some examples over here https://github.com/Linkurious/linkurious.js

All infos on the toolkit are available on http://linkurio.us/toolkit/