Cicada looks very promising, congrats. I'm wondering why you choose to use Fly.io for the CI/CD runners, instead of using VPS / baremetal servers that are a lot cheaper? Do you need the edge features that Fly.io offers?
We really like the speed of their firecracker VMs with spinning up runners (important when you need your CI/CD to start quick), we don't really need the edge features of the platform.
Congrats on the launch! I've been following Moon since a few months, seems like an interesting project.
Could you explain why any existing project using Turborepo/Nx should switch to Moonrepo? What are the advantages and disadvantages? The support for multiple languages seems like a big advantage.
I'll start with Turborepo. Turbo is primarily a task runner for `package.json` scripts with some caching... and that's basically it. If that's all you need, then great, but if you're looking for more functionality, that's where moon comes in. moon is more than just a task runner, we're aiming to be a repository management tool as a whole. This includes project/code ownership, direct CI support, future CD support, code generation, hooks management, constraints, release workflows, and much more. With that being said, we do have a comparison article against Turbo: https://moonrepo.dev/docs/comparison#turborepo
As for Nx, they're more of a competitor than Turborepo. Nx and moon are aiming to solve the same problems, but go about it in different ways. Nx is Node.js based and requires heavy adoption of their ecosystem (@nrwl packages) and their executors pattern. In the long run, this becomes a heavy source of tech debt, as your dependencies are now tightly coupled to their packages and release timelines. With moon, we wanted to avoid this all together. There are no coupled dependencies, and tasks are ran as if you ran them yourself on the command line. No abstraction layer necessary. We also want to embrace a language's ecosystem as much as possible, so moon adoption should be rather simple and transparent (at most each project has a moon.yml file).
But to your last point, we agree, multi-language support is a massive advantage. Having both backend and frontend code in the same repository, powered by the same build system, is a massive win in maintenance costs and developer time saved.
Yup exactly that! We want a single to to handle version bumping, changelog generation, publishing to a registry, etc, for _all_ languages that we support.
I'm building Lagon, an open-source [1] runtime and platform that allows developers to run TypeScript and JavaScript serverless functions at the Edge, close to users. The runtime uses V8 Isolates and is written from scratch using Rust and rusty_v8 [2], Deno's Rust bindings for V8.
Looking at the source code [0] for Deno HTTP server, they spawn at least one thread for the server to listen and handle requests, before they are sent through a MPSC channel to the thread running the Isolate.
Not the author of this app, but I found this to be very useful for circumventing domain blocks made by ISPs / sovereign entities[0].
Let's say that the government / some central entity takes the blocking a step further by blocking Cloudflare's DNS-over-HTTPS (DoH) endpoint. I could just spin up a new instance on fly.io (or really any other service of your choosing), and use the new endpoint as the new DoH endpoint.
What I like about this service is the fact that I can still use a blocklist to block trackers & ads, just like how you would with NextDNS. Most of the services listed in the example page are pretty generous with their free plans, so the whole setup may end up being cheaper than the Pro plan[1] of NextDNS.
[0]: A number of quite essential services just got blocked by the government where I live, so this is a very real possibility.
Cloudflare Workers supports ECH out of the box. Also, one can deploy serverless-dns against any sub-domain that's available with underlying provider (mydoh.workers.dev, yourdoh.deno.dev, dohapp.fly.dev, etc) and keep changing the sub-domain for free to defeat SNI-based censorship.
Not this project specifically, but a DoH resolver of your own is pretty nice. It's almost impossible for someone to reliably block it by filtering DNS packets (many public networks do for some reason), you can do your own crazy levels of caching (I ignore TTLs and serve stale responses for speed), in general my setup for this just works very pleasantly.
Probably more for privacy reasons. And maybe if you set it to resolve to an adguard or pihole instance it could be for adblocking on the DNS level. Which really is quite effective a lot of the more spammy ads, even though it can't really do anything about Youtube (since they use the same domains for content and ads so blocking ads blocks content too).
