Recently, our team has starting using http://swagger.io/, which after tweaking a bit how we'd need to work has worked very well for us. The Swagger UI with the prebuilt documentation is quite helpful.
Part of the other reason we started using Swagger was to try and take advantage of Swagger Code Generation, which is the hope of easily generated SDKs. It takes a bit to figure out, but once it is configured it seems to be doing a decent job.
Ultimately, my question is does anyone have experience with Swagger Code Gen, and can speak to their experience with it? We've felt it is a bit of a immature tool (at this stage), and are trying to balance how much is worth either tweaking Swagger Code Gen to get it working or even compromise aspects of our API to get it there.
Thanks
Dan
There's been a lot of improvements to Swagger Codegen since your question in March 2015. More than 300 PRs have been merged. The latest version 2.1.4 was released 2 weeks ago.
There are many examples that developers using it in production. Here is one recent example.
Please give it another try and report here if you've any feedback for the Swagger Codegen community.
Related
In casting my eye around for a good, stable, javascript UI framework I've been drawn to Dojo. In particular, the Dijit set of UI components look really good, and are very good as far as accessibility is concerned.
My question is this: is it worth learning Dojo 1.10 (or at least dabbling and familiarising myself with it) before 2.0 comes out? Or is 2.0 going to be a "throw the baby out the with bath water" complete rewrite?
I could probably learn TypeScript as that would be a useful investment of my time. I'm just eager to start doing something productive in Dojo as I really think 2.0 is going to see a major resurgence of interest and it looks like something I'll want to commit to for 5, 10 years or more (hopefully!). Dojo seems to have stood the test of time well since it came out, and there's no reason to think that 2.0 won't be as stable, either (from what I can tell).
Thanks.
You could get familiar with Dojo Toolit 1.10 and later get updated with the new version.
In my opinion some concept behind Dojo will be remain very similar in the new version, for example:
Modules/Amd, Ajax Deferreds, Promises DOM Basics.
As mention in the Ken's comment usefull source of onformation on dojo 2 can be found here:
dojotoolkit.org/community/roadmap
I've spent the last few days trying to understand if I should use api blueprint, RAML or swagger.
It looks like swagger has the biggest community but the closer I look the more I feel that it greatly lacks in documentation (I was forced to look at the code many times to try and integrate it with my current project), many github issues and stackoverflow questions are unanswered.
Is it possible that I am missing something here?
All I want is a tool to help me write the API documentation and test the endpoints.
Why must swagger become part of the server logic?? If I create swagger files in the editor and then serve them to the UI directly it breaks..
As far as I can tell it even makes the server slightly slower and forces the existence of many clumsily maintained integrations :p What am I missing here?
We're trying to work a lot on improving the documentation of Swagger. It's a bit more difficult when many of the projects are community-driven and not managed by a single organization.
We actually try to reply to issues on github quickly (we don't always succeed) and we have our own google group for general questions so we follow stackoverflow somewhat less.
The editor you mention is a new tool as part of the work on Swagger 2.0 and it's not final yet. As such, it still have a few bugs and missing features. The UI is also in the process of being adapted to Swagger 2.0 and the same limitations apply to it.
You most certainly don't have to integrate it with your server and you can expose the documentation statically. The advantage of integrating it with the server is that it's easier to maintain if the API changes.
You can try RAML + ramlev + Abao
The steps should be
Write API Spec in RAML with your fav editor, ie. Atom, vim
Validate your RAML with ramlev
Implement the server logic according API Spec
Validate server logic with Abao
Looking for some fast, simple and stable RPC library I stumbled upon MessagePack project which seems to be very good. It is also under active development.
If you used it in any way, could you please share your experience?
P.S. I think this question should be community wiki
Well, after some time I found that MessagePack is not well-documented (there was even non-working tutorial in Wiki for Java), there are like 7 outstanding bugs several months old without any replies. Code even is not JavaDoc'ed so that you can take and learn it quickly...
But it seems developer activity there is quite high despite of some outstanding pull requests from the community, that are several months old.
So, well, if GPL suits you, go for ICE. If not... don't know yet. Still looking.
I'm also looking into a fast, cross-platform, cross-language, non-GPL-licensed RPC library.
From looking at the C++ source of MessagePack it seems that it doesn't work on Win32 though, which is a requirement for myself.
Except for that that single item it is on top of my list of serialization/RPC libraries.
http://msgpack.org/ - Win32 missing
http://avro.apache.org/
http://thrift.apache.org/ - Win32 missing
http://bert-rpc.org/
http://www.xmlrpc.com/
http://json-rpc.org/ - GPL license
http://code.google.com/p/protobuf/ - RPC missing
We are in mid of a project where we have used an extended Dojo 1.1.1 to meet the customer requirement and add richness.
But there are quite some bugs and performance problems with this version of Dojo and
we are looking ahead to migrate the Dojo version to overcome both the issues, but the migration cycle seems to be quite painful and may not be yield expected result.
The concern we have is with the various extension which we have created with the version of Dojo for components that were provided in 1.1.1 and the impact on them after migration.But, the advantage we see are equally important.
As per Dojo , they have kept some level of compatibility with version 1.1.1 but i have not seen any discussion around this anywhere.
Has any body else previously done
migrated between Dojo version?
Will the components like Grid will
work as expected or will i need to
carry out a refactoring exercise?
Do we have any commercial support
available as the forum seems to
deprecated?
Any help or suggestions are welcome
Dojo has had a policy of freezing and supporting public APIs since 1.0. Migrations prior to 1.0 were extremely painful. Now, it should be much better, provided you use only public APIs. Code written for stable JS APIs in Dojo or Dijit in 1.1 should largely still work. Exceptions are noted in the release notes, which you should explore (good luck finding them... unfortunately the site is a bit of a mess)
If you wrote any custom widgets, you're probably in for some extra work. dojox.grid was not particularly stable at that point, and it has also seen a major rewrite since then (there is an old 'compat' layer you may wish to use)
Regarding for forum, like the note says, you can either use the active dojo-interest mailing list or post questions here at SO. There are some firms which offer commercial support, but that's outside of the scope of Dojo as an open source project. (try googling 'Dojo commercial support' or asking on dojo-interest)
I have done 5 dojo migrations now (from 0.2 -> 1.4) over the last few years. Although the API does not change, you will often have coded in workarounds that no longer work after upgrading. Things I have noticed:
quality in 1.4 is VERY good and worth
upgrading to (even from 1.3)
although
the API does not change, little
things that are not public often
change slightly (diji.Tree
itemNodeMap -> itemNodesMap in 1.4)
build options are usually added each
release but not always publicised -
strage really as they are always
useful improvement
since you are 1.1.1, you should change all your set attribute calls to 'attr' - this could take a while to do.
As for commercial support, you could try Sitepen
I've enjoyed using the iTunes Store but I'm curious on what it was developed on (PHP & MySQL, Something Custom?).
WebObjects. It comes with XCode these days, but used to cost over $50 000! Not sure about the database backend. I seem to recall reading that it was Oracle, but I don't have a source and may have just accidentally made that up.
Joe Nuxoll former apple employee on the java posse pod cast has mentioned that they use web objects.
#Stephen Darlington is correct, it's WebObjects. The WO code generates pure Java, which is further optimized. The code has been rewritten a couple of times.
Interestingly, Dell's original BYO website was written in WebObjects, the $50,000 version back in 1996.
iTunes store is a mix of a lot of technologies, but the main one is Apple's WebObjects. WebObjects is rock solid java framework including a lot of mature technologies (templating, ORM).
WebObjects is free (correct me if i'm wrong), can be installed virtually on every platform and is not restricted on MacOSX.
WebObjects is mainly developped using eclipse and a plugin called WOLips.
There is a very active community behind this framework and the development tools.
Some links :
The official WebObjects community website
The WebObjects/Wonder/Wolips community wiki
yeah its webObjects, also you can use multiple database sources with WO and you can combine other languages with it such as JS and php
In reality webobjects has been overlooked for some time now, mainly because of its past price and that it has not been well marketed by apple
I think whatever answer you get will be 99% speculation. I would bet that if someone really did work for Apple and did have the facts they wouldn't be allowed to share them.