Live data from Hacker News

Smithy: A language for defining services and SDKs

awslabs.github.io

61–70 of 77 posts

Re: Smithy: A language for defining services and SDKs

#61

This looks pretty sweet; I've spent a lot of time the past few years writing a LOT of OpenAPI specifications and the thing that gets tiring is all of the boilerplate with each bit of the definition (paths -> get -> responses -> 200 -> application/json -> schema). It gets so exhausting and turns into nested YAML soup pretty quickly. Having better support for multiple files will also be nice; _technically_ you can spli…

We were bothered by the same thing :) Many plugins for OpenAPI had no codegens which would produce deterministic behavior for compatibility across various languages. Also we wanted to have something that could express complex business domains in definitions.

Ended up building protoforce.io for the very purpose. It does support typescript + nodejs, which we used for the website itself as well.

Re: Smithy: A language for defining services and SDKs

#62
For curiosity and testing what I learned from CocoR https://ssw.jku.at/Research/Projects/Coco/ I created a parser for Smithy that anyone can see/use here https://github.com/awslabs/smithy/issues/793 , also include a transformed ABNF IDL to an EBNF accepted by https://www.bottlecaps.de/rr/ui

Re: Smithy: A language for defining services and SDKs

#63

Smithy, Protoforce, Taxi - is the assumption synchronous request/response? OpenAPI has callbacks ( https://swagger.io/docs/specification/callbacks/ ), I am not seeing that in these others. The other thing I am not seeing is a service registry, eg something like UDDI. How do microservices know about each other? Is that a build over common IDL and a coordinated deploy?

Taxi+Vyne gives you a complete service registry, so both users and systems can discover services and data. Because Taxi lets you describe how data from services relate, Vyne can work out how to connect services together automatically, and handle the integration for you. This is a realisation of the UDDI concept, where systems can autonomously work out how to operate with each other.

Thank you. Your recent blog post (https://blog.vyne.co/rethinking-api-consumer-patterns/ ) was a positively interesting read. I wonder if there's a query analyzer a ways down the road ...

Re: Smithy: A language for defining services and SDKs

#64
post #55
post #47

Earlier quoted context omitted.

soap was a really good interoperability protocol for adding kilobytes of overhead to simple text based rest rpc where interoperability was defined as being able to interoperate with clients and servers from the exact same software environment. trying to get perl to talk to windows or windows to talk to java or java to talk to perl never really worked at all. but wsdl was like this tempting thing. self describing serv…

Apparently this is V2 or even v3 of something internal. So probably V1 did what you were saying :-)

Yup. Smithy is from a lineage of internal tools that have been in use at Amazon since the early 2000s. From my dive into software archaeology at Amazon (I work there), there was a bit of SOAP in use in the 2000s, and some other internal model formats that are now obsolete claimed to be SOAP like. As the years went on, other internal formats came out to replace other formats, until the internal model format became something distantly inspired by SOAP, but very practical and tuned for cross language code generation so it could power AWS (that’s my take at least). That was in use for well over a decade before we built Smithy to improve on and open source the internal format.

Re: Smithy: A language for defining services and SDKs

#65

Smithy, Protoforce, Taxi - is the assumption synchronous request/response? OpenAPI has callbacks ( https://swagger.io/docs/specification/callbacks/ ), I am not seeing that in these others. The other thing I am not seeing is a service registry, eg something like UDDI. How do microservices know about each other? Is that a build over common IDL and a coordinated deploy?

Smithy has something called event streams that send async datagrams: https://awslabs.github.io/smithy/1.0/spec/core/stream-traits....

This is currently used in Amazon S3, Kinesis, Transcribe, and other services.

Smithy doesn’t have a service registry today. However, models can be vended and shared via Maven. Client codegen was designed explicitly to not require coordinated releases of clients and servers (that’s impossible for AWS SDKs).

Re: Smithy: A language for defining services and SDKs

#66

Smithy, Protoforce, Taxi - is the assumption synchronous request/response? OpenAPI has callbacks ( https://swagger.io/docs/specification/callbacks/ ), I am not seeing that in these others. The other thing I am not seeing is a service registry, eg something like UDDI. How do microservices know about each other? Is that a build over common IDL and a coordinated deploy?

Smithy has something called event streams that send async datagrams: https://awslabs.github.io/smithy/1.0/spec/core/stream-traits... . This is currently used in Amazon S3, Kinesis, Transcribe, and other services. Smithy doesn’t have a service registry today. However, models can be vended and shared via Maven. Client codegen was designed explicitly to not require coordinated releases of clients and servers (that’s imp…

Thank you. Some new vocabulary with Smithy: Prelude, Shapes, and Traits (https://awslabs.github.io/smithy/1.0/spec/core/model.html ). With all the evolution, the lineage story would find an audience, I bet.

Re: Smithy: A language for defining services and SDKs

#67
post #32

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.

It's not really a fully finished project yet, so not much. We shipped the AWS SDK for JS v3 with Smithy, the AWS SDK for Go v2 with Smithy, and just launched an alpha of the AWS SDK for Rust using Smithy. More are in the works. We're currently iterating on their code generators to make them easier to use outside the AWS SDKs. AWS SDKs are being built in a layered approach where there's a generic code generator that's…

I gather the impact of Smithy is to generate something like an old style CORBA client/server stubs and vocabulary types for a given serialization, and communication schema (HTTP2, gRPC) in a target language? Is Smithy specific to interoperating with AWS services or can used in pretty much any distributed system?

Re: Smithy: A language for defining services and SDKs

#68
post #67

Earlier quoted context omitted.

It's not really a fully finished project yet, so not much. We shipped the AWS SDK for JS v3 with Smithy, the AWS SDK for Go v2 with Smithy, and just launched an alpha of the AWS SDK for Rust using Smithy. More are in the works. We're currently iterating on their code generators to make them easier to use outside the AWS SDKs. AWS SDKs are being built in a layered approach where there's a generic code generator that's…

I gather the impact of Smithy is to generate something like an old style CORBA client/server stubs and vocabulary types for a given serialization, and communication schema (HTTP2, gRPC) in a target language? Is Smithy specific to interoperating with AWS services or can used in pretty much any distributed system?

Pretty much, but Smithy can be used for anything and isn’t specific to AWS. The AWS modeling support in Smithy is all through extensions that aren’t part of the core.

It’s also protocol agnostic and can be used in a lot of applications (HTTP, MQTT, and we are even experimenting using Smithy to generate C ABI bindings for non client server stuff).

Re: Smithy: A language for defining services and SDKs

#69

This looks pretty sweet; I've spent a lot of time the past few years writing a LOT of OpenAPI specifications and the thing that gets tiring is all of the boilerplate with each bit of the definition (paths -> get -> responses -> 200 -> application/json -> schema). It gets so exhausting and turns into nested YAML soup pretty quickly. Having better support for multiple files will also be nice; _technically_ you can spli…

Hey TranquilMarmot. I am working on a TypeScript code Generator for OpenAPI 2 and 3 that you might be interested in. It works on Node.js and web, provides strong typing (types generated against schema in the OpenAPI definition) and runtime type-checking to prevent the runtime data from deviating from TS types. We have been testing it in private for sometime; clients generated using this Code Generator have already been installed ~50K (and counting). I am looking for feedback so I'd be happy if you could try it out. My email is in my profile.

Re: Smithy: A language for defining services and SDKs

#70
post #14

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…

There’s a Go implementation buried within the V2 SDK.
Post reply on HN