gofrendiasgard / ayanami Goto Github PK

Is your feature request related to a problem? Please describe.
Currently there is no way to set custom header and cookies for response

Describe the solution you'd like
Gateway should also listen to <ID>.trig.response.in.header

Is your feature request related to a problem? Please describe.
This issue is related to #2 .
Instead of implementing <ID>.trig.response.header, we can change the publish & subscribe mechanism instead.

Describe the solution you'd like

• implement PublishRecursively(ID, rawEventName string, data interface{}) error. When publish a data, we should also see, whether the data has subValues or not, and publish subEvent recursively. One possible solution (for map) is provided here: https://play.golang.org/p/BgIu6bfW4ov. Beside map, we should also handle slices: https://play.golang.org/p/7OkRT-SgeGt.

• When service is ready to publish, make check all output event. Is there any common parent event or not. Also, is our event is parent event, or it still have ancestors. For example if we publish: trig.response.in.code and trig.response.in.content, we should also publish trig.response.in. The published data of the last event should be a map, containing code and content.

Read this article: https://dev.to/olibutzki/why-event-sourcing-is-a-microservice-anti-pattern-3mcj

Is your feature request related to a problem? Please describe.
This repo could be intimidating. Some people might just want to know about the service or the generator, not both

Describe the solution you'd like
Keep this repo for the generator, make another repository ayanami-service-go

Describe alternatives you've considered
none

Additional context
none

Is your feature request related to a problem? Please describe.
Gateway and flows actually only need to subscribe into ID based event until a response is generated (e.g: <ID>.trig.response.in.code or <ID>.srvc.<service>.out.<var>). Once the response has been generated, gateway and flows doesn't need to listen to these events anymore.

Having a lot of subscriber could have a performance drawback sometime.

Describe the solution you'd like
There should be a way to unsubscribe from a particular event. Define Unsubscribe in Common broker interface and make our brokers comply the interface

Describe the bug
While nats supporting > and * anywhere, memory broker only support * as the first segment

To Reproduce
Simply create a subscriber in memory broker containing the characters.

Expected behavior
It should behave like nats

Is your feature request related to a problem? Please describe.
Config is not clear enough. Entity is a better term

Describe the solution you'd like
Use entity instead of config

Describe alternatives you've considered
none

Additional context
none