Earlier quoted context omitted.
Thanks for the kind words. We're pretty excited about the platform. For our first sets of APIs we'll probably focus on payment since this is where we've heard consistently that this is a struggle. Either users cannot effectively switch easily or they want to use more than one. So we're focusing there. As for APIs that may not have another solution like Facebook, not sure there's much we can do there. We're offering s…
Another great use case is Analytics. On a recent project we started out using Facebook Analytics, switched to Google (code change everywhere) then wanted to move to MixPanel (again lot of code change). Would be great if there was a single API that allowed me to change the backend API seamlessly. Essentially an abstraction layer.
Apply HN: Brightwork – Making APIs More Intelligent
21–30 of 61 posts
Re: Apply HN: Brightwork – Making APIs More Intelligent
#22You instantly lose points for not supporting HTTPs. Not requesting an invite :(
We will have HTTPS for all services when the beta goes live. Currently, we are just adding people to the waiting list via the website so we didn't feel it was a high priority compared to working on features. However, you have given us something to think about. Thanks for the feedback!
Re: Apply HN: Brightwork – Making APIs More Intelligent
#23You instantly lose points for not supporting HTTPs. Not requesting an invite :(
We will have HTTPS for all services when the beta goes live. Currently, we are just adding people to the waiting list via the website so we didn't feel it was a high priority compare to working on features. However, you have given us something to think about. Thanks for the feedback!
Re: Apply HN: Brightwork – Making APIs More Intelligent
#24Re: Apply HN: Brightwork – Making APIs More Intelligent
#25How much work is it to integrate an new API into brightwork? Will all of my API calls have to be proxied by brightwork? If so, is the only benefit to lock-in the cost projection?
The benefits are to keep analytics on all upstream API calls. If you encounter a problem, with Brightwork you will quickly see if the problem is in your code or an upstream API that stopped responding or has increased latency.
Re: Apply HN: Brightwork – Making APIs More Intelligent
#26What are your main use cases going to be? These are the only ones I can think of where this is going to be "very" useful.. But even so, how often can companies expect to switch between these?
And what's the expectation that Brightwork is going to fail vs expectation that the underlying service (Google, Mailchimp, etc) with a proven track record is going to fail?
Maps Email Analytics
I'm very interested to see how beta turns out. Your success heavily depends on enterprise and developer adoption. The fact that you're also baking in API analytics makes me think that you're likely going to pivot to full-blown API traffic/analytics platform in the next few months (ala Mashery).
We're not seeing much adoption in that space either as service-end products are doing the majority of that work already (ie ELK stack). Very interested to see where you guys go with this.
Re: Apply HN: Brightwork – Making APIs More Intelligent
#27What are your main use cases going to be? These are the only ones I can think of where this is going to be "very" useful.. But even so, how often can companies expect to switch between these? And what's the expectation that Brightwork is going to fail vs expectation that the underlying service (Google, Mailchimp, etc) with a proven track record is going to fail? Maps Email Analytics I'm very interested to see how bet…
This seems too risky with their obstacles ahead.
Re: Apply HN: Brightwork – Making APIs More Intelligent
#28First of all, it does feel like this solves a genuine problem. Despite standards it still feels like every external API is unique. With that said, I'm not sure I 100% grasp what Brightwork does from your description and website. Maybe you could describe a specific use case of how it would help me as a developer? It seems that one of the use cases is easily switching between APIs that serve the same purpose (eg Google…
We feel it's a pretty big problem. Are you familiar with Object Relational Mapping (ORM) in the database world? In the past, we coded our solutions direclty to the database technology (MySQL, Oracle, SQL Server). I think you'll find most modern solutions leverage an ORM to decouple the database. We are doing the same thing with APIs. Think Email, SMS, Push Notifications, Analytics, Payments, Object Storage and on and on. In each of these verticals there a re multiple providers/APIs that offer similar features. Then think about version to version migrations, mobile and IOT devices. The problem space is pretty big.
Re: Apply HN: Brightwork – Making APIs More Intelligent
#29You instantly lose points for not supporting HTTPs. Not requesting an invite :(
We will have HTTPS for all services when the beta goes live. Currently, we are just adding people to the waiting list via the website so we didn't feel it was a high priority compared to working on features. However, you have given us something to think about. Thanks for the feedback!
'josh_carterPDX' claimed beta was open now in a comment earlier. Yet you're just adding people to the waiting list? That seems inconsistent.
Security is always a high priority and a fundamental feature for any stage of business. That is especially true when credentials and authorizations are intertwined.
It is SSL*.
Re: Apply HN: Brightwork – Making APIs More Intelligent
#30Earlier quoted context omitted.
We will have HTTPS for all services when the beta goes live. Currently, we are just adding people to the waiting list via the website so we didn't feel it was a high priority compared to working on features. However, you have given us something to think about. Thanks for the feedback!
'josh_carterPDX' claimed beta was open now in a comment earlier. Yet you're just adding people to the waiting list? That seems inconsistent. Security is always a high priority and a fundamental feature for any stage of business. That is especially true when credentials and authorizations are intertwined. It is SSL*.
The beta is open to some folks that have already signed up. The waitlist is for new beta users. Sorry for the confusion.