Decouple ui/* from api/* via openapi types #4725

KrumTy · 2025-07-16T12:59:50Z

Issue

Currently we have a lot of typescript issues on the client side. Many of them are due to references to the nestjs api and/or mismatch between api contracts.

What this PR does

It addresses decoupling the ui/* from api/* be leveraging auto generated types based on openapi (swagger).
It shrinks the tsc errors by about 50% (from ~2500 to ~1300) and sets the path for further ts fixes.

Review guide

This PR appears large at first but that's because of the large amount of autogenerated types. Do not review the ui/src/api-client folder

Notes

When an api controller changes (param/dtos/etc), generate-client script needs to be rerun in order to generate the new types for the client. Not sure if this can be automated.
There's an option to split the autogenerated types into multiple files (one per type) but searching through the codebase with so many overlapping file names becomes too hard, so I kept them in one (api/clinet/api.ts)

…into feature/resolve-ts-issues

github-actions · 2025-07-16T13:09:10Z

Code Coverage - Integration Tests

Status	Category	Percentage	Covered / Total
🟢	Statements	81.76%	16250/19874
🟡	Branches	64.83%	7333/11310
🟡	Functions	70.87%	2280/3217
🟢	Lines	81.4%	15283/18774

github-actions · 2025-07-16T14:27:06Z

Code Coverage - Backend unit tests

St.^❔	Category	Percentage	Covered / Total
🟢	Statements	92.36%	13788/14928
🟡	Branches	74%	4143/5599
🟢	Functions	85.96%	2124/2471
🟢	Lines	92.15%	13178/14300

Test suite run success

2940 tests passing in 286 suites.

Report generated by 🧪jest coverage report action from 5c05cfb

github-actions · 2025-07-16T14:36:49Z

Code Coverage - Frontend unit tests

St.^❔	Category	Percentage	Covered / Total
🟢	Statements	81.27%	18867/23214
🟡	Branches	66.93%	8214/12273
🟡	Functions	74.71%	4971/6654
🟢	Lines	81.67%	18468/22612

Test suite run success

4802 tests passing in 631 suites.

Report generated by 🧪jest coverage report action from 5c05cfb

pd-redis · 2025-07-17T08:09:51Z

redisinsight/api/package.json

@@ -172,7 +174,6 @@
    ],
    "moduleNameMapper": {
      "src/(.*)": "<rootDir>/$1",
-      "apiSrc/(.*)": "<rootDir>/$1",


was this unused?

I don't think so

I think we didn't use apiSrc from api folder. so it should be safe to remove

valkirilov · 2025-07-17T08:26:13Z

Great job on this, using an OpenAPI contract to keep services in sync is a solid and widely used approach, especially when different tech stacks are involved or when the code lives in separate repos. In those situations, generating types from Swagger docs makes it easier to keep services aligned and follow the correct communication protocol.

That said, in our case, we're working in a monorepo, and both the backend and frontend use TypeScript. I don't want to sound too negative, but adding a (semi-automatic) code generation tool here feels like extra complexity and might hide the real issue that we don't have a single source of truth for our types.

Instead of adding another layer, I think it would be more effective to focus on fixing the type mismatches directly. We could do this by adjusting how the frontend uses the types, or better yet, by introducing a shared types package (or something similar) so both sides rely on the same definitions.

Another thing to consider is that OpenAPI doesn't always match perfectly with the actual TypeScript code, so I think it's better to stick to the code interfaces as the main source of truth.

That said, if there are plans to move away from the monorepo and split the services, then generating types from Swagger would absolutely make sense, and it will probably be the best approach. I'm not against it overall, just think we should focus on solving the core issue first.

So, I'll be happy to chat more about this so we can agree on which is the best way to reduce these TypeScript errors and resolve the type mismatches between the BE and the FE.

pd-redis · 2025-07-17T08:39:20Z

Great job on this, using an OpenAPI contract to keep services in sync is a solid and widely used approach, especially when different tech stacks are involved or when the code lives in separate repos. In those situations, generating types from Swagger docs makes it easier to keep services aligned and follow the correct communication protocol.

That said, in our case, we're working in a monorepo, and both the backend and frontend use TypeScript. I don't want to sound too negative, but adding a (semi-automatic) code generation tool here feels like extra complexity and might hide the real issue that we don't have a single source of truth for our types.

Instead of adding another layer, I think it would be more effective to focus on fixing the type mismatches directly. We could do this by adjusting how the frontend uses the types, or better yet, by introducing a shared types package (or something similar) so both sides rely on the same definitions.

Another thing to consider is that OpenAPI doesn't always match perfectly with the actual TypeScript code, so I think it's better to stick to the code interfaces as the main source of truth.

That said, if there are plans to move away from the monorepo and split the services, then generating types from Swagger would absolutely make sense, and it will probably be the best approach. I'm not against it overall, just think we should focus on solving the core issue first.

So, I'll be happy to chat more about this so we can agree on which is the best way to reduce these TypeScript errors and resolve the type mismatches between the BE and the FE.

I don't think BE types should be used at all on FE, besides in the apiService.
Many type problems are caused because RedisString can be either string or RedisStringBuffer, and its being used as a string in most places, but in a few it is converted to string or to buffer. However, it is not actually a Buffer, but a data structure with type and data properties - so in this example, I don't think it should be typed as Buffer (it is send like one from BE, but serialized to JSON as plain object), but as:

{
type: string
data: number[]
}

Since we're passing via the API, using the same types is a lie for anything that is not supported by JSON and converting from json to buffer for example is a waste since we don't use it as buffer anywhere

…into feature/resolve-ts-issues

pawelangelow · 2025-07-29T14:46:58Z

What are we going to do here?

KIvanow · 2025-07-30T10:34:57Z

What are we going to do here?

Were the comments from @pd-redis and @valkirilov adressed @KrumTy ?

Before all of the conflicts, were the tests (despite being flaky) passing?

Is anyone against these changes (@ArtemHoruzhenko and @dantovska as only ones not tagged so far)?

ArtemHoruzhenko

Seems like a lot of dto's fields were missed. Well done!

ArtemHoruzhenko · 2025-07-30T12:20:53Z

redisinsight/api/package.json

@@ -172,7 +174,6 @@
    ],
    "moduleNameMapper": {
      "src/(.*)": "<rootDir>/$1",
-      "apiSrc/(.*)": "<rootDir>/$1",


I think we didn't use apiSrc from api folder. so it should be safe to remove

ArtemHoruzhenko · 2025-07-30T12:23:26Z

redisinsight/api/src/common/decorators/redis-string-schema.decorator.ts

+export const REDIS_STRING_SCHEMA = {
+  type: String,
+  oneOf: [
+    { type: 'string' },
+    {
+      type: 'object',
+      properties: {
+        type: { type: 'string', enum: ['Buffer'], example: 'Buffer' },
+        data: {
+          type: 'array',
+          items: { type: 'number' },
+          example: [61, 101, 49],
+        },
+      },
+      required: ['type', 'data'],
+    },
+  ],
+};


Nice! I assume before we had "string" in swagger, right?

It was mostly string yes

ArtemHoruzhenko · 2025-07-30T12:27:32Z

redisinsight/api/src/common/decorators/redis-string-schema.decorator.ts

+export const ApiRedisString = (
+  description: string = undefined,
+  isArray = false,
+  required = true,
+) =>


I feel like it will be better to join isArray and required and send as a second argument {isArray: string, required: boolean}. It will be more flexible/scalable approach.

yeah, I figured I'll get that comment
it was just 2 params until the very end when a 3rd was needed for a few service methods

ArtemHoruzhenko · 2025-07-30T12:29:41Z

redisinsight/api/src/modules/browser/hash/dto/delete.fields-from-hash.dto.ts

-    type: String,
-    isArray: true,
-  })
+  @ApiRedisString('Hash fields', true)


and here it will be clear what we are doing: e.g. @ApiRedisString('Hash fields', { isArray: true })

ArtemHoruzhenko · 2025-07-30T12:40:05Z

redisinsight/api/src/modules/cloud/user/models/cloud-user-account.ts

+  @ApiProperty({
+    description: 'Cloud API key',
+    type: String,
+  })
  capiKey?: string; // api_access_key


fields under 'secure' group are not sent to UI not sure we must include them into swagger

ArtemHoruzhenko · 2025-07-30T12:45:23Z

redisinsight/desktop/src/lib/cloud/cloud-oauth.handlers.ts

+// ref: /api/src/common/constants/user.ts
+const DEFAULT_USER_ID = '1'
+const DEFAULT_SESSION_ID = '1'
+// ref: /api/src/modules/cloud/auth/exceptions/cloud-oauth.unexpected-error.exception.ts


what is ref here? do we have circular deps here?

ArtemHoruzhenko · 2025-07-30T12:47:43Z

redisinsight/ui/src/api-client/common.ts

+/* eslint-disable */
+/**
+ * Redis Insight Backend API
+ * Redis Insight Backend API


twice for those who didn't get 😄

ArtemHoruzhenko · 2025-07-30T12:49:01Z

redisinsight/ui/src/api-client/common.ts

+/**
+ *
+ * @export
+ */


why do we need this?

ArtemHoruzhenko · 2025-07-30T12:59:32Z

redisinsight/ui/src/api-client/docs/AIApi.md

I'm not a big fan of having millions of .md files in our source code. Why we need it?

KrumTy added 27 commits July 14, 2025 14:57

add openapi-generator-cli

bf14313

run generate-client

c7e81a8

update swagger fields

c14b283

use swagger generated dtos/models for some ui components

4e88dce

update swagger docs

08f82aa

update api documentation/swagger types

6f14c82

decouple api src/* from ui

f5aae22

decouple a lot of apiSrc/ references from ui

bc2b1bc

decouple more apiSrc/ from ui

b44b204

update api types

ca69d01

update api types

0f214d6

update api types

d7b481b

use api types

6b01e88

use api types

69d9b76

update api types

9109723

fix types

8cda749

update types

a138eca

update types

6d40ba7

fix more type imports

82c56a5

use more api types

6645547

decouple final apiSrc ui components

4ca94a9

remove apiSrc alias configs

12079de

Merge remote-tracking branch 'origin/fe/feature/RI-7039-replace-eui' …

87a4e31

…into feature/resolve-ts-issues

use single file for api-client

2ed73d6

update eslint configs

5f4a9ae

revert service change

3fbc9d7

fix ui issue

7e45f36

KrumTy changed the title ~~Feature/resolve ts issues~~ Decouple ui/ from api/ via openapi types Jul 16, 2025

KrumTy changed the title ~~Decouple ui/ from api/ via openapi types~~ Decouple ui/* from api/* via openapi types Jul 16, 2025

ignore api-client for jest coverage

07b800a

KrumTy marked this pull request as ready for review July 16, 2025 14:56

KrumTy requested review from pawelangelow, dantovska, ArtemHoruzhenko, pd-redis and KIvanow as code owners July 16, 2025 14:56

pd-redis reviewed Jul 17, 2025

View reviewed changes

Merge remote-tracking branch 'origin/fe/feature/RI-7039-replace-eui' …

5c05cfb

…into feature/resolve-ts-issues

ArtemHoruzhenko reviewed Jul 30, 2025

View reviewed changes

Decouple ui/* from api/* via openapi types #4725

Are you sure you want to change the base?

Decouple ui/* from api/* via openapi types #4725

Conversation

KrumTy commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issue

What this PR does

Review guide

Notes

Uh oh!

github-actions bot commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage - Integration Tests

Uh oh!

github-actions bot commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage - Backend unit tests

Test suite run success

Uh oh!

github-actions bot commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Coverage - Frontend unit tests

Test suite run success

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!

valkirilov commented Jul 17, 2025

Uh oh!

pd-redis commented Jul 17, 2025

Uh oh!

pawelangelow commented Jul 29, 2025

Uh oh!

KIvanow commented Jul 30, 2025

Uh oh!

ArtemHoruzhenko 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!

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!

KrumTy commented Jul 16, 2025 •

edited

Loading

github-actions bot commented Jul 16, 2025 •

edited

Loading

github-actions bot commented Jul 16, 2025 •

edited

Loading

github-actions bot commented Jul 16, 2025 •

edited

Loading