svelte-routing VS windmill

participated in discussion about the initiative to keep svelte-routing package alive on their github issue: https://github.com/EmilTholin/svelte-routing

So my questions are : Is it possible to have routes inside the MFs ? If yes, should I use something like this (https://github.com/EmilTholin/svelte-routing) even if it's not official svelte support ? I don't really see informations about entry points on the Turborepo doc. I want to be able to work on each MF independantly (I mean see them in the browser in dev mode) but then just serve them as modules for the app shell in prod mode. I imagine this is possible but is it a configuration I need to implement myself with the package.json files or is it about Turborepo ? I read this (https://michalzalecki.com/micro-frontends-module-federation-monorepo/) article about a similar approach with Webpack, but in this article I don't quite see where is the difference between the bundling part of Webpack (wich can be whatever I want Vite for Svelte, Turbo for Next, etc.) and the monorepo handling part. So how/why only one tool (webpack) instead of many others (turborepo + other bundlers) ?

I used https://github.com/EmilTholin/svelte-routing with great success, though it looks like the maintainer has recently stopped maintaining it, and recommending sveltekit.

Still, I'd give try, it looks like people are still using it, and perhaps someone else will pick up the burden of maintenance, since there's clearly a ton of demand: https://github.com/EmilTholin/svelte-routing/issues/236

I'll use SvelteKit in the future but I wanted to learn Svelte with the most basic setup first. I don't want to use SSR anyway. I went with a Vite + Typescript setup and used this router library. It's really simple and did work without any hassle. I love the mindblowing simplicity of Svelte, the tiny builds and the blazing fast dev-server HMR. Coming from React and Vue.

Second point, yes you can add routes. Here is the refence I used: https://github.com/EmilTholin/svelte-routing

Routing: We have a few third party ones such as routify, svelte-spa-router and svelte-routing as well as the clientside routers included in SvelteKit and Sapper.

Data Handling: Utilizes Windmill for data pipelines, with a primary database powered by PostgreSQL. Auxiliary data storage is handled by MongoDB, with Redis for caching to optimize performance

Look very similar to the script builder portion of https://github.com/windmill-labs/windmill, but not open-source, not self-hostable, and without open-source integrations (https://hub.windmill.dev/)

disclaimer: I'm founder of ^

If you need a job queue on Postgres, https://windmill.dev provide an all-integrated developer platform with a Pg queue at its core that support jobs defined in python/typescript/sql

windmill.dev - Windmill is an open-source developer platform to quickly build production-grade multi-step automation and internal apps from minimal Python and Typescript scripts. As a free user, you can create and be a member of at most three non-premium workspaces.

For an alternative to airplane.dev, you can checkout Windmill.

https://github.com/windmill-labs/windmill

"Open-source developer infrastructure for internal tools (APIs, background jobs, workflows and UIs). Self-hostable alternative to Airplane, Pipedream, Superblocks and a simplified Temporal with autogenerated UIsm and custom UIs to trigger workflows and scripts as internal apps.

Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code. Supported script languages supported are: Python, TypeScript, Go, Bash, SQL, and GraphQL. "

If you search HN, you'll find the creator of Windmill comment on comparisons to airplane.dev:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

https://windmill.dev is a self-hostable OSS alternative to pipedream

(disclaimer: I'm founder)

I'm genuinely curious what server-side stuff on BC you are referring to. That may have been something added after our assessment. The way I'd generally approach something like that for any of the platforms would be using an external low/no code solution to process webhook data. But it would depend heavily on the use case. For a more developer friendly option I've been really impressed by windmill.dev. We use a mix of n8n and windmill for various needs.

Yes it goes in that direction, however note that you can already do this in a not too hard way.

Our openflow spec is both open-source and has a full openapi definition: https://github.com/windmill-labs/windmill/blob/main/openflow...

you can use that to generate client sdks in any languages and build your own dag with it. That's what one of our customer did building a reactflow to openflow library: https://github.com/Devessier/reactflow-to-windmill

It's not as good as the decorator way but we move fast and if you still have interest for it we could prioritize it (and ask for feedbacks :))