We do have some prototypes, but we are yet to venture beyond scaffolding..and honestly, we are more focused to provide basic, universal tooling and let respective communities to handle their-favorite-language/framework bindings.
From what I tried, it is fairly easy to get "almost there", but the remaining 10% is dealbreaker. If too much editing constraints are placed on resulting application, it feels odd and it's easy to break them and thus diverge from original blueprint.
One possible approach is to maintain original blueprint, then say "Let us implement" and completely blueprint as "primary data source" into scaffolded application -- into module/method docstrings and start generating blueprint back from there.
However, we are yet to find something that feels unobstrusive and natural during whole development cycle. Suggestions certainly welcome.
Right on. In our particular case, we have an API that's fairly well built-out, so I would probably toy around with this on the next side project.
Rather than having a 100% there solution that's opaque, I think the cool thing would be to have an open source project that handles the boilerplate.
Then, you could fork, point to your blueprint, and deploy in minutes and then do whatever tweaking is required to cover the remaining 10% (there's always something).
Keep up the great work--I am definitely interested (and will check out swagger, as well!).
From what I tried, it is fairly easy to get "almost there", but the remaining 10% is dealbreaker. If too much editing constraints are placed on resulting application, it feels odd and it's easy to break them and thus diverge from original blueprint.
One possible approach is to maintain original blueprint, then say "Let us implement" and completely blueprint as "primary data source" into scaffolded application -- into module/method docstrings and start generating blueprint back from there.
However, we are yet to find something that feels unobstrusive and natural during whole development cycle. Suggestions certainly welcome.