I'm happy to take performance improvements. The authorization redact isn't even desirable in my opinion. Coding that at a resolver level that has security wrappers is a better way to go, but it was a quick and dirty demonstration of how you could do things. It had not occurred to me that it would be a performance problem, although it should have, because I've had similar issues with the merge routines. Those leverage the query, and that allows me to stop traversing early when there's a large value that doesn't need walked.

Leveraging the query is the best solution, because when there's a prop in the query you can just stop, and when there's a join, you can pull the subquery and continue. I'm not sure that final would be an answer, because a resolver can technically return nested structure; however, if you're talking about the auto generated resolvers, then having an algorithm that only walks a single level at the resolver would be the best solution, and eliminate the recursive walk all together

I’d be fine with removing the redact as the default as well. as for an alternative fix, I was thinking of not traversing values with ::p/final , as that seems to be how pathom generally tackles this problem, but open to just a single-level traversal as well

should i start with a PR to simply remove the redact call in auto-resolvers?

Breaking change. Need a new option to disable it instead.

ahh yeah sorry

the final idea doesn’t work…because a resolver can return nested data that MIGHT need to be affected

The whole idea of final is to be able to return any arbitrarily complex value of any depth without further processing…but post-processing must apply to that value in this case

otherwise you’re overloading the meaning of final in a way that limits flexibility

(e.g. if I send a password back 3-levels deep in a final result, I’d want the password redacted still)

ahh yeah fair point

Nope.

No way to do that

You can get local synchrony if you want, but mutations that are full stack can't. If you use a single remote, then order is guaranteed.

But there is no way to do remote ops synchronously in js browser

And optimistic actions also guarantee order. Independent of the number or type of remotes.

See also : https://book.fulcrologic.com/#_the_transaction_processing_system

I think the question might be: will mutations run in the order they are defined in a transaction?

For the optimistic parts, yes. For any remote parts: they will be submitted in order, but if more than one remote is involved there's no way for it to guarantee the return order, or even the processing order for that matter.

What about pessimistic transactions? If I understood it right, than this will run and return in order. The next transaction is only run after the last transaction finished. So if you are concerned about the return order then you would have to run pessimistic transactions, wouldn’t you?

Yes I actually wanted to know if they’re run in order. So any mutation involving mutations on the client database will be run in order, right? Things like merge/merge-component!, dr/target-ready , uism/begin!, uism/trigger! ?

correct. There is a guarantee that (the optimistic part, for local client database) mutations are run in the order they are submitted.

They are also submitted to remotes in the order transacted…but Fulcro cannot make guarantees about the arrival order of remote mutations to multiple remotes, or the completion order.

Do you refer to the case, where one mutation has multiple remotes?

Ok. Coming from re-frame, this is actually very enjoyable 😁 thanks for your answers

@U023LKF2PQV A transaction in Fulcro is a vector. Vectors imply a required order. So, a single call to transact! has the semantic of an in-order sequence of operations:

[(f) (g)]

(defmutation f [params]
  (remote1 [_] true)
  (remote2 [_] true))

Two calls to transact! will always be run and queued in the order they are run, but they will be separate transactions as far as the server is concerned. In the case of a single transact! it is therefore possible for you to code an atomic processing of a sequence of mutations in your server code as long as they are run as a single unit. Communication between mutations on the server (e.g. seeing result of the first one in the second) is completely up to you.

(e.g. you could make middleware that starts a transaction on a thread-bound SQL connection, and commit/rollback at the end of the Pathom processing, and have all the Pathom mutations use the thread-bound connection. Intermediate db changes would be visible on that shared connection)

Thanks for that detailed explanation. That makes totally sense. Fulcro is awesome. It handles so much in a sane well designed way :)

Thanks. The most recent fun “remote” I made might be of interest on this thread as well. I made a WebWorkerRemote. It does just what it sounds like. It lets you hook a mutation up to an operation that runs in a WebWorker. So now, given a separate js file that has code I want to run on a thread, I can (transact! this [(some-bgop)]) and it works just like any other Fulcro mutation that has async (remote) operation…but is in fact just running in a thread in the browser. Parameters go to the web worker, and the web worker can respond with progress and final result, which of course merges according to the normal rules of mutations.

That sounds like a super useful abstraction to utilise web workers in your web app 🙂

@tony.kay I wanted to read more about the WebWorkerRemote, but couldn’t find anything. Is this included in Fulcro? Or is there a snippet, which I could use as a starting point?

it’s something I did for a client. Nothing to it really. Write a js web worker. Write a fulcro remote that sends/receives messages to/from it.

A lightweight web worker in vanilla js can just serialize JSON, and the remote you write just translates that to/from EDN.