some context from the site:
Its main purpose is to allow developers to quickly and dynamically mock API endpoints.
Why mock?
Some reasons to mock endpoints:
The service you want to consume:
is still under development
is not available
and you don’t want to implement the mocking inside your code.
There’s also another interesting point which transforms the DuckRails from a development tool to an actual API (the tool needs a lot of improvements though in order to be used like this in production): Since the mocks can be configured to be dynamic, you can actually wrap your actual endpoint and enhance it with new data, transformations on the original data and whatever else you can think of.
To build a Apache CXF restful project and deploy it to Tomcat takes about an hour. Mocking request and response payloads about another hour. I can make this available to a UI developer under half a day. I can re-use the same code and build a fuller implementation later on. How is this tool gonna help me and where will it make more sense to me? I build many many restful services every Sprint. I want to understand more.
Thanks
@sridhar_kondoji No idea how you build APIs that fast. you'll have to share your secret with us.
Building an API isn't a simple task. I think this is very smart & I see this as valuable for the prototyping stage. You never really know everything that your API needs before you start building. I like that this allows you to prototype/try things out/see how it works before writing code.
Potentially even get feedback from users of the API before deploying it. Once deployed & being used, APIs are very hard to change.
@mscccc Agree, API implementation is not simple. We built Maven archetypes for Spring Restful and Apache CXF projects. The endpoints, request and response contracts are defined part of the design phase, so we add these to our projects and quickly deploy to QA environment for UI developers to consume and code as per the contract. While the UI developer is consuming the deployed webservices (with dummy/mocked implementation), the backend developer will continue to work on implementing the logic of APIs. This task might take longer depending on the complexity. Again a lot of it depends on the process.
We build many many microservices and the above process has helped us. I do see a benefit in Duckrails at design phase and for architects to quickly build something and deploy even before Developers come into picture. I will give it a try for my next sprint project and provide more feedback.
Makerpad
stup
PlanetScale Boost
Twittume
PlanetScale Boost
Twittume