220718

_0523

Okay I’ve been do throwing this idea around in my head after getting that reader to work last week. I don’t think I need a Kafka just to use cross service just to send REST request between services. After coming to this concussion. My first thought was damn I wasted a lot of time. Then I tried to rationalize it which I think won out in the end.

• I learned to a small degree how Kafka works and how to integrate it with golang and the package go-kafka. Learning is my main goal of this whole thing, but I would like some at the end I would like to use.
• Kafka already has retry part and scalability built in, but is not really needed at the current state of things.
  • to get the best use of some of these features I would have to send all REST request through them and that just seems silly
• I do think making the kafka reader and writer item could be useful later for items that don’t have a easily implementable REST requirement
• I am still going to have to do the orchestration part of the pattern with sage it self and adding the kafka part right doesn’t seem to add anything of value. SO what I think I am trying to say is adding the kafka messaging between services doesn’t have a huge add at the current state if I am going to just send a REST request.

Now what… I’m the in the middle of the writing the kafka write that and service can use do some basic test to see if works as expected then move on start on the saga pattern it self.

__ _0555

Wtf is a key kafka: I have to keep looking this up for some reason

Straight from the Stack-overflow

“Keys are mostly useful/necessary if you require strong order for a key and are developing something like a state machine. If you require that messages with the same key (for instance, a unique id) are always seen in the correct order, attaching a key to messages will ensure messages with the same key always go to the same partition in a topic. Kafka guarantees order within a partition, but not across partitions in a topic, so alternatively not providing a key - which will result in round-robin distribution across partitions - will not maintain such order…”

So in other other word if First in First Out is the desired give it some uuid.

_ _0832

So the generic kafka writer is complete and seems to work. I was feeling froggy and started to work on for generic reader, but ran into mux. So this I can pass a generic REST mux then fill it out each of the services or create more custom one per service and function carry, but both of those are a good deal of work for something I really don’t plan on using.

I have a working reader made just for the server service with a working mux for both GETs so I’ll leave that code in for now.

_2048

Okay after a sleep I have one more thought on the idea. The Sending REST request to that start of the service would work fine, but it would limit the depth of

220719

_2023 So I am designing the saga pattern in golang and the no real Inheritance is fucking me up.

_220720_0174 220718 _0523

Okay I’ve been do throwing this idea around in my head after getting that reader to work last week. I don’t think I need a Kafka just to use cross service just to send REST request between services. After coming to this concussion. My first thought was damn I wasted a lot of time. Then I tried to rationalize it which I think won out in the end.

I learned to a small degree how Kafka works and how to integrate it with golang and the package go-kafka. Learning is my main goal of this whole thing, but I would like some at the end I would like to use. Kafka already has retry part and scalability built in, but is not really needed at the current state of things. to get the best use of some of these features I would have to send all REST request through them and that just seems silly I do think making the kafka reader and writer item could be useful later for items that don’t have a easily implementable REST requirement I am still going to have to do the orchestration part of the pattern with sage it self and adding the kafka part right doesn’t seem to add anything of value. SO what I think I am trying to say is adding the kafka messaging between services doesn’t have a huge add at the current state if I am going to just send a REST request. Now what… I’m the in the middle of the writing the kafka write that and service can use do some basic test to see if works as expected then move on start on the saga pattern it self.

__ _0555

Wtf is a key kafka: I have to keep looking this up for some reason

Straight from the Stack-overflow

“Keys are mostly useful/necessary if you require strong order for a key and are developing something like a state machine. If you require that messages with the same key (for instance, a unique id) are always seen in the correct order, attaching a key to messages will ensure messages with the same key always go to the same partition in a topic. Kafka guarantees order within a partition, but not across partitions in a topic, so alternatively not providing a key - which will result in round-robin distribution across partitions - will not maintain such order…”

So in other other word if First in First Out is the desired give it some uuid.

_ _0832

So the generic kafka writer is complete and seems to work. I was feeling froggy and started to work on for generic reader, but ran into mux. So this I can pass a generic REST mux then fill it out each of the services or create more custom one per service and function carry, but both of those are a good deal of work for something I really don’t plan on using.

I have a working reader made just for the server service with a working mux for both GETs so I’ll leave that code in for now.

_2048

Okay after a sleep I have one more thought on the idea. The Sending REST request to that start of the service would work fine, but it would limit the depth of

220719 _2023 So I am designing the saga pattern in golang and the no real Inheritance is fucking me up.

_220720_0174 Yes I need all these Tabs

Markdown 3167 bytes 586 words 46 lines Ln 46, Col 61HTML 2407 characters 573 words 27 paragraphs