[viraptor]

I'd really like to be positive about it, because there's an interesting concept hiding inside, but... They neither let me play with it, not address the very basically questions I'd ask. It's purely marketing material for a product at this point.

They talk for example about all the great save-is-deploy things and first-class feature flags and I'm still waiting to know how do I not destroy the production database with one typo and how does staging isolation work in this environment. And how do you revert changes? Again, feature flips they talk about are not it.

[pbiggar]

Founder here. This is fair. Dark is still quite early, and while we're talking about it, it's currently got a lot of sharp and ugly parts that we want to tidy up before we go public.

Happy to answer questions on it though - I answered tons of questions about it in the last HN thread.

Some specifics around your questions:

- it would take more than a type to destroy the production DB. You'd need to type DB::deleteAll, then run it (which you'll need to do as an explicit action, either click the "run this function" button, or enable the feature flag to users). We'll eventually have backups so you can undo, but we don't yet.

- staging isolation: there aren't infra questions here since we run the infra. But we'll probably allow DB clones so you can test this sort of thing.

- reverting: That depends on exactly when you want to revert. If you've made a new flag and you want to not do that anymore, just change the flag condition to "false". You can then cancel the flag, or iterate on it. If you instead want to go back to a previous point in time, we've saved every version and you'll be able to pick from them.

[viraptor]

Thank you for answering the questions!

With the staging/deletion, I meant a scenario like this: I'm working on some feature which deletes an item I own. But in a delete condition I put "or" instead of "and" (in a non-obvious place) and the function will delete all records instead when it's run.

In the current development model, this will be caught by:

- me testing it locally (then fixing it and reloading test db)

- maybe reviews

- potentially CI/CD

But with what I understand about Dark, this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.

Backups are ok, but not a solution in this case (you can't just roll back money transactions for example), and the downtime is not great. What system in Dark prevents this from happening in the first place?

[pbiggar]

> this will be close to auto-published on save, and the first person to try the code will delete all entries from a live table/collection.

Ah, that's not how it works. I think you're thinking that you edit code in your editor and then there's this super dangerous deploy. That's not it at all.

When you make new code you open a feature flag. The feature flag doesn't run until you're ready to run it. We haven't dealt with the delicate case, but I'm imagining that we'll let you put a clone of the DB in so that you can test it.

And you can have code reviews and tests and so on while the feature flag is open. Think of it like a branch.