feat: Swap mapping direction #107

sandornagy517 · 2025-12-10T13:48:28Z

Description

To improve loading performance of the mappings page we swap the direction of the data loaded. Until now were were mapping Backstage entities to PagerDuty services, now we swap this and will do the opposite. In this PR I've updated the mappings table to the new Backstage UI table and updated the way we load the data for the component.

Affected plugin

backstage-plugin
backstage-plugin-backend
backstage-plugin-scaffolder-actions
backstage-plugin-entity-processor

Type of change

New feature (non-breaking change which adds functionality)
Fix (non-breaking change which fixes an issue)
Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

I have performed a self-review of this change
Changes have been tested
Changes have been tested in dark theme
Changes are documented
Changes generate no new warnings
PR title follows conventional commit semantics

If this is a breaking change 👇

I have documented the migration process
I have implemented necessary warnings (if it can live side by side)

Acknowledgement

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

jhfgloria

Left some comments. The PR is quite big (and visual), so probably I would need to test it locally to make more sense of it.

jhfgloria · 2026-01-07T16:00:40Z

plugins/backstage-plugin-backend/src/apis/pagerduty.ts

+  await Promise.all(
+    Object.entries(EndpointConfig).map(async ([account, _]) => {
+      services = await Promise.all(
+        ids.map(async id => await getServiceById(id, account)),


I think we should probably use this API instead, because we can do it in one request? https://github.com/PagerDuty/service-search-service/blob/master/apps/api/doc/api/service_directory.md#api-service_directory-list_services

jhfgloria · 2026-01-07T16:06:00Z

plugins/backstage-plugin-backend/src/service/router.ts

-      mapping => mapping.serviceId === service.id,
+      e =>
+        e.integrationKey ===
+        ent?.metadata.annotations?.['pagerduty.com/integration-key'],


Are there any guarantees that at this point the integration-key was set? 🤔 Why not searching by integration-key OR service-id.

jhfgloria · 2026-01-07T16:08:08Z

plugins/backstage-plugin-backend/src/service/router.ts

+      result.mappings.push({
+        entityRef: '',
+        entityName: '',
+        integrationKey: entityMapping?.integrationKey,
+        serviceId: entityMapping?.serviceId ?? '',
+        status: 'NotMapped',
+        serviceName: '',
+        team: '',
+        escalationPolicy: '',
+        serviceUrl: '',
+        account: '',
+      });


Do we need to push this empty state?

jhfgloria · 2026-01-07T16:10:14Z

plugins/backstage-plugin-backend/src/service/router.ts

  });

-  // GET /mapping/entity
-  router.get('/mapping/entity', async (_, response) => {


Please don't remove any methods. Instead mark them as deprecated. There is a chance that people only update the frontend or just the backend and then there will be missing methods.

jhfgloria · 2026-01-07T16:18:00Z

plugins/backstage-plugin/src/components/PagerDutyPage/MappingsTable/MappingsTable.tsx

+        search: debouncedSearchQuery,
+        searchFields: ['metadata.name', 'spec.owner'],
+      }),
+    staleTime: 5 * 60 * 1000,


Why 5 minutes? 🤔 Is it worth caching at all?

hmm, not sure why did I include this back then, just removed it!

jhfgloria · 2026-01-07T16:20:54Z

plugins/backstage-plugin/src/components/PagerDutyPage/MappingsTable/MappingsTable.tsx

+  const [pageSize, setPageSize] = useState(10);
+  const [searchQuery, setSearchQuery] = useState('');
+  const [debouncedSearchQuery, setDebouncedSearchQuery] = useState('');
+  useDebounce(() => setDebouncedSearchQuery(searchQuery), 500, [searchQuery]);


Use debounce used like this is so awkward... Shouldn't it return something? What's the point of the hook at all? 🤔

plugins/backstage-plugin/src/components/PagerDutyPage/MappingsTable/StatusCell.tsx

plugins/backstage-plugin-backend/src/apis/pagerduty.ts

jhfgloria · 2026-01-15T14:35:17Z

plugins/backstage-plugin-backend/src/apis/pagerduty.ts

  }
 }

+export async function getServicesByIdsServiceDirectory(


I don't think we need to expose the calling service from PagerDuty. getServicesByIdsAndAccount would be more readable and not expose the fact that the call is made to ServicesDirectory.

jhfgloria · 2026-01-15T14:53:30Z

plugins/backstage-plugin-backend/src/service/router.ts

+          };
+
+          const formattedEntity = {
+            name: entity?.metadata?.name,


Why would the entity be null? Doesn't it come from the catalog API? Also, if it is null would be better practice to early return here, instead of dragging the ? around forever?

jhfgloria · 2026-01-15T14:56:47Z

plugins/backstage-plugin-backend/src/service/router.ts

+            const foundServices = pagerDutyServices.filter(
+              s => s.id === serviceId,
+            );
+            if (foundServices.length > 0) {
+              service = foundServices[0];
+            }


Suggested change

const foundServices = pagerDutyServices.filter(

s => s.id === serviceId,

);

if (foundServices.length > 0) {

service = foundServices[0];

}

service = pagerDutyServices.find(s => s.id === serviceId);

jhfgloria · 2026-01-15T14:57:46Z

plugins/backstage-plugin-backend/src/service/router.ts

+                account,
+              );
+            } catch (e) {
+              // Service might not exist, just continue


I think this type of error is only valid if the error is a 404. Otherwise you will not know if there is a map or not and could decide to map something else.

jhfgloria

LGTM! Let's just make some tests in the ServiceMappingComponent (I think it is the topmost component) and test the router.ts new endpoint (which I also think is the topmost backend piece of software). There is no tests in the PR and I think there should be.

sandornagy517 requested a review from a team as a code owner December 10, 2025 13:48

sandornagy517 changed the base branch from main to next December 10, 2025 13:48

jhfgloria reviewed Jan 7, 2026

View reviewed changes

jhfgloria force-pushed the next branch from bb72be1 to 597db0e Compare January 14, 2026 11:56

jhfgloria reviewed Jan 15, 2026

View reviewed changes

jhfgloria requested changes Jan 20, 2026

View reviewed changes

sandornagy517 force-pushed the feat/swap_mapping_direction branch from c38fcb1 to ed2ba57 Compare January 23, 2026 10:54

sandornagy517 added 7 commits January 23, 2026 12:01

feat: Swap service mapping direction

e87a151

feat: Get rid of the old MappingTable

0f9b54f

feat: Use a different API for retrieving PD services

891ba0d

fix: Revert entity mappings

8d98f69

fix: Resolve conflicts

08016cb

fix: Service mapping creation and update

fcd4f9f

feat: Add unit tests

582e3ba

sandornagy517 force-pushed the feat/swap_mapping_direction branch from ed2ba57 to 582e3ba Compare January 23, 2026 11:01

feat: Swap mapping direction #107

Are you sure you want to change the base?

feat: Swap mapping direction #107

Uh oh!

Conversation

sandornagy517 commented Dec 10, 2025

Description

Affected plugin

Type of change

Checklist

Acknowledgement

Uh oh!

jhfgloria left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jhfgloria left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants