I wonder if Google is going to extend this https://fuchsia.dev/fuchsia-src/development/languages/fidl for other consoles...
Smithy: A language for defining services and SDKs
41–50 of 77 posts
Re: Smithy: A language for defining services and SDKs
#42We'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.
This is some impressive stuff! Congrats on a sizable achievement. I just went through your website, have a few questions...
Questions:
1. SCALA: is the generated code ONLY scala? are other languages supported?
2. CODE-GEN: is it designed only for code generation for a target http framework or does it actually provide an "API Server" itself ( e.g. like graphQL )
3. COMPARISON: the list of frustrations with other solutions, listed in your intro/technology goals are somewhat high-level. what are the "leaky abstractions" or "non-deterministic behaviour"?
4. SETUP: does someone need to know scala to use this ? ( depends on #1 above )
5. DSL : is the protoforce code implemented as a DSL in Scala or its a "language" in itself?
6. IDE : how do you check/compile the code? does it integrated with an IDE?
As a Scala Engineer myself ( though I mostly work in Kotlin now for Android/Server ), this looks great, but most Scala engineers i've met are focused on Spark, and using Play Framework/Http4S, etc. How big is the actual market for Scala API tools?
Re: Smithy: A language for defining services and SDKs
#43We'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.
FYI - your website is an unreadable catastrophe on Firefox for Android.
Re: Smithy: A language for defining services and SDKs
#44This 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 split an OpenAPI specification into multiple files but the tooling never quite deals with it properly.
I'll definitely be keeping an eye on this; looking forward to TypeScript code generation! One of our main use cases for OpenAPI is to document our models and then generate TypeScript types from them (that we then use in Node and React apps)
Re: Smithy: A language for defining services and SDKs
#45We'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.
This is some impressive stuff! Congrats on a sizable achievement. I just went through your website, have a few questions... Questions: 1. SCALA: is the generated code ONLY scala? are other languages supported? 2. CODE-GEN: is it designed only for code generation for a target http framework or does it actually provide an "API Server" itself ( e.g. like graphQL ) 3. COMPARISON: the list of frustrations with other solut…
Thank you.
1. Scala, Typescript/Javascript, and Java at the moment.
2. It does provide the runtime which allows to bootstrap a server easily. (You can check out this post which has modeling + scala setup example at the bottom https://www.protoforce.io/ProtoForce/post/extensive-guide-to...)
3. Please take a look at the documentation, it has a good outline of the features supported. There are many features, most are well documented there.
4. No, not really. You can do with other languages, it provides both client & server sides, so no other language is needed. Again, you can still generate client side stuff for other languages and use them to connect to your server.
5. protoforce website was implemented using the protoforce DSL itself. The parser and transpilers are written in scala. The portal is written in typescript + react.
6. There is currently a sandbox at the website which you can experiment in. There is no currently integration with other IDEs, but language server can be added a bit later for VSCode for instance.
Hope this answers a bit :)
Re: Smithy: A language for defining services and SDKs
#46We'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.
FYI - your website is an unreadable catastrophe on Firefox for Android.
We focused on the desktop because it is difficult to use from mobile due to it being an online IDE. I'll take a look, thank you for reporting.
Re: Smithy: A language for defining services and SDKs
#47what ever did happen to wsdl? ducks
Why duck? WSDL still beats the crap out of most newer would-be contract definition standards. OpenAPI is ok, but the tooling comes from all from the same place.
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 services! (that only worked when you had a full definition of the service on the client side anyhow)
i'd take a wild bet that this stuff at amazon grew out of frustration with soap a long time ago...
edit: read new replies to thread. this is new as of 2018. soap was circa 2002. ah, well.
Re: Smithy: A language for defining services and SDKs
#48Earlier quoted context omitted.
FYI - your website is an unreadable catastrophe on Firefox for Android.
We focused on the desktop because it is difficult to use from mobile due to it being an online IDE. I'll take a look, thank you for reporting.
I get your thought process, but two things:
1. If you use flexbox from the beginning, you can easily have basic readability on mobile.
2. A huge % of users will discover things on mobile, even if those things are desktop apps.
I wasn't even able to tell what your product is at a basic level.
Re: Smithy: A language for defining services and SDKs
#49"The primary difference between Smithy and OpenAPI is that Smithy is protocol-agnostic, allowing Smithy to describe a broader range of services, metadata, and capabilities. Smithy can be used alongside OpenAPI by converting Smithy models to OpenAPI."
How is OpenAPI not "protocol-agnostic" then? And if you can convert to OpenAPI, then OpenAPI must be capable of the same representations.
This demands explanation.
Re: Smithy: A language for defining services and SDKs
#50This 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 use multiple files at work, but all of our make rules first bundle the spec into a single file. We also save that bundle in our VCS. CI will fail if the bundle hasn't been recreated since updating the split files