31–40 of 77 posts
What's the difference between the bracketed syntax, e.g. [City] and `list`?
https://awslabs.github.io/smithy/quickstart.html#next-steps
well, what is it? What was autogenerated? I know JAVA from previous jobs, but not Gradle and whatever the Smithy generated artifacts are to be composed with is unclear to me.
Smithy structure definitions don't have field indexes like in protobuf or thrift. It also has required fields, where proto3 intentionally did away with them. How do these differences impact backwards-compatibility-safety of Smithy schema changes?
That said, traits can be used in Smithy to enforce constraints on structures, so if you ever needed explicit indexing like that, it could be done via traits and protocols (Smithy's nomenclature for describing how clients and servers communicate). In fact, protocols are defined by traits, and traits can enforce requirements on the rest of the model using a DSL called selectors... Probably way too much info other than -- it's possible and easy to support this in Smithy if it's ever needed.
As for required vs optional -- today it's treated as server-side validation only and not used in client codegen. This allows service teams to remove the required trait from members if something ends up needing to be optional in future without breaking clients. We're working on some ideas too to see if we can generate even better code for SDKs in languages like Rust where optionality is very explicit, but without sacrificing the ability of being able to remove the required trait.
And, in general, backward compatibility issues are caught with Smithy diff, which also supports custom rules: https://github.com/awslabs/smithy/tree/main/smithy-diff
What's the difference between the bracketed syntax, e.g. [City] and `list`?
list Messages { member: Messages }
Then you can reference Messages from other places in the model, like from a structure:
structure Something { messages: Messages }
In contrast, the `[City]` syntax is used in other places in the IDL to define a relationship to a shape. This isn't something that gets sent over the wire, it's just used to form essentially a relationship in the service graph from a service to resources, a resource to operations, an operation to errors, etc. For example:
service Weather { resources: [City, Sensors] }
Pardon my ignorance: once one gets to: https://awslabs.github.io/smithy/quickstart.html#next-steps well, what is it? What was autogenerated? I know JAVA from previous jobs, but not Gradle and whatever the Smithy generated artifacts are to be composed with is unclear to me.
We're working to get projects like these to GA: https://github.com/awslabs/smithy-typescript, https://github.com/aws/smithy-go, and https://github.com/awslabs/smithy-rs. And we're also working on service code generation.
Reminds me a lot of this talk: https://www.youtube.com/watch?v=j6ow-UemzBc I think it's a really powerful paradigm. I think an org adopting such patterns widespread leads to some really rad capabilities. GDPR compliance, for example, is really tough in SOA architectures in companies without a ton of engineering capacity, but this sort of data/api introspection could do a lot to change that. Any plans to open source p…
what ever did happen to wsdl? ducks
what ever did happen to wsdl? ducks
How does this compare to Google’s protocol buffers? [0] It looks like smithy has a broader set of applications. [0] https://developers.google.com/protocol-buffers
Protobuf and gRPC are great, and AWS will continue to make sure developers can be successful using them with AWS. I’ll try to explain how we ended up at Smithy instead of using other existing tools. We started working on Smithy around 2018 because we wanted to improve the scale of our API program and the AWS SDK team to deal with the growing number of services (over 250 now!) and languages we want to support in offic…