Hello HN, I’m the founder of blotato - turn existing scripts into production grade apps in minutes, without changing your code!<p>Built in rust (API backend, CLI, executors) and react (frontend).<p>The lineage of most scripts is someone asking a developer for something: can you check these messages, pull data for a report, update customer subscriptions… you throw a script together, then the script gets used more and more, needs more functionality, more people use it. The script must become “production grade”.<p>Other tools force you to migrate your script to conform to their library and paradigm.
With blotato, add a script.yaml file describing your script’s inputs - it works! No limitations on libraries you can use or how to handle certain logic.<p>I built blotato because I want to focus on writing core logic, not all the other stuff. Blotato fills the void between writing a script and ensuring the script is useful to business users, minimizing the work turning scripts into production-grade apps, while retaining the benefits of scalable infrastructure, access controls, logs, etc... so you can focus on the script’s core logic.<p>Blotato is best for use cases involving:<p>- multiple APIs to connect to<p>- non-trivial data transformations<p>- oauth2 integrations<p>- loops<p>- libraries<p>- “I have an existing script that already works and want to put it to work asap”.<p>Streamlined developer-first experience is the differentiator:<p>1. You have an existing script. No need to migrate your script or integrate a library.<p>2. Write script.yaml that tells blotato what arguments your script expects, then blotato autogenerates UI and runs the script on a highly available distributed infrastructure. No need to drag-and-drop UI, no need to write react views, no need to deploy manually on AWS lambda.<p>3. Blotato provides instant scalable infrastructure, execution logs, access controls, secrets management, and one-click oauth2 integrations without setting up oauth2 apps (zapier-style).<p>I built the backend, CLI, and executors in rust and the frontend in react.<p>Between deno and firecracker, rust is great for creating sandboxed isolated environments for running arbitrary user code. “If it compiles it works” - the language enforces strict rules so I don’t shoot myself in the foot. I want to protect customers from myself - so that their workflows won’t suddenly stop running due to an uncaught runtime error. This doesn’t prevent “logic” errors, but it does prevent a fairly substantial amount of errors; and yes, I use strict: true in our tsconfigs on the frontend.<p>Rust's rich type system complements the point above re: error prevention, making it easy to create unrepresentable workflow states that are caught at compile time. Also less memory and CPU hogging so that the resources can be actually spent on running user workflows. Executors, CLI, and the API backend are all written in rust and promote code sharing without explicit codegen / protobuf-like solutions. Sharing code with frontend is also easy (even without wasm by using macros like ts-rs). Compile time SQL queries are awesome (sqlx). Trusting the `query!` macro have saved me many bugs.<p>Coolest thing I’ve implemented is the custom type system with user-defined types that could be (mostly) inferred from existing scripts. There are poor-man’s dependent types that are resolved at runtime. For example, you have a google sheets integration. You have a spreadsheet id and a sheet id. With a bit of handwaving, you get a strongly typed sheet id that is a type only valid for a given spreadsheet (because a sheet id is only valid in a particular spreadsheet), so we get type-level validations that your script is indeed using a sheet id from the correct spreadsheet.<p>To try out blotato, check out the website (<a href="https://blotato.com" rel="nofollow noreferrer">https://blotato.com</a>) and docs (<a href="https://docs.blotato.com" rel="nofollow noreferrer">https://docs.blotato.com</a>).