Thanks alot for the great talk, was very informative and educative. I wanted to ask why did you base64 encode the json object? are there any benefits for doing that before storing the object in dynamodb?
I was wondering the same thing and after a bit of searching and consultation my conclusion is: don’t do it. It seems like a poor (to put it mildly) idea… Unless there were some particular reasons for a particular system, which obviously have nothing to do with presentation code 🧐
This is a good talk. However, I am not sure why you keep referring that in the Microservices world, I would have to do this and that. Event sourcing and Microservices can go hand in hand. The example that you have shown is about Order information. Well that's a MS. I am sure you would still want to keep your domain's bounded context independent of each other. Also, your consumers of the events themselves could implement tasks which could be again a MS.
Is it possible to share the source code please :) ?
We have all the events at DynamoDB already what is the reason to store also at S3?
dynamodb charges for read and write operations, s3 does not.
Is there any reason lambda calls the firehose and then S3 instead of directly to S3?
It allows him to extract the event data from the dynamodb record and buffer those into a file where each line is an event.
Thanks alot for the great talk, was very informative and educative. I wanted to ask why did you base64 encode the json object? are there any benefits for doing that before storing the object in dynamodb?
Hi Rami, did you find out the benefits of base64 encoding in that case?
@@DawidTomkalski honestly i couldnt find anything other than that dynamodb itself base64 encodes data.
base64 is easier to send over the wire.
I was wondering the same thing and after a bit of searching and consultation my conclusion is: don’t do it. It seems like a poor (to put it mildly) idea… Unless there were some particular reasons for a particular system, which obviously have nothing to do with presentation code 🧐
This is a good talk. However, I am not sure why you keep referring that in the Microservices world, I would have to do this and that. Event sourcing and Microservices can go hand in hand. The example that you have shown is about Order information. Well that's a MS. I am sure you would still want to keep your domain's bounded context independent of each other. Also, your consumers of the events themselves could implement tasks which could be again a MS.
Here's the source code!
github.com/altairsix/eventsource
could you share source code?
We can see the github link in video as github.com/altairsix
Nice content!
just wanted to note: lambda layers make the dependency thing an almost, non-issue.
Similar principles to redux, very cool!
Actually, it's the other way around. CQRS/ES existed way before Flux and Redux.
cloud is all good and great but i will never let them have my business data.