Change #1294286 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/VisualEditor@master] EditCheck headless mode

https://gerrit.wikimedia.org/r/1294286

When a request comes in, a standalone page fetches the HTML for that page (or uses POSTed HTML)

TBD on if we can POST the HTML at all. This would be a nice optimization, but we may be likely to use Linked Artifact Cache for this, which hides the internal 'lambda' API call from us. We can only provide e.g. a revision id as the input parameter.

Let's try fetching the HTML and see how much latency that accounts for. Linked Artifact Cache is a cache, and if we warm the cache quickly enough it is possible the extra html fetch latency will never be felt by the page load.

Also FYI: We are still drafting and thinking about the data architecture for fetching and storing suggestions, but it is possible we will use Linked Artifact Cache (LAC) for this. LAC requires that the backend service/lambda/function respond to requests over gRPC.

I'm not exactly sure how that relates to service-utils, T428174: Standard helm chart for simple service-utils nodejs apps, etc. CC @tchin .

Change #1294286 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] EditCheck headless mode

https://gerrit.wikimedia.org/r/1294286

Hi So!

The current draft recommendation is to used Linked_Artifacts_Cache (see also Hoarde) (the underlying service) to store edit suggestions.

This means that Headless VE (the lambda function) will need to conform to LAC's gRPC API contract.

The design isn't 100% settled yet (I hope we can settle that soon?) but I expect it to be soon, and I think it is quite likely that LAC is the way we will go. Should we make another task for Headless VE gRPC?

cc @Eevans

@Esanders moving this to "Blocked" and reassigning back to you to respond to the question Andrew posed in T428491#12054044.

The design isn't 100% settled yet (I hope we can settle that soon?) but I expect it to be soon, and I think it is quite likely that LAC is the way we will go. Should we make another task for Headless VE gRPC?

I think so.

Hi, sorry, let's take a step back.

Running headless browsers in production is highly problematic from multiple points of view, hard to maintain, and very resource hungry. If we need to do this at all, we are going to have to pick up the concept in T424872 from where it stopped being worked on.

I think we should really look at alternative approaches, if at all possible - as we're already struggling to maintain the only service that uses a headless browser in production.

So, can you please explain clearly why a headless browser is needed in this process? Is there a reason we can't obtain the same results using a pure nodejs service?

If at all possible, we should avoid using full browsers in production.

FWIW, an (undetailed) justification can be found in still WIP Prep Pantry Design doc under Compute: Headless Visual Editor section.

Also:

https://docs.google.com/presentation/d/1H5p7ocYasREJKZLWxfj08DXr08M9CSJKMQzwBFO7Vxk/edit?slide=id.g3d20f852778_0_0#slide=id.g3d20f852778_0_0