Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Smithy: A language for defining services and SDKs

awslabs.github.io

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Smithy: A language for defining services and SDKs

#71

Post by donavanm »

troelsSteegin wrote: post #56

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?

Its not exactly what youre atter but smithy has waiters https://awslabs.github.io/smithy/1.0/spec/waiters.html

> Waiters are a client-side abstraction used to poll a resource until a desired state is reached, or until it is determined that the resource will never enter into the desired state.

I havent seen them put behind an async interface but it seems like a good match for a lot of StartWork, DescribeWork(token) patterns.

Re: Smithy: A language for defining services and SDKs

#72

Post by donavanm »

TranquilMarmot wrote: post #44

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…

Ive used a bit of smithy at work. Yes, composable models, projections, and transforms are super common. Think joining multiple microservices in to a single public interface or splitting out different service/client models based on tags or traits. Most of this is handled by build infrastructure so it takes some mental energy to setup but then it “just works.”

Note: Principal at AWS.

Re: Smithy: A language for defining services and SDKs

#73

Post by fanylad »

TranquilMarmot wrote: post #44

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…

To generate TS code given an OpenAPI specification, you may want to try OpenAPI Generator[1] and NSwag[2], which work in our cases but your mileage may vary. Both projects allow template customization to meet different requirements.

[1] https://github.com/OpenAPITools/openapi-generator

[2] https://github.com/RicoSuter/NSwag

Re: Smithy: A language for defining services and SDKs

#74

Post by fanylad »

RideAndWave wrote: post #29

We've built a similar thing at https://www.protoforce.io , which auto-generates client and server side. It actually transpiles, parsing the models definitions and emits actual code with a bit of shared runtime. Good amazon opened up their stuff, there should be more competition on this front.

> Good amazon opened up their stuff, there should be more competition on this front.

It was actually open-sourced ~2 years ago: https://news.ycombinator.com/item?id=21472080. Good to see the project is still active.

Re: Smithy: A language for defining services and SDKs

#75

Post by phjordon »

lenkite wrote: post #28
mtdowling wrote: post #18

Earlier quoted context omitted.

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…

Does Smith support describing OAuth ?

There's not a trait for it yet, but Smithy is designed to be auth agnostic so new auth traits can be added by anyone. There's a meta-trait called authDefinition[0] that you can apply to your own trait to indicate that it's an auth trait. With that your trait would show up anywhere else auth traits are found in the Smithy tooling. We're designing the code generators to be extensible enough that you could then fairly easily implement just the necessary bits.

[0]: https://awslabs.github.io/smithy/1.0/spec/core/auth-traits.h...

Re: Smithy: A language for defining services and SDKs

#76

Post by thex »

I understand that codegen is not yet "mature"nevertheless it would be great to have some insight how code generation is intended to be done. It would really be cool if there was a "simple" code gen example using a nice templateing engine.

Any timeline for "basic" codegen availability? (C++, JS, go, rust, etc. Will it be weeks, months, years?

Also an example for serialization would be nice. How would one be defining a service that can be interacted with via multiple transports? (HTTP/MQTT/UDP in one description for example) My current guess would be that you have to establish traits specifying the details or is there some equivalent to a Franca IDL deployment description?

Re: Smithy: A language for defining services and SDKs

#77

Post by jonhohle »

aszen wrote: post #15
inshadows wrote: post #12

Earlier quoted context omitted.

> while Smithy is just an idl used to describe services What's the use of such descriptions aside from diagrams? I realize there's e.g. terraform that use similar kind of language to describe what to create/destroy.

The main use case is to auto generate clients for services and even create stubs for service implementations. AWS sdks need to be implemented in dozens of languages so something like Smithy helps in code gen for multiple languages, avoiding the massively manual task of creating client apis.

Amazon has done this internally across several different iterations and it's fantastic. Being able to write a service definition and object model and then generating clients and service stubs makes it easy to model what client/server interaction will look like apart from implementation. When I was there, there were at least 3 protocol representations that you could expose for the same model, make it simple to support a variety of use cases.
Post reply on HN