I found that WebhookPayload.Memo is using a type generated by protobuf. When implementing the webhook, I need to implement the serialization of the Memo type using json.Marshal in webhookPayload.Memo, and when calling the API to update the Memo in Memos, I need to implement the serialization of the Memo type using protojson in the gRPC Gateway again, which is double work.
So, I think it might be better to allow users to implement Webhooks using gRPC. This way, when implementing the webhook, I can directly take the proto file from the repository to generate the types, and I only need to implement a Service myself.
Another simpler method is to use protojson to serialize WebhookPayload.Memo. Since protojson has implementations in multiple languages, the webhook can also directly use the proto file to generate types, and then each language can call its corresponding protojson implementation to deserialize.
In summary:
Allowing the use of gRPC to implement webhooks does not introduce Breaking Changes, but the transformation may be quite challenging.
Using protojson to serialize WebhookPayload.Memo is relatively simple to implement, and I can provide the code if needed. However, this will change the JSON structure after serializing webhookPayload.Memo, which is a Breaking Change.
Personally, I think it would be better to allow the use of gRPC to implement webhooks.
These are just my personal opinions and can be considered for reference.
boojack
commented
5 months ago
Describe the solution you'd like
I found that
WebhookPayload.Memois using a type generated by protobuf. When implementing the webhook, I need to implement the serialization of theMemotype usingjson.MarshalinwebhookPayload.Memo, and when calling the API to update the Memo in Memos, I need to implement the serialization of theMemotype using protojson in the gRPC Gateway again, which is double work.https://github.com/usememos/memos/blob/423861d48c4436539fae1dd88dbcf6e2890efb43/plugin/webhook/webhook.go#L22-L28
https://github.com/usememos/memos/blob/423861d48c4436539fae1dd88dbcf6e2890efb43/plugin/webhook/webhook.go#L39-L42
So, I think it might be better to allow users to implement Webhooks using gRPC. This way, when implementing the webhook, I can directly take the proto file from the repository to generate the types, and I only need to implement a Service myself.
Another simpler method is to use
protojsonto serializeWebhookPayload.Memo. Sinceprotojsonhas implementations in multiple languages, the webhook can also directly use the proto file to generate types, and then each language can call its correspondingprotojsonimplementation to deserialize.In summary:
protojsonto serializeWebhookPayload.Memois relatively simple to implement, and I can provide the code if needed. However, this will change the JSON structure after serializingwebhookPayload.Memo, which is a Breaking Change.Personally, I think it would be better to allow the use of
gRPCto implement webhooks.These are just my personal opinions and can be considered for reference.
我发现
WebhookPayload.Memo使用的是 protobuf 生成的类型。在实现 webhook 时需要实现一遍webhookPayload.Memo中json.Marshal序列化的Memo类型，调用 Memos 的 API 更新 Memo 时又需要实现一遍 gRPC Gateway 中使用的 protojson 序列化的Memo类型，我觉得这是在做双重工作。所以我认为，允许用户使用 gRPC 来实现 Webhook 可能会比较好。这样实现 webhook 时可以直接从仓库中拿到 proto 文件直接生成类型，自己只需实现一个 Service 就好了。
而另一种更简单的方法，就是使用
protojson来对WebhookPayload.Memo序列化，由于protojson在多语言中都有实现，这样 webhook 中也可以直接拿 proto 文件生成类型，再各自调用对应的protojson实现来反序列化。总的来说：
protojson来序列化WebhookPayload.Memo实现起来比较简单，如果有需要的话我可以提供代码。但这样会改动webhookPayload.Memo序列化后的 JSON 结构，是一个 Breaking Change 。我个人认为允许使用
gRPC来实现 webhook 会比较好。这都是我的个人意见，可以参考一下。
Type of feature
API
Additional context
No response