getezy / ezy

🔥 GUI client for gRPC/gRPC-Web
https://getezy.dev
Mozilla Public License 2.0
974 stars 16 forks source link

Allow importing multiple proto files in one collection #27

Closed AnotiaWang closed 1 year ago

AnotiaWang commented 1 year ago

Is your feature request related to a problem? Please describe.

My project has multiple .proto files in microservices, and I want to test them in one collection, instead of creating several collections with only one .proto file in it.

Describe the solution you'd like

It would be great if ezy supports having more than one proto files in one collection (a little similar to BloomRPC). I think there can be more input fields in the "Create Collection" page, and I can specify all of my proto files there.

Describe alternatives you've considered

Besides allowing multiple proto input, I think it would also be nice if I can specify a directory containing all the needed proto files, and ezy automatically finds and imports the files under that directory.

Btw, thanks for creating such an awesome project.

notmedia commented 1 year ago

@AnotiaWang Hi! Thank you for opening this issue. When I developed this feature I thought that collection was a place of one service/microservice API which means one main protobuf file in import.

I think you made this feature request because adding a few collections at one time is too slow, am I wrong?

Besides allowing multiple proto input, I think it would also be nice if I can specify a directory containing all the needed proto files, and ezy automatically finds and imports the files under that directory.

This is a really interesting feature, but how do you think how we can automatically get the protobuf roots for a few services when scanning the directory? Do we need to define that all .proto in the giving path are different services and they are all roots?

Also, I see here a problem when different service requires different include directories paths.

AnotiaWang commented 1 year ago

I think you made this feature request because adding a few collections at one time is too slow, am I wrong?

Yes, exactly

how do you think how we can automatically get the protobuf roots for a few services when scanning the directory? Do we need to define that all .proto in the giving path are different services and they are all roots?

I can think of two approaches. (I haven't tried developing with Electron so far, but I guess these are possible)

One way is to let users manually provide all their import paths, and notify them if they missed some paths and caused error while importing.

A more automatic way is to read the content of each .proto file, and check their import statements. If the service imports custom .proto files other than the built-in ones, we add the path of that file to import path.

Also, I see here a problem when different service requires different include directories paths.

I just had a look at the source code of BloomRPC (here and here), seems that they simply included all import paths for every file 😂

Or maybe we can keep a record, with K/V structure like:

{
    "path/to/a.proto": ["path/to/dirnameRequiredByA"],
    "path/to/b.proto": ["path/to/dirnameRequiredByB", "path/to/dirnameAlsoRequiredByB"],
}

where the paths are obtained from the former part I mentioned (the automatic way). Then load protos like

loadProto(filePath, [
    ...commonPaths,
    ...importPathsByUser,
    ...(record[filePath] ?? [])
])

These are my thoughts and suggestions :)

notmedia commented 1 year ago

@AnotiaWang Thanks for your great research!

In the future I have plans to add more complex features to ezy and collections is the first thing that I want to rebuild. I want to make them more customisable (maybe like a folder) which will more simple to solve most of user problems. This rebuild I think closely related to another features like supporting different protocols, not only gRPC. But this will cause a lot of work.

Right now I'm trying to find the best way to simplify creating collections experience as is, I agree with you that current creation flow is slow.

One way is to let users manually provide all their import paths, and notify them if they missed some paths and caused error while importing.

Yeah, manual will work here, but it's not a simple creation flow I think. Also in this way we need to have a table relation view with main .proto file and included directories for it (table inside table)..

I have got an idea while reading your message. What if in create collection modal we will have a checkbox "create more". When this checkbox checked and the user clicks on create button we will not close the modal and only clear name and Protobuf path fields. So Include directories field will stay and the user don't need to fill it again with same values. For example like Linear did:

image

The second idea here is to make a select button near Include directories field where the user can choose from what already created collection he wants to prefill values.

A more automatic way is to read the content of each .proto file, and check their import statements. If the service imports custom .proto files other than the built-in ones, we add the path of that file to import path.

I'm afraid that this solution may be not suitable for every cases. It's kindly difficult to make universal proto parser for such thing. Maybe we could scan folder and make a suggestions that user can modify then.

I just had a look at the source code of BloomRPC (here and here), seems that they simply included all import paths for every file 😂

Yeah, this is what I'm talking about. I think this solution could make a problems

I saw you have connected to discord ezy channel, maybe we could talk there about your working flow. This will help me to understand ezy users needs :)

AnotiaWang commented 1 year ago

Okay, headed to Discord

notmedia commented 1 year ago

After our discussion in this issue will be implemented: