>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.
> 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.
They might as well have chosen to journey to an application, that print "Hello World" on the screen, but it would probably have been too obvious a marketing piece.
This 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!
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.
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.)
Sure. For me, the features of StdLib that make it great for building a public-facing service are:
- 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.
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. :)
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.
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.
Requirements analysis done properly it involves more than just checking boxes, there are exploratory exercises like https://www.agilealliance.org/glossary/storymap/ which allow stakeholders, customers and the development team to work together to voice requirements and concerns.
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.
>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.