Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An API Journey: From Idea to Deployment the Agile Way

developers.redhat.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: An API Journey: From Idea to Deployment the Agile Way

#11

Post by keithwhor »

dwilding wrote: post #9
keithwhor wrote: post #7

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 (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://webta…

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

Re: An API Journey: From Idea to Deployment the Agile Way

#12

Post by dwilding »

keithwhor wrote: post #11
dwilding wrote: post #9

Earlier quoted context omitted.

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://webta…

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

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!

Re: An API Journey: From Idea to Deployment the Agile Way

#13

Post by keithwhor »

dwilding wrote: post #12
keithwhor wrote: post #11

Earlier quoted context omitted.

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

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…

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

Re: An API Journey: From Idea to Deployment the Agile Way

#14

Post by dwilding »

keithwhor wrote: post #13
dwilding wrote: post #12

Earlier quoted context omitted.

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…

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 you…

That would be brilliant. Thank you so much!

Re: An API Journey: From Idea to Deployment the Agile Way

#15

Post by donttrack »

barbegal wrote: post #2

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, an…

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.

Re: An API Journey: From Idea to Deployment the Agile Way

#16

Post by UK-Al05 »

marichards wrote: post #10
UK-Al05 wrote: post #8

Earlier quoted context omitted.

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.

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?

Re: An API Journey: From Idea to Deployment the Agile Way

#17

Post by marichards »

UK-Al05 wrote: post #16
marichards wrote: post #10

Earlier quoted context omitted.

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.

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?

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.

Re: An API Journey: From Idea to Deployment the Agile Way

#19

Post by UK-Al05 »

marichards wrote: post #17
UK-Al05 wrote: post #16

Earlier quoted context omitted.

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?

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 ab…

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.

Post reply on HN