An API Journey: From Idea to Deployment the Agile Way
developers.redhat.com
developers.redhat.com
>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.
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.
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!
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/
If you don't mind me asking; are there things you like to do with Webtask that you think we could improve with StdLib? You mention a strength of ours is creating public-facing services, but the majority of customer use cases are actually private (internal) APIs. Is there anything we can do to make this more clear? (Edit: I mean more clear as to the ability to do both.)
- I can use my own domain for my service, with the request path mapping neatly onto different functions within my service;
- I can leverage unauthenticated/authenticated requests to allow a certain number of "trial" calls, with users charged a small fee for additional calls.
Something that I think could be a bit clearer would be how to tell from within a service whether a request was authenticated. From reading the docs, I figured the way to do this is to ask for user fields in package.json, then check for user data in the calling context. If this isn't the best way, please let me know!
The reason I'm also using Webtask at the moment is that it's free to set up scheduled jobs. I think that my use case makes this more of a significant concern than it ought to be, so I've dropped you an email to dig into what I'm doing.
Hope this feeeback is helpful!
Yep, that's the best way to check if a request is Authenticated. Alternatively, you can disable unauthenticated requests outright by setting the rate limit to 0 requests allowed via your dashboard.
Yeah; scheduled tasks are a paid feature of StdLib. I received your e-mail and will respond shortly, I don't think it's too difficult for us to allow for the intricacies around your use case. :)
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.
It's marketing all the way down.
The best documention from a Devs perspective are interactive sandboxes with examples.
It won't having good engineers who understand secrurity. Who emdedd it in everything they do.
Yes it is agile. This is what exactly what it means by collaboration in the agile manifesto.
Hackathons have been brilliantly successful for companies exploring new solutions for problems. Why do you think they are so popular?
http://agilemanifesto.org/history.html "The Agile movement is not anti-methodology.." Agile is not about hacking, and the manifesto is not about replacement of one with the other, but about the balance of how you adopt them.
Formal requirements analysis might be too much process, but then on a financial system, it would likely warrant a necessity on accountability requirements put in place by regulators. Looser story mapping alone might be an appropriate balance for a Beer Catalog.
I'm not a fan of a agile, but can we stop recharacterising it as not doing process.
*Not a fan: Having a 3 month support ticket, with multi-level signoff, 100% test coverage, cost codes and invoices per change is a bit much for text change on a website, so Agile does help solve a problem that really does exist in places. But is individual and interactions before process appropriate on medical systems? Agile may fit somewhere in the middle ground (between computer games and nuclear control systems), but it is definitely not a catch all for appropriate ways to work, especially in high risk environments.
Writing code, getting feedback and then adjusting is a process in itself. It's an ooda loop. Probably the most powerful process.
A lot of process distracts from getting in that loop.