4 ms·

Did you trial the ususal suspects for getting those features you list, eg. REST+WADL, SOAP+WSDL?

by folmar 6y ago

foota 6y ago
I don't think either of these are a usual suspect anymore. I hadn't even heard of these. Maybe these are more common in some parts of the industry.
- tpxl 6y ago
  I haven't used WADL, but WSDL stands for Web Services Definition Language and is an amazing way to define endpoints and messages with type safety. From these you can generate bindings for pretty much any language or protocol that has a generator (and there are plenty, but probably not for the cool kids^TM 'golang' and 'rust'). One of the reasons it fell out of use is XML is verbose and typesafety is not cool anymore.
  - pault 6y ago
    > typesafety is not cool anymore This is rapidly reversing as the javascript ecosystem has increasingly adopted typescript in the last two years. I, for one, refuse to start a new front end without it, and the only other js dev I've spoken with recently who disagreed had never actually used typescript and didn't want to "write a bunch of interfaces like java".
    - ErikBjare 6y ago
      The same goes for Python, where typechecking with mypy is getting pretty popular.
  - folmar 6y ago
    There is a couple for go and at least one for rust, although I don't know how well it fares. It shines more with languages which allow first-class runtime reflection and code loading, but you only care if dealing with runtime-configured services. Also WSDL 2.0 supports REST. I would not say fell out of use, most enterprise-grade apis, old or new, will have one -- think bank/government/big corp. GraphQL is not there yet - as other commenters pointed out the tooling is not good enough outside JS world, security is complicated on the service side, and the protocol is just to young - the official release is two years ago, so it may start appearing just around now.
davidkell 6y ago
I’m not familiar with those solutions in particular. For type safety, many backend frameworks generate OpenAPI specs automatically, and you can generate Typescript stubs based on this. Ditto for gRPC and gRPC web. We use these. But I’ve not seen a replacement for the “application data graph” (but would be interested to learn about them!). The link from @jefflombardjr [0] explains it nicely - it is a great abstraction (in certain situations). Modelling your application data graph is like modelling a good database schema - when you get it right, the rest of the application follows naturally. It’s magical when it works, and I’d happily do it even if it’s just me working on the project. And GraphQL has a great ecosystem, that is the advantage over niche tools. Example - last week we added auto-generated GraphQL types and relationships for Postgres JSON fields, with the help of [1]. No more malformed JSON breaking our app. Note this is all in the context of a web app. Reading other comments, the tooling seems to be less developed on other platforms. And again, without decent tooling (especially for the server) I wouldn’t touch it. [0] https://medium.com/@JeffLombardJr/when-and-why-to-use-graphql-24f6bce4839d https://medium.com/@JeffLombardJr/when-and-why-to-use-graphq... [1] https://github.com/graphql-python/graphene-pydantic https://github.com/graphql-python/graphene-pydantic

Did you trial the ususal suspects for getting those features you list, eg. REST+WADL, SOAP+WSDL?

by folmar 6y ago

Did you trial the ususal suspects for getting those features you list, eg. REST+WADL, SOAP+WSDL?

I don't think either of these are a usual suspect anymore. I hadn't even heard of these. Maybe these are more common in some parts of the industry.

tpxl 6y ago
I haven't used WADL, but WSDL stands for Web Services Definition Language and is an amazing way to define endpoints and messages with type safety. From these you can generate bindings for pretty much any language or protocol that has a generator (and there are plenty, but probably not for the cool kids^TM 'golang' and 'rust'). One of the reasons it fell out of use is XML is verbose and typesafety is not cool anymore.
- pault 6y ago
  > typesafety is not cool anymore This is rapidly reversing as the javascript ecosystem has increasingly adopted typescript in the last two years. I, for one, refuse to start a new front end without it, and the only other js dev I've spoken with recently who disagreed had never actually used typescript and didn't want to "write a bunch of interfaces like java".
  - ErikBjare 6y ago
    The same goes for Python, where typechecking with mypy is getting pretty popular.
- folmar 6y ago
  There is a couple for go and at least one for rust, although I don't know how well it fares. It shines more with languages which allow first-class runtime reflection and code loading, but you only care if dealing with runtime-configured services. Also WSDL 2.0 supports REST. I would not say fell out of use, most enterprise-grade apis, old or new, will have one -- think bank/government/big corp. GraphQL is not there yet - as other commenters pointed out the tooling is not good enough outside JS world, security is complicated on the service side, and the protocol is just to young - the official release is two years ago, so it may start appearing just around now.

davidkell 6y ago

I’m not familiar with those solutions in particular. For type safety, many backend frameworks generate OpenAPI specs automatically, and you can generate Typescript stubs based on this. Ditto for gRPC and gRPC web. We use these. But I’ve not seen a replacement for the “application data graph” (but would be interested to learn about them!). The link from @jefflombardjr [0] explains it nicely - it is a great abstraction (in certain situations). Modelling your application data graph is like modelling a good database schema - when you get it right, the rest of the application follows naturally. It’s magical when it works, and I’d happily do it even if it’s just me working on the project. And GraphQL has a great ecosystem, that is the advantage over niche tools. Example - last week we added auto-generated GraphQL types and relationships for Postgres JSON fields, with the help of [1]. No more malformed JSON breaking our app. Note this is all in the context of a web app. Reading other comments, the tooling seems to be less developed on other platforms. And again, without decent tooling (especially for the server) I wouldn’t touch it. [0] https://medium.com/@JeffLombardJr/when-and-why-to-use-graphql-24f6bce4839d https://medium.com/@JeffLombardJr/when-and-why-to-use-graphq... [1] https://github.com/graphql-python/graphene-pydantic https://github.com/graphql-python/graphene-pydantic