Closed AnotiaWang closed 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.
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 :)
@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:
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 :)
Okay, headed to Discord
After our discussion in this issue will be implemented:
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.