That depends on the “world”. We built an adapter interface so you could store the data (and other things) anywhere you want. There are some docs which are wip regarding that: https://useworkflow.dev/docs/deploying/world
Hi I’m Gal from the team. Thanks! We did ship a reference Postgres implementation. It would receive more love now that we open sourced, but we can’t call it “production ready” without running it in production.
But we did have convos in the last couple of days on what we can do next on the pg world ;D
We built Fluid with noisy neighbors(=requests to the same instance) in mind. So because we are a data-driven team, we
1. track metrics and have our own dashboards to ensure we proactively understand and act whenever something like that happens
2. also use these metrics in our routing to smartly know when to scale up. we have tested a lot of variations of all the metrics we gather and things are looking good
anyway, the more workload types we will host with this system, the more we know and the better/performant it will get. we're running this for a while now, and it shows great results.
there's no magic, just data coming from a complex system, fed into a fairly complex system!
hope that answers the question, and thanks for trusting us
So if undertood 1. correctly I could use this solution to potencially save money, but it could turn into a nigthmare very quickly if you guys aren't watching?
Hey there! I plan to open source this soon so the source will be available and you can read it. It is really doing nothing but adding the emoji to GitHub.
But I understand that the shadiest people say they are legit, so I’ll prioritize open sourcing the extension so others can review it :) sounds good?
That is a nice thing to do, but I think people will still be hesitant because there is no way to know whether that code you open-sourced is actually what's in the Chrome Store, or that the Chrome Store listing won't change ownership in the future. (Chrome extensions auto-update, so it's easy to ship users code that does something "new and exciting", and when dealing with software supply chain risk, "new and exciting" is something many people don't want.)
I get that you just wanted to make something cool, and it is very cool, but people are also right to be paranoid here. Compare the value between having a certain tiny image in your PRs versus being able to check code into any organization's Git repo as a trusted engineer at that organization, and how much someone would pay you on the black market for either of those things.
Not to mention that even the data being requested and stored is also organizationally sensitivite if leaked. Everyone's got some problem customer emoji or frustration with their cloud provider in there, which maybe wouldn't look great externally.
Hi! I guess you're `whyboris` from GH. Thanks again for the feedback :D
Just noting that I have added a small piece of documentation. The CLI itself also has `--help` flag, and it works also for every subcommand (`nvm install --help` for instance)
I'm pretty sure `nvm` supports more use cases than fnm right now, as it is a much more mature project. However, it is slower in orders of magnitude.
It does support `.nvmrc` files so my use cases have been fulfilled with fnm - but if yours wasn't implemented yet - you are more than welcome to open an issue and we'll try to tackle it.
Also, fnm is a single executable, therefore it is very easy to install and works across all shells (no need for wrappers in `fish` shells, for instance). Just put it in your path and you're good to go!
Hey! fnm is a very simple and (very) fast node version manager.
On my machine, `nvm init`/`nvm use` takes around 600ms - this means each time you spawn a new shell you have a ~600ms penalty.
The gif on the README is real time (it's a screen recording) - so installations are fast, and every command that works locally is extremely fast.
