E2E test with AWS SDK on aws-query/aws-json both

[kojisaikiAtSony]

Here is the PoC of E2E testing aws-query and aws-json in one time with aws-sdk-go and aws-sdk-go-v2 both.

[kojisaikiAtSony]

At current commit, we can see a deserialization error on AWS SDK with aws-json. Since we are responsing XML also on aws-json protocol in current implementation

[kojisaikiAtSony]

At current commit, I supported json response on CreateQueue API. https://github.com/Admiral-Piett/goaws/pull/292/files#diff-acccc2ce70958dc7c057e923106be32a254f07404da8d765e526d0837516f708R45-R53

This doc was helpful 👍 https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-json-api-responses.html

[Admiral-Piett]

Thanks @kojisaikiAtSony! I really appreciate your support here, but give me some time on the CreateQueueV1 piece, that is still in progress from me, and I don't think it's helpful for us to be working at separate ends of it here. I would suggest letting me finish off the rest of the CreateQueue piece if you could - and plowing onward with the SendMessage piece that I noticed you picked up. I have some un-pushed things you haven't seen, but you will as soon as I can manage it - if we start tripping on each other here it's going to be a mess in a rebase.

Thanks for also looking at the json response handling - I am also looking at that, and I have a pattern in mind. I need to finalize some of my abilities to test against it with an SDK, but I'm working through some complexities on my local machine. I will get there soon though - hoping by the end of the week.

In terms of the servertest stuff - as far as I can tell that does look like sort of an integration test suite, but it's calling the services functions directly and I'd prefer something more external for this purpose. We can revamp the Smoke Tests to be whatever we need - and maybe plug in the sdk instead of this httpexpect library or a combination if needed.

I like your idea about the sdk versioning but I wouldn't sweat the old version piece unless you have a path that's really easy. I think we should make this work first for the new JSON mode - and then we can fix up the backward compatibility if we need to. My thinking is that in theory folks who are on the old versions can just use the current release until they're ready to switch.

Thanks again for the support here - it's great work and invaluable! 😄 I'm sorry that this is kind of in a mixed state until I finish off the CreateQueueV1 bits but my hope is that I can put most of pieces we'll need in place to make this work - so that all the future tickets are easier. So I hope it's easier if we split things up by endpoint, so we can divide and conquer. Great work!

[Admiral-Piett]

Actually, I pushed most of what I have now (didn't push the json response yet but I will look into it and get to that) - I had to do both int and string request parsing - during my testing I found different behavior than documented so I think for now, we have to support both - at least for JSON, I don't think we ever did for XML, but if we need to I think we can look at it later.

I also added more smoke tests he smoke tests are failing because there's a memory collision or something as the servers must not be shutting down before the next test starts. But ignore that - you can get an idea about the rest of what's going on I think. See what you think and let me know when you can?

[kojisaikiAtSony]

@Admiral-Piett

In terms of the servertest stuff - as far as I can tell that does look like sort of an integration test suite, but it's calling the services functions directly ...

The servertest looks like that is the same idea as your smoke test. Here is the bootstrap step of the target app for servertest, but it serves HTTP with router.New(). https://github.com/Admiral-Piett/goaws/blob/master/app/servertest/server.go#L59-L61

However the testing granularity and variety are very different with your idea. I agree to renew the test as your smoke test! 👍

[svitcov]

my organization uses goaws for our integration tests, and we had a few quick questions:

1. it sounds like the plan for the near term is to support both XML and JSON APIs. that's an important feature from our perspective since some of our clients are not yet using the JSON API (and it could be a PITA to have to update them). can you confirm if that's the plan?
2. if we wanted to contribute to help out with getting the new JSON API up and running, what would be the best ways for us to do that? not sure if that would be a "too many cooks" situation, or if we would be able to help out...?

thanks :)

[kojisaikiAtSony]

@svitcov

1. Yes, we are aiming to support both XML and JSON APIs. Our latest draft is at https://github.com/Admiral-Piett/goaws/pull/289.

2. We are currently exploring the core idea of ​​a new architecture to support XML and JSON and how to test it. So it might be a good idea to participate in the reviews and suggestions! Once the core idea is agreed upon, it will need to be applied to all SQS/SNS APIs, but I think mass production is needed here, so it would be a blessing if you could provide some help 👍

FYI: @Admiral-Piett

[Admiral-Piett]

@svitcov I guess @kojisaikiAtSony beat me to it, but regardless, yes like they said - we are planning to support JSON and XML formats for the foreseeable future.

I am working through creating a pattern to generically handle both request types, and I'm near to having it workable for now. Once that's complete, we would welcome any and all contributions you can spare. Like Koji said - we'll have to rework all the endpoints. Once I finish the generic code (at least for a start), I will finalize the scope of work for subsequent actions and create a check list so we can track who's doing what.

Thanks for checking in and potentially pitching in. Let me know if you have any questions about the project or anything else!