Apply HN: Brightwork – Making APIs More Intelligent

Yeah this is definitely something we see value in. We wanted to build a service that provides a higher level of aggregation in which the APIs being used would be exposed to more detailed information. Today many Developers cobble a bunch of solutions to do this today. Everything should be in one place and work as expected.

Very well said. Thank you for the feedback.

Thanks for the kind words.

Q) What is the incentive for your enterprise customers to pay?

A) We have a few enterprise customers we're working with in which they want to take certain parts of our technology and roll it into their internal infrastructure or their own product offerings.

As for where the market will pan out, APIs are becoming more and more prevalent. Companies are starting to charge to access their APIs rather than just make them open to do whatever Developers want. So I don't see APIs going away anytime soon. Whether that's 10 years, 15, etc I really don't know. I believe they'll become more important as we roll into the new realm of VR and IoT.

Q) While building your company, you will develop talent and technology in house that might prove to be more valuable than the product you offer. If this happens, what possible avenues do you see to take your company into more diverse markets? What can you potentially get into?

A) This one is tough to answer because it's a huge hypothetical. Overall we want Brightwork to become a trustworthy platform that makes the development process more efficient and more accessible. Programming is the new literacy and we want Brightwork to be the platform that Developers trust can scale their solutions quickly and reliably.

Q) Do you plan to build an maintain a developer ecosystem around your product? If yes, what do you imagine it will look like?

A) Absolutely! We are setting the pieces together today to build out our Developer Evangelist program. We've all seen other companies do this well and their solutions end up being the "go to" technology. We want Brightwork to be built for and by the Developer Community.

Q) Five years from now, how will you keep your documentation in order keeping in mind that APIs that plug into brightwork will keep changing, be fluid, and not support all international languages that you may have to support for your enterprise customers?

A) We do this by staying ahead of this today and not putting ourselves in a position to fall behind or create documentation that provides no value. I'm a firm believer in more information is better. Today, we're putting together the documentation infrastructure to ensure we can quickly deploy incredible and accurate docs that are meaningful and valuable to the Developer Community.

Q) Are you familiar with the npn and kik stories recently? How would you have handled it assuming you operated strictly under the values you have set for Brightwork?

A) Not specifically familiar with what happened here. Might need some context.

Thanks!

Good questions, I have tried to answer them as simple and complete as possible.

1) I wrote my first API in 1998 to connect field agent laptops to DARPA's web interface for incident management. Been building distributed systems and APIS for private enterprise ever since. Unfortunately, this my first publicly available product.

2) A combination of things, lots of questions here. Major versioning will control access to new features or structural changes in features. Bugs will be patched as often and quickly as possible in a minor release. Obscure documentation problem will be blogged about and then linked into the BW docs. Registered users will receive communication about all the aforementioned items via email or inline in the BW dashboard as notifications.

3) No, at this time we will to support upstream API caching.

4) There are many subsystems involved in BW. Our core is written in NodeJS.

5) Every upstream API endpoint is tracked by BW, we keep audit and metric logs. Each endpoint that requires authentication will interact with Vault (https://www.vaultproject.io) for requesting and storing credentials.

6) There are multiple layers of security with BW. - SSL, to secure the wire - Network (public/private), the only publicly exposed system is the proxy. The proxy is responsible for all traffic in/out of BW. - App Token, All upstream API calls including BW services and 3rd party API services require authentication to the proxy using an app token. The app token is unique to each app you run on BW and using ACL security will allow access to only the services provisioned for that app (data, email, storage, user auth). - User Authentication/ACL, every BW account is secured from one another using ACL security. Audit logs are maintained for all requests made in BW. - Endpoint Security, as mentioned above if you are connecting to an upstream API endpoint that requires a token then BW will use Vault.

Thanks!

I'd like to disagree with the statement that this can "only take a few minutes" by pointing out, done correctly, essentially everything takes 15+ minutes to accomplish.

As far as SSL/TLS you've got to generate a CSR, get it signed, go poke around in your load balancer and/or application server to reconfigure appropriately, and very probably iterate on your cipher list until SSL Labs (or equivalent) looks good.

If that isn't a contentious view, then I'll go further, building a product has hundreds of these "miniscule" tasks (your words) and added together that's significant time. Whilst you might not agree with the prioritisation, the response that they'd prioritised feature work over ticking off this box was at least honest.

Hat tip to the team for communicating so well in this thread.