Currently I'm working on following features: - Multi user support (Team) on project level - Then I'll look into whether to add support for OIDC/SSO now or not - Alert on slack - Webhook support

0: https://daestro.com/

Apart from bringing your own compute, Daestro also integrates with AWS, DigitalOcean and Linode.

0: https://daestro.com

Self-hosted compute can also be linked to Daestro to run jobs on.

[0]: https://daestro.com

I am also working on similar tool[1] but it's bit more niche to batch jobs type functionality but not just limited to AWS rather it's cloud agnostic.

[1]: Daestro - https://daestro.com

My name is Vivek, I've been working on Daestro (https://daestro.com) for quite some time which is a cloud agnostic orchestration platform. Where cloud providers are the first citizen. Which let's you run jobs (docker image based) across cloud providers.

What can Daestro do? - Run jobs on your machine or Cloud Provider account, i.e. AWS, Vultr, DigitalOcean, Linode - Daestro handles creation and deletion of instances on your cloud provider account - Cron Jobs - Schedule jobs for later execution - Realtime logs and metrics (currently very basic but will improve) - Set custom cpu and memory quota for jobs - Can run multiple jobs per machine - See metrics and logs for each job run

Why I created Daestro? There are way too many options available when choosing cloud providers, they all have compute to offer however most don't have any options when it comes to running managed batch jobs. They all have their merits and demerits when it comes to your specific needs. So why not a platform that integrates with these platform and manages it for you. So suppose if you are getting some cheaper compute or lower data transfer cost, you can use that without any extra effort.

What's next for Daestro? - Multi user support with RBAC - Job chaining - GCP and Azure Integration - Run multiple jobs on single machine - External triggers integration - Improve API support

Comments URL: https://news.ycombinator.com/item?id=45253220

Points: 1

# Comments: 0

I get the premise of HTMX and when and why to use it, it's not solution to everything however it is a blessing for backend developers' who wants to work on frontend.

-> A bit of backstory

For my project Daestro[0], which is bit complex (and big) I chose Rust as backend and Svelte (with Sveltekit) as frontend SPA app. This was my first time working on both. After years of working on Django, I wanted to try statically typed language, after some research and trial, I chose Rust. Sveltekit was obvious because it made sense to me compared to other frameworks and it was super easy to pick up.

After working on Sveltekit for a year, I realised I've been spending a lot of time doing these same thing: 1. You create the api on the backend 2. then you create Zod schema on the frontend for form validation 3. the create +page.ts to initialize the form 4. in +page.svelte you create the actual form and validate it there itself with zod before sending it to the server

Hopping over two code bases just for a simple form, and Daestro has a lot of forms. I was just exhausted with this. Then HTMX started to get a lot of traction, I was watching it from a distant but having worked with Django and it's template, I was dismissive of it and thought having separate frontend is best approach.

-> Why I'm leaning towards HTMX now?

- Askama (rust crate) is a template engine which is compile time checked - Askama supports block fragments[1], which is you can render certain part (block) of template, plus for HTMX usage - Askama's macro almost don't make me miss Svelte's components - Rust has amazing type system, now you can just use it, no need to replicate those on Typescript - same codebase, no more hopping - only one binary to deploy (currently for Daestro I've 3 separate deployments)

-> My rules for using HTMX

You must self-impose a set of rules on how you want to use HTMX, otherwise things can get out of you hand and instead of solving a problem you'll create bigger ones. These are my rules:

- Keep your site Multi-page Application and sprinkle some HTMX to make it SPA like on per page basis - make use of hx-target header to only send the block fragments that is required by HTMX (very easy with Askama) - do not create routes with partial page rendering instead a route must render complete page, and then use block framents to render only what is being asked in hx-target - Do not compromise on security[2]

[0]: https://daestro.com [1]: https://askama.readthedocs.io/en/stable/template_syntax.html... [2]: https://htmx.org/docs/#security

This is for Daestro[1] which is a cloud agnostic job orchestrator.

[1] https://daestro.com

However I tried rustls with redis for my axum application, for some reason it was not working, even though my self signed ca certificate was updated in my system's local CA store.

After a lot of try I gave up then thought about trying native tls, and it worked in first go.

About Daestro: Daestro is workload orchestrator that can run compute jobs across cloud providers and on your own compute as well. More like cloud agnostic batch jobs or step functions.

[1]: https://daestro.com

For my work[2] I am using SvelteKit and written my own blog using mdsvex and enabled pre-render. That works well too.

[1]: https://vivekshuk.la [2]: https://daestro.com/blog

Daestro - https://daestro.com

Launching next month @ https://daemonstack.com/

Comments URL: https://news.ycombinator.com/item?id=15291468

Points: 1

# Comments: 0