[proposal] Lightweight API journeys DSL

[vigneshshanmugam]

Summary

Introduce a way to run Lightweight API based journeys that does not involve launching browsers for every run, instead rely on the APIRequest API provided by Playwright core to do Web API testing.

Proposal

The agent will introduce a new API for registering and running these API based checks.

DSL

type APIJourneyOptions = {
  name: string;
  id?: string;
  tags?: string[];
};

type APIJourneyCallback = (options: {
  request: APIRequestContext;
  params: Params;
}) => void;

export { apijourney }

Usage

Users would import this API and configure the tests.

import { apijourney, monitor, expect } from "@elastic/synthetics";

apijourney('test example.com', async ({ request, params }) => {
 // monitor configurations would still work as usual
 monitor.use({ schedule: 10, locations: [ "us_east1"] });

  const resp = await request.get('https://example.com/api/getText', {
    params: { id: params.id },
  });
  const data = resp.json();
  expect(data).toEqual({ text: 'Hello, World!' });
});

difference with journey API and request context exposed.

• Does not require spinning a new browser instance, instead each api journey will create a separate APIRequestContext which have its own cookie storage.
• The request object exposed by the browser journey API does share the same context configurations meaning the cookies will be shared based between API requests and Page requests.

Addresses #137

[jasonwhetton]

Eagerly awaiting this feature.

[dominiqueclarke]

@vigneshshanmugam Do you have an example of the outputted heartbeat documents?

Should we expect, from a UI perspective, that the schema will be identical to typical browser journeys aside from including screenshots? How does this impact network timing for the waterfall chart?

Which parameters can you configure for api journeys that you cannot configure for browser journeys? Which parameters for browser journeys can you configure that you can't for api journeys? Just envisioning the UI form in my head and trying to determine how different it will be from our current browser monitor form.

@drewpost
How do you see us representing this type of UI monitor from a UI perspective? Seems like we'll need to expose a 5th monitor type?

Which data streams do we use? Do we continue to use synthetics-browser datastreams or do we need to introduce 5th datastream for this monitor type?