An API Journey: From Idea to Deployment the Agile Way
developers.redhat.com
An API Journey: From Idea to Deployment the Agile Way
1–10 of 19 posts
Re: An API Journey: From Idea to Deployment the Agile Way
#2What about this is agile?
>We can set up the assumption that today, each new application supporting API should be a cloud-ready application. By cloud-ready, we expect that it should have the following properties: The ability to adapt dynamically to the load, A flexible and centralized configuration A dependency discovery mechanism, A native load-balancing mechanism for communicating, Strong resiliency, monitoring, and observability, Automatic log and distributed traces collection
This sounds like over-engineering (the exact behaviour that agile is designed to counter). There is too much focus on tools and processes rather than the working software.
A more agile way would to create a working API with basic tools but in a way that allows adding the extra features (logging and load balancing) at a later date.
Re: An API Journey: From Idea to Deployment the Agile Way
#3Disclaimer - I work at Postman.
IMHO this is a lot of learning overhead.
Postman allows me to design and mock APIs by simply adding my request and saving the example responses I would like my endpoints to return. The request/response format is what is natural to a web developer and does not need learning another DDL like RAML or OpenAPI/Swagger.
The mock url generated can be directly consumed by anyone without needing any local setup and allows decoupling the consumers of the API from the service deployment allowing parallel development tracks i.e being agile. The documentation comes out of the box when you create anything in Postman and can be shared with your API consumers.
I can then use the same Postman Collection to debug and test my APIs and eventually make it a part of my CI/CD process using their Newman CLI tool or just creating a Postman monitor which runs the API specification with tests on a pre defined schedule and notifies you when the tests fail or experience latency issues in production.
Re: An API Journey: From Idea to Deployment the Agile Way
#4What about this is agile? >We can set up the assumption that today, each new application supporting API should be a cloud-ready application. By cloud-ready, we expect that it should have the following properties: The ability to adapt dynamically to the load, A flexible and centralized configuration A dependency discovery mechanism, A native load-balancing mechanism for communicating, Strong resiliency, monitoring, an…
> There is too much focus on tools and processes rather than the working software
That's because this is a marketing piece for Red Hat tools and processes. All you really need to implement the API they describe is a database, a web server, and a few lines of glue in some scripting language or other.
Re: An API Journey: From Idea to Deployment the Agile Way
#5Disclaimer - I work at Postman. IMHO this is a lot of learning overhead. Postman allows me to design and mock APIs by simply adding my request and saving the example responses I would like my endpoints to return. The request/response format is what is natural to a web developer and does not need learning another DDL like RAML or OpenAPI/Swagger. The mock url generated can be directly consumed by anyone without needin…
You should probably disclose that you work for Postman.
Re: An API Journey: From Idea to Deployment the Agile Way
#6How is this agile?
Where is the requirements analysis?
Where is the design?
Where is the process?
Where is the documentation?
Re: An API Journey: From Idea to Deployment the Agile Way
#7This is great! But, to be honest, with innovations in "serverless" web technologies you only need one tool end-to-end for API building, deployment, management, documentation, mocking, logging, rate-limiting, you name it.
StdLib [1] does all of these things, with local command line testing included. Think of it like Lambda + APIG + Postman + Doc Generator + Your Favorite Framework, optimized for shipping functions (Node.js) as infinitely scalable web APIs. For example of an Enterprise-ready API + integration, check out MessageBird's (YCS16) one-line SMS API published on the platform [2].
Disclaimer: I'm the founder. We support tens of thousands of developers at hundreds of companies and we're just getting started. :) I toot our own horn quite a bit here, but always happy to get more of the HN community involved: let me know if you have any questions!
Re: An API Journey: From Idea to Deployment the Agile Way
#8How is this agile? Where is the requirements analysis? Where is the design? Where is the process? Where is the documentation?
I think creating an example API, going back to your customers, asking customers for feedback rinse and repeat is far better than a formal requirements analysis phase.
The best documention from a Devs perspective are interactive sandboxes with examples.
Re: An API Journey: From Idea to Deployment the Agile Way
#9This is great! But, to be honest, with innovations in "serverless" web technologies you only need one tool end-to-end for API building, deployment, management, documentation, mocking, logging, rate-limiting, you name it. StdLib [1] does all of these things, with local command line testing included. Think of it like Lambda + APIG + Postman + Doc Generator + Your Favorite Framework, optimized for shipping functions (No…
I'm building the API for my side project on StdLib, and the experience has been great so far, for many of the reasons you mention - so thank you!
For comparison, I'm also building part of the backend on Webtask [1], which provides similar functionality to StdLib (i.e., serverless Node.js functions). Webtask is also very nice to use, but I find StdLib more suited to shipping a public-facing service.
[1]: https://webtask.io/
Re: An API Journey: From Idea to Deployment the Agile Way
#10How is this agile? Where is the requirements analysis? Where is the design? Where is the process? Where is the documentation?
I think creating an example API, going back to your customers, asking customers for feedback rinse and repeat is far better than a formal requirements analysis phase. The best documention from a Devs perspective are interactive sandboxes with examples.
Functionally that ticks boxes, but it won't tick non-functional boxes of security, resilience, performance, ..., ..., ...
It's very immature to suggest that this is Agile and persists the myths that Agile as a hackathon exercise is okay as a business methodology.