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

Apply HN: Brightwork – Making APIs More Intelligent

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 61 posts

Re: Apply HN: Brightwork – Making APIs More Intelligent

#11

Post by palakchokshi »

josh_carterPDX wrote: post #6
niklas_a wrote: post #2

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

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.

Re: Apply HN: Brightwork – Making APIs More Intelligent

#12

Post by davemel37 »

> What happens if that API doesn’t work as well or costs too much? That Developer has to dig back into their code, remove dependencies, and recode their application in a process that takes time. Sometimes lots of time.

How would you address these objections regarding the risks of using Brightwork? (i.e. what if you guys go down, get too expensive, stop working, get acquihired, etc...)

Re: Apply HN: Brightwork – Making APIs More Intelligent

#13

Post by [deleted] »

josh_carterPDX wrote: post #6
niklas_a wrote: post #2

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

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…

[deleted]

Re: Apply HN: Brightwork – Making APIs More Intelligent

#14

Post by josh_carterPDX »

davemel37 wrote: post #12

> What happens if that API doesn’t work as well or costs too much? That Developer has to dig back into their code, remove dependencies, and recode their application in a process that takes time. Sometimes lots of time. How would you address these objections regarding the risks of using Brightwork? (i.e. what if you guys go down, get too expensive, stop working, get acquihired, etc...)

Good question. We knew people are feeling anxious about this especially with the whole Parse debacle. Eventually we want to open source this so users can host this instead of us. We're getting good feedback from our Enterprise customers so we'd rather offer this as an open source project to Developers and let the Enterprise help us keep the lights on.

Re: Apply HN: Brightwork – Making APIs More Intelligent

#15

Post by josh_carterPDX »

palakchokshi wrote: post #11
josh_carterPDX wrote: post #6

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.

Yeah we've heard this as a big painpoint as well. We will be offering some basic usage information ourselves that we can abstract, but it would be good to be able to give more flexibility here. Definitely on our roadmap!

Re: Apply HN: Brightwork – Making APIs More Intelligent

#16

Post by palakchokshi »

davemel37 wrote: post #12

> What happens if that API doesn’t work as well or costs too much? That Developer has to dig back into their code, remove dependencies, and recode their application in a process that takes time. Sometimes lots of time. How would you address these objections regarding the risks of using Brightwork? (i.e. what if you guys go down, get too expensive, stop working, get acquihired, etc...)

One way I can think of is to provide clients with their own server so the abstractions can be hosted by the client themselves.

Re: Apply HN: Brightwork – Making APIs More Intelligent

#17

Post by seabass »

hooande wrote: post #10
zzz157 wrote: post #4

You instantly lose points for not supporting HTTPs. Not requesting an invite :(

"Be Nice". https://news.ycombinator.com/item?id=11440627

I expect they'll add it in the future, but given that they intend to begin with payment apis, the service is effectively unusable without SSL.

Re: Apply HN: Brightwork – Making APIs More Intelligent

#20

Post by AkiraMichi »

palakchokshi wrote: post #11
josh_carterPDX wrote: post #6

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.

Wouldn't it make more sense to abstract away the analytics code in your app and write it as an independent entity and then just implement an entity gateway for all the providers you want to support?
Post reply on HN