
An API Journey: From Idea to Deployment the Agile Way - rterzi
https://developers.redhat.com/blog/2018/04/11/api-journey-idea-deployment-agile-part1/
======
barbegal
What 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.

~~~
ams6110
> 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.

------
keithwhor
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!

[1] [https://stdlib.com/](https://stdlib.com/)

[2] [https://stdlib.com/@messagebird/](https://stdlib.com/@messagebird/)

~~~
dwilding
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/](https://webtask.io/)

~~~
keithwhor
Wow, thank you! Very glad we can help.

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.)

~~~
dwilding
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.

Hope this feeeback is helpful!

~~~
keithwhor
This is awesome! Thanks for the feedback.

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. :)

~~~
dwilding
That would be brilliant. Thank you so much!

------
ratpik
Disclaimer - 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.

[https://www.getpostman.com/products](https://www.getpostman.com/products)

~~~
barbegal
You should probably disclose that you work for Postman.

------
throwaway13337
Marketing piece with marketing comments on hn on the marketing piece.

It's marketing all the way down.

------
marichards
How is this agile? Where is the requirements analysis? Where is the design?
Where is the process? Where is the documentation?

~~~
UK-Al05
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.

~~~
marichards
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.

~~~
UK-Al05
Secruirity as formal requirements analysis is often awful anyway. Often just a
checkbox exercise.

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?

~~~
marichards
Requirements analysis done properly it involves more than just checking boxes,
there are exploratory exercises like
[https://www.agilealliance.org/glossary/storymap/](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](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.

~~~
UK-Al05
I wouldn't class user story mapping as formal requirements analysis.

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.

