So happy to see support for running durable objects outside of one provider. Upvoted.

The "durable object" concept has been repeatably demonstrated to be a valuable abstraction.

"Each object is its own SQLite database, addressed by name and replicated to an S3-compatible bucket you own" -- this concept can take you a long way, both in its power and simplicity.

One function I've written that I frequently use is a generic iterate function which (in JS/TS land) allows you to loop over a T[], Array, ArrayLike, Iterable, AsyncIterable, including generators and async generators.

It is just easier to always be able to write: "for await (const item of iterate(iterable))" in most places, without worrying about the type of the item I am looping over.

I like the reducers and collectors in your library! Going to try it out.

Also, something new I discovered is the Array.fromAsync() method in JS, which is like Array.from() but for async values. I don't think it is available in all browsers/runtimes yet though.

I think another audience for this is stock market traders and analysts who usually have Bloomberg and other channels up for watching market news.

If you can write a function, you can deploy to the cloud. No infra or deployments to configure or manage. Storage, auth, payments, and more are all built right in.

Currently in beta and TypeScript only but support for all mainstream languages coming soon.

For relational setups this is the way to go though. I prefer the combo approach though - autoincrementing numbers plus a UUID in another column.

I enjoyed the MongoDB analyses. Make sure to check it out too as well as the one for Redis, RethinkDB, and others.

Would be great if there was an analysis done for rqlite/dqlite or turso/libsql at some point in the future.

You could also add a collapse toggle ">" to the classname line that will open the focus view (instead of the keyboard toggle). I think the VSCode API supports it.

- It'll be hosted in our data center in the USA. - It will have 4GB RAM, 20+GB SSD, super fast internet, and lots of bandwidth.

Like getting a Digital Ocean Droplet or an EC2. Except we're hosting it for you for free and you can deploy as many applications as you want to it.

rx is a lightweight CLI and runtime that lets you deploy any function instantly as you save it in your editor. It’s fast, simple, and takes care of setting up all your cloud infrastructure.

Currently I personally host ~20 or so web and scheduled applications on a Raspberry Pi. It just runs in a closet, has a fan on it to keep it cool, and is super fast. I basically never check on it. It is locked down for security, has scripts to automatically run services on restart, and to keep stuff updated.

Way better than dealing with EC2 or Lambda. Lets me ship stuff fast, THEN I can think about scaling later and paying for expensive cloud services and databases (after ACTUALLY having users).

I want more people to experience this! You don't need cloud and microservices and Kubernetes (come on) for everything.

Sign up for the beta here: https://rx.run

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

Points: 5

# Comments: 2

The best dev experience with everything you need built-in: - auth - permissions - payments - secrets - storage - logs - email & SMS - and way more

Related beta launch tweet: https://x.com/KhalidZoabi/status/1777673531972608249

Wanted to show it to you guys, gauge interest, and get some feedback.

There's a large roadmap of upcoming stuff.

Feel free to DM me on X for more information!

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

Points: 8

# Comments: 1

I just tested with yarn, and the same issue exists unless the yarn or npm config option for `script-shell` is set to zsh (like the solution described in the link).

With `script-shell` set to zsh: globstar paths work with subdirectories. Without `script-shell` set (the default on linux): only top-level paths work.

The command I ran was `yarn test` with this test script in the scripts section of package.json: `node --test src/**/*.test.ts`.

I don't want to turn this into a GitHub issue thread, but also didn't want to be dismissive. I hope that helps.

TLDR:

Fixing the issue with globstar paths (`**/*`) not working when running an npm script:

`npm` uses `sh` by default on Linux when running a script with `npm run`. The thing is, if you are using globstar paths in your script, like `node --test src/**/*.test.js`, paths that are more than one-directory-level deep won't be expanded!

This is not an issue with Node.js or npm per say, but with how `sh` works by default. The thing is, this isn't the behavior that most people _expecting_ when setting up their npm scripts.

The link in this submission includes a description of this "pitfall", a resolution for Linux, and some other notes.

I strongly recommend checking your important repositories and CI pipelines for any issues, like tests getting skipped or assets not getting bundled (since their globstar paths are not being picked up by `sh`). Basically just check for any `package.json` that has `**/*` in it. You may also want to check that all your other scripts are being run with bash (with the `shopt globstar` setting set to `on` -- or just use `zsh`).

Sorry for the drama -- but I just _KNOW_ that this is being overlooked all over the place.

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

Points: 1

# Comments: 3

Also, the current theme I'm seeing across many companies is "we have added lots of engineers/products/vendors and we need to focus on building a platform (infra, automation) that lets us ship and not get in the way".

It seems industry went from un-bundling engineers --> sre, devops, network, security, developers --> re-bundling much of this knowledge back into a new role/practice area called "platform engineering".