Investigate moving bundling into a worker

[lottamus]

• Do we need this? Are we going to hit performance issues on the main thread?
• How do we do it without requiring users to use webpack?
• Can we make it work with the raw React distribution?

[P0lip]

Do we need this? Are we going to hit performance issues on the main thread?

yes, for large (say Stripe-sized) documents with plenty of inline $refs or Redfish-like crap with plenty of external $refs (resolving such a document may last seconds)
When I measured it in Studio, it took over a 1s on my machine (my CPU is i7-10875H)

How do we do it without requiring users to use webpack?

we can inline a worker when bundling our own code - this is what we did in case of JSV back in the day

Can we make it work with the raw React distribution?

yes, if we inline the worker's code

You can find some of the answers here as well #575 (comment)

[P0lip]

Tab hangs :P


STR:

• import stripe spec
• open v1/3d_secure path
• click preview

bang, tab freezes

[P0lip]

I can take care of it, as this kind of goes in our way when trying out some YJS stuff.
@lottamus @marbemac @marcelltoth you good with it?

[marbemac]

🤔 why does the tab hang? There are not even any remote $refs in the stripe spec. How long does dereferencing take?

[marcelltoth]

@lottamus @marbemac @marcelltoth you good with it?

If you confirm we have done everything we could - in a reasonable timeframe - to speed up json-schema-ref-parser in the first place, then I guess it's the way to go.

I just want to avoid "throwing hardware" at a problem that could simply be optimized.

[P0lip]

I just want to avoid "throwing hardware" at a problem that could simply be optimized.

Well, same. That's why I questioned the addition of json-schema-ref-parser in first place.
Studio does not need it and it's unnecessarily slowed down by the redundant resolving process.

We can try incorporating APIDevTools/json-schema-ref-parser#195 but still, it's going to take some time regardless. As said, the actual solution would be to avoid the dereferencing entirely.

[P0lip]

FWIW, 195 improves the situation. At least the tab no longer freezes.

[marcelltoth]

Then let's try wrapping up and incorporating that first. If the problem still persists we'll think about other options.

By the way the entire problem is going to go away once we release the new TryIt. It drops the prism dependency completely and will only support mocking for Stoplight-hosted projects.

AFAIK the only thing that really needs dereferencing in elements is the RequestMaker because of this prism-based mocking. If we can drop prism, we can also drop the requirement that Docs is fed with dereferenced data -> problem gone.

This also supports that a short term solution (like the PR you mention) would be enough, and investing a lot of work into workerifying things is not worth it.

[marcelltoth]

By the way in the studio use-case dereferencing actually takes place inside studio. So you can shove it into a worker in any way you'd like. The only place where elements does any dereferencing is inside its public-facing StoplightProject and API components, neither of which are used in platform-internal.

So I'm closing this issue, there's nothing we can do about the studio problem at the elements level and we are working to eliminate the requirement completely with #640 anyway.

[marbemac]

and investing a lot of work into workerifying things is not worth it.

I agree with this and the rest of it 👍.

[P0lip]

By the way the entire problem is going to go away once we release the new TryIt. It drops the prism dependency completely and will only support mocking for Stoplight-hosted projects.

AFAIK the only thing that really needs dereferencing in elements is the RequestMaker because of this prism-based mocking. If we can drop prism, we can also drop the requirement that Docs is fed with dereferenced data -> problem gone.

Oh yeah, totally. If that is going away, we won't need to do anything.