[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/

[2] 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/

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