algorithmmonkey

I'm not knocking what you are doing. I love the effort, and I think it will improve developer experience for the most part. I'm just raising the questions of "Should we have to do this?" and "Didn't we go down this path before?".

The thing that the library is doing, is now replacing a wsdl with an expert that develops a swagger document. This to me sounds problematic. The wsdl had some idea of versioning of the contract, and was dependent on the developer of the service to update the wsdl with updates of their service.

I imagine, and correct me if I'm wrong, but the swagger doc will have to updated by the expert per release of the service (obviously, pending any implementation changes of the service). This actually puts the consumers of the framework at risk of incompatibility via 1., the developer changing the service, and 2., the expert not updating the swagger definition upon 1. Is this accurate?

Please don't take this as me saying that I'd like to go back to wsdls. That is certainly not at all what I'm advocating.

This is really starting to sound like what java / .net were doing with wsdl code generators via soap.

Devs that integrate with multiple apis know there is a problem with the wide range of implementations, from authentication to communication patterns. This makes it a pain to integration with multiple service providers. Without some form a standardization you must have an intermediary library to provide an abstraction.

Are we doing it right?? The community has recognized the problem of non-standard lightweight services to be widespread enough to create a tool to standardize communication with them.

Would something like HAL (http://stateless.co/hal_specification.html) be a start down a path where we can have lightweight services that are also self documenting?

MVC may not be a solid pattern for a client side framework. It makes sense to contain some semblance of state with in the presentation layer on the client side, rather than working with a stateless MVC pattern.

http://www.martinfowler.com/eaaDev/uiArchs.html MVP via M. Fowler seems a little closer to what client side should feel like (imho).

http://en.wikipedia.org/wiki/Model_View_ViewModel MVVM also makes sense for a client side app, which is just an extension of MVP.

IMO MVC on the client side is just a carry over from people who were experienced in writing web apps who wanted something that felt familiar on the client side. It's a leaky abstraction at best.