• X4 (unregistered)

    public class FristCommentRequest extends AmazonWebServiceRequest {}

  • (nodebb)

    Having a specific function/method is aligned with having a specific endpoint. A change to one (without any direct changes to others) is very unlikely to impact the others...

    IF the alternative (say a parameter) is used, then a change to one, does impact all of them (i.e. execution of different functionality will cause the same code to be executed. This increases risk and the need for more exhaustive testing earlier the game (thing TIA)

  • Richard Barrell (unregistered)

    Seems fine and sensible to me. Aesthetically you might want that split up into more packages so you only bring in a couple hundred at a time but eh there would be costs to doing that too. Server side environments that are going to interact with AWS APIs probably don't care about the size of a measly free thousand class files.

  • (nodebb)

    Generated code is great for situations where you want compile-time validation of adherence to an external interface.

    It would be awesome if the other party supplied you with a native library to compile against, but it's just not realistic to expect this very often. Code generation creates a library that validates the caller against the known parts of the interface contract.

    I've had the argument of "code generated interface" vs. "dynamic binding" many times over my career. Dynamic binding is easier and "cleaner", but it is based on the shaky assumption that the caller is always correct. The purpose of the code generated interface is to actually validate the caller to some extent. No generated interface will catch all of the interface implementation details, but the templates can be updated to catch the things that go wrong most often. This is really just an extension of the static/dynamic language argument, and you'll find people lining up on both sides of it.

    However, the lamest criticism I've heard yet is "There's too much generated code". Any uncalled code will either be left out by the compiler, ignored by the jitter, or at least never take up valuable cache space.

  • Paul (unregistered)

    The AWS SDK uses generated code- because the whole SDK is generated based on a published API specification. This lets them maintain SDKs for a bunch of programming languages, and not worry about keeping them at feature parity with each other and the underlying API. The stuff is ugly- but it is probably the best solution to a hard problem.

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    I'm sure that [...] your average SDK user is never going to need to directly interact with any of these classes

    Sorry Remy, but this is not really a WTF. At most, the generated javadocs are a WTF, since it's not helping anyone to list 7000 request and response types there. Your average SDK user is going to directly interact with these classes.

    The general workflow is:

    1. Instantiate your service client object (e.g. S3Client for S3)
    2. Instantiate your Request object of the appropriate type
    3. Fill out all the fields for each of the request parameters
    4. Send the request
    5. Examine the fields in the returned Response object of the appropriate type

    Stolen directly from the SDK examples:

    PutObjectRequest objectRequest = PutObjectRequest.builder()
        .bucket(bucketName)
        .key(key)
        .build();

s3.putObject(objectRequest, RequestBody.fromByteBuffer(getRandomByteBuffer(10_000)));

    (This example ignores the PutObjectResponse returned, but you can easily imagine capturing and inspecting that.)

  • Naomi (unregistered)

    This seems less like a WTF and more like an interesting bit of trivia/discussion fodder. And frankly, I enjoy that just as much as the more mainstream WTF articles.

    Incidentally, @Generated makes this definitely Java, which has first-class support for code generation through the annotation processor API. There are some really cool libraries using it. My favorite has to be Dagger 2, which does compile-time dependency injection, but there are also AP-based type system extensions (yes, you could always write a wrapper class, but something like @Regex String is so much easier to work with than some RegexString). On the other hand, you've got things like the Hibernate ORM that will implement your interfaces for you. I wouldn't be surprised if C# (or would that be .NET in general?) has some similar constructions, but I don't feel qualified to speak to it. I guess all I'm trying to say is, code generation is great for automatically implementing APIs, but framing the discussion in terms of that misses out on the other things it can do.

  • Kurt Duncan (unregistered)

    I think the code smell is that there are thousands of differing requests... I can understand a couple hundred or so... but thousands? It seems to me that the API itself is not well-considered.

  • kdgregory (unregistered)

    it hints as missed abstractions

    AmazonWebServiceRequest is the abstraction. The various subclasses are specializations to support the close-to-200 services that AWS supports.

    Or would you prefer that people generate the HTTP(S) requests themselves?

  • linepro (unregistered)

    Ah yes

    • Inheritance
    • Delegation
    • Generation
    • Copypasta

    The eternal software triangle....

  • (nodebb) in reply to Paul

    The stuff is ugly- but it is probably the best solution to a hard problem.

    I'd say the "best" solution is to publish a native client library and reference implementation for every supported client language. What they did is a compromise that is solid and doesn't require a lot of labor on their part.

  • Anon (unregistered)

    I remember when I found a database with over 9000 tables, the company wanted a new reported, they had to hire the original developer just for him to say where the required data was.

  • (nodebb)

    I'd list the 129 duplicate "TagResourceRequest"s (and the "TagResourcesRequest" that immediately follows them, but I discovered a post size limit even before getting on to the corresponding "UntagResourceRequest"s, and you can probably generate them yourself.

    Addendum 2021-01-04 17:44: Which is to say that there is another layer of abstraction: the different services themselves (each of which has its own TagResourceRequest class), but that information isn't shown in this generated document. It would have been if AWS had, say, an abstract AmazonEC2ServiceRequest in between.

  • nasch (unregistered)

    "I think the code smell is that there are thousands of differing requests... I can understand a couple hundred or so... but thousands? It seems to me that the API itself is not well-considered."

    Have you seen how many services AWS has these days? If each one has several different operations, it's easy to see how there could be thousands of types of requests.

  • Duke of New York (unregistered)

    You know what I call a class model that generalizes across thousands of concrete use cases added over more than a decade? A SUCCESS.

    A problem with the "code smell" concept is that it encourages people to criticize code before thinking about it.

  • plaquenil sulfate 200 mg (unregistered)

    side effects of chloroquine https://chloroquineorigin.com/# who produces hydroxychloroquine win

  • zgckhu (unregistered)

    hydroxy chloroquine https://keys-chloroquineclinique.com/

  • https://candipharm.com (unregistered)

    best canadian mail order pharmacies for diet pills https://candipharm.com

Leave a comment on “Generated Requests”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article