Show HN: Skybear.net – A managed platform automating Synthetic HTTP API testing https://ift.tt/bDotj5d

Show HN: Skybear.net – A managed platform automating Synthetic HTTP API testing Hey folks, I am finally posting a Show HN post for a project I have been working on for several months now, and it's in a state where I already get a lot of value myself, so I am happy to share broadly. The pitch line is: "Skybear.NET is a managed platform automating Synthetic HTTP API testing." At the moment, the main source file format supported for your API tests are Hurl.dev files [1]. Hurl is a CLI tool wrapping `curl` and it's really awesome. At least check that out :) I am not affiliated directly with the Hurl CLI tool, and the platform I am building provides full Hurl compatibility. I have been using Hurl for a few years now [2], and use it for my API testing, for orchestrating a bunch of HTTP APIs, and in general whenever I need to do anything with HTTP requests, I reach for Hurl. You can try without signup the basic execution feature with the free Open Editor [3], but for full functionality (retaining responses and cron triggers) you need a signed in account, even free. The Skybear.NET platform: 1. Has Hurl Compatibility, so take your local scripts and run them on the cloud as well. No changes needed. 2. Provides managed infrastructure for authoring, storing, and most importantly executing your Hurl scripts, that automatically scales to handle as many script runs as you need. 3. Generates detailed reports from your tests execution, automatically persisting requests and response bodies for introspection in the future, and with automatic insights coming up soon. 4. Supports multiple ways of triggering execution of your scripts, including periodic executions, and on-demand HTTP triggers enabling integration with your CICD pipelines. Most importantly, it eliminates excessive per-request/per-step/per-check charges, leading to substantial cost-savings for complex multi-step API tests covering complete user-journeys. I consider a "script project run" to be the main unit in my pricing, which includes execution of all the source files of the script project, which can be tens or hundreds of requests. I am starting to document some of the architecture of the platform as well [4], but in a nutshell, all your data is encrypted inside the application before stored on AWS (S3, DynamoDB, also encrypting at rest) [5], the control plane runs on Hetzner and AWS EC2, and the execution servers running your scripts run on Fly and soon on AWS EC2 (for some plans). Future plans depend a lot on feedback from users. I already have a long list of things I personally want to have, but as more users start using I would like to see user needs influencing the roadmap more. Some upcoming features: 1. Insights and metric graphs for historical tracking of your tests (per project, per file, per request URL). 2. Automatic generation of tests based on OpenAPI schemas, HAR files, etc. 3. Export API of all the data and reports for your own consumption. 4. OTEL traces generated per script run, exportable and sent to APM products. Thank you, and I hope you find it interesting too! Lambros Petrou 1. https://hurl.dev 2. https://ift.tt/STcstrX 3. https://ift.tt/GxKl0uR 4. https://ift.tt/OtADoFJ... 5. https://ift.tt/VTyJtSl https://www.skybear.net December 23, 2024 at 01:39AM

Show HN: Get e-signatures & pay per signed doc https://ift.tt/rkxu5Sd

Show HN: Get e-signatures & pay per signed doc Woke up today with a 100-degree fever & found out Google is now our competitor. Last week, we started building signwith.co/ - a simple, pay-per-use e-signature tool for people who are struggling with complex e-sign tools. The plan was to build quietly, run a private beta, get 50 users in 15 days, and then do a launch. Easy peasy. But since Google dropped into the e-signature space - we needed to talk. So after 30 minutes of existential dread, a lot of “what are we even doing?” thoughts, and one strong dose of paracetamol we said, screw it. - let’s change gears. So now we're opening our beta, and here's the deal: • All the people who join will get free credits worth 10 signed docs • 12 months credit validity • No complexity • No hidden cost • No subscription commitment You can join the beta here - http://signwith.co That said, we see Google's entry in the signature space as validation. This event expanded the market with such massive awareness. Let me be clear: We’re not trying to be DocuSign, Google, or any other enterprise beast. We’re indie makers and building for: • The freelancers • The consultants • The indie and small business owners • and anyone who just needs a contract signed—fast, simple, no headaches. Here’s how SignWith works: • Upload your doc • Drop signature spots • Send it out and track • Pay per signed document That’s it. No subscriptions. No feature bloat. No crazy hidden charges and no complex pricing tiers. If you've read it so far, would love to see you on the other side. And hey, if you’ve got any feedback, suggestions, or just want to tell us what you need, reply here or drop me a DM. We’re all ears! Cheers! https://signwith.co/ December 20, 2024 at 05:03PM

Show HN: Rivet Actors – Durable Objects build with Rust, FoundationDB, Isolates https://ift.tt/VMSQYtn

Show HN: Rivet Actors – Durable Objects build with Rust, FoundationDB, Isolates Hello! We posted a Show HN for Rivet last year for our container orchestration project ( https://ift.tt/KLyeZmM ). In that time, a lot has changed that I think HN will find interesting. Rivet is open-source actor infrastructure similar to Cloudflare's Durable Objects. Rivet itself already serves millions of MAU in production using our current container runtime – primarily for multiplayer games – and Rivet Actors are a new extension to support actor-like workloads. Rivet Actor's core primitives are RPC, state, and events. Actors are powered by Rust, V8 isolates (supports Deno), and FoundationDB. An architecture diagram is available here for [1]. If you're not familiar with FoundationDB, you're overdue to watch Dave Rosenthal's talk [3]. (I firmly believe it's by far the best permissively licensed database; if only it had a well maintained SQL layer.) Here's where Rivet's architecture gets fun – we don't rely on a traditional orchestrator like Kubernetes or Nomad for our runtime. Instead, our orchestrator is powered by an in-house actor-like workflow engine – similar to how FoundationDB is powered by their own actor library (Flow [4]) internally. It lets us reliably & efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here's the logic that powers Rivet Actors themselves with complex mechanisms like retry upgrades, retry backoffs, and draining [2]. One of the reasons we built Rivet Actors is because we tried to replace most of our Redis-based realtime infrastructure with Durable Objects. The architecture allowed us to build realtime features much faster & efficiently, but the platform & APIs were needlessly rigid and difficult to use. Our goal is to build an actor-like platform that includes the bells and whistles required for developers to benefit from the actor model without the learning curve of tools like Erlang/OTP, Akka, or Orleans. Rivet Actors provides a few key benefits in flexibility over Durable Objects: - Open-source (Apache 2.0) – built to be self-hosted and deployed on-prem - Provides observability out of the box, no Logpush required - Rivet Actors support the Deno runtime, so NPM & JSR just works - @rivet-gg/actor [5] framework provides RPC, state, and events out of the box for faster bootstrapping; you can modify and deploy it yourself - Supports both V8 isolates & Docker-compatible containers so you can run any software you'd like, like Godot/Unity servers or video transcoding - Also supports TCP & UDP (we run games!) - Provides vanilla HTTP API for easy use with existing apps - Full control over regions There's plenty more that I don't have space to talk about. Give our docs a read if you'd like to learn more [6] or read about internal design decisions [7]. I'll be in the comments answering questions! Cheers, Nathan [1] https://ift.tt/rWPSa3K [2] https://ift.tt/X8WOuNe... [3] https://www.youtube.com/watch?v=9g84y_60VGM [4] https://ift.tt/S4AhDsq [5] https://ift.tt/SYMy0Rq [6] https://rivet.gg/docs [7] https://ift.tt/2gUy64E https://ift.tt/hiJdTvX December 20, 2024 at 10:06PM

Show HN: Web worker and polling exp / HN client app https://ift.tt/DMnC4mE

Show HN: Web worker and polling exp / HN client app demo and src inside newstories will be loaded in web worker polling for comments refresh in main thread configurable worker cache https://ift.tt/yiwfebN December 22, 2024 at 01:28AM

Show HN:Free Online Tool to Experience Microsoft's MarkItdown https://ift.tt/Pd54I6i

Show HN:Free Online Tool to Experience Microsoft's MarkItdown https://markitdown.pro December 21, 2024 at 10:43AM

Show HN: openai-realtime-embedded-SDK Build AI assistants on microcontrollers https://ift.tt/U0qtgvD

Show HN: openai-realtime-embedded-SDK Build AI assistants on microcontrollers Hi HN! This is an SDK for ESP32s (microcontrollers) that runs against OpenAI's new WebRTC service [0] My hope is that people can easily add AI to lots of 'real' devices. Wearable devices, speakers around the house, toys etc... You don't have to write any code, just buy a device and set some env variables. If you have any feedback/questions I would love to hear! I hope this kicks off a generation of new interesting devices. If you aren't familiar with WebRTC it can do some magical things. Check out WebRTC for the Curious[1] and would love to talk about all the cool things that does also. [0] https://ift.tt/FKJo1x6 [1] https://ift.tt/btkcoae https://ift.tt/daAZVfX December 18, 2024 at 09:17PM

Show HN: Model Validation Using LLMs https://ift.tt/KwfpTM7

Show HN: Model Validation Using LLMs https://ift.tt/iVxHNuF December 21, 2024 at 12:31AM