TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Apply HN: Brightwork – Making APIs More Intelligent

64 点作者 josh_carterPDX大约 9 年前
When building an application Developers use APIs to serve different functions. This can be payment, data, social network, push notifications. All of these APIs are pivotal in adding a robust feature set to their application. Some they build themselves, but many are used from existing companies and their platforms. However, using an API is a leap of faith. A Developer uses these APIs perhaps because of its reputation in the Developer community. Perhaps someone has used it in the past and found it to be useful. However, this is genuinely a leap of faith they take to use a tool in their application and trust it implicitly. But what happens when that trust is broken? 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.<p>Meet Brightwork.<p>Brightwork is an API Developer Tool. But it’s so much more. With Brightwork Developers can now see usage information as well as performance information about the APIs they use with their application. They can also see cost projections for their APIs as it relates to competing APIs. However, we take it all a step further. Now Developers can simply click a button in the Brightwork dashboard and switch APIs without having to write one line of code. We do all the heavy lifting in the integration layer and move the API so Developers can spend more time building applications that are agile, meaningful, saves them time, and ultimately money.<p>On top of offering all of this intelligence with their APIs, we’re offering full stack profiles. These are what we’re calling “BrightStacks” but are pre-built API bundles that can be used in their full stack. So instead of programming these services individually, entire stacks can now be turned up in minutes, not hours or days.<p>http:&#x2F;&#x2F;brightwork.io

12 条评论

davemel37大约 9 年前
&gt; 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.<p>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...)
评论 #11443029 未加载
评论 #11443039 未加载
asimuvPR大约 9 年前
I&#x27;ve built something similar. A generic API that abstracts away implementation details of many different APIs into a simple set of endpoints. From my experience:<p>1) What APIs has your team built before that qualifies them to build this?<p>2) How will you manage changes, bugs, and obscure documentation issues in the APIs that will be made available through you?<p>3) Will your API cache results from participating parties?<p>4) What language will the API be written in?<p>5) Regarding API access security: How will you handle access to multiple APIs for the same client when each API requires a different set of tokens?<p>6) What kind of security (aside from having an encrypted connection) will this system have?
评论 #11444867 未加载
amjd大约 9 年前
Clicky: <a href="http:&#x2F;&#x2F;brightwork.io" rel="nofollow">http:&#x2F;&#x2F;brightwork.io</a>
niklas_a大约 9 年前
First of all, it does feel like this solves a genuine problem. Despite standards it still feels like every external API is unique.<p>With that said, I&#x27;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?<p>It seems that one of the use cases is easily switching between APIs that serve the same purpose (eg Google Maps to Mapbox). How big a use case do you think this will be? Ie if I use the Facebook API there&#x27;s is no replacement. I have to use their API if I want to use their platform.
评论 #11443460 未加载
评论 #11442776 未加载
dilippkumar大约 9 年前
This appears to be a very exciting service! I wish you the best.<p>I have some questions:<p>1. What is the incentive for your enterprise customers to pay? If I classify your potential customers as (a)students, (b)hobbyists, (c)freelance developers, (d)startups, (e)small scale operations, (f) large scale operations, my first guess is that groups (a),(b),(c),(d) and (e) would use this service as opposed to building something in home, only (c), (d) and (e) would choose to use a &quot;paid enterprise&quot; solution and only (e) as potentially continuing to pay 5 years down the line. I don&#x27;t see anyone continuing to pay for 10-15 years. I don&#x27;t mean this as a judgement on your idea (it is my uninformed opinion in the end), I just want to hear your thoughts about this and how you think the market will play out.<p>2. 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?<p>3. Do you plan to build an maintain a developer ecosystem around your product? If yes, what do you imagine it will look like?<p>4. 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?<p>5. 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?<p>Thank you, and I wish you and your team the very best!
评论 #11444771 未加载
6thSigma大约 9 年前
If I understand this correctly, Brightwork is essentially acting as a middleman between APIs and the developer. Are you creating new API auth tokens on behalf of each user or are you using only one token and using that to make all of the API calls? If it&#x27;s the latter, how do you handle rate limiting?<p>Is this concept against the terms of third party APIs like Twitter&#x2F;Facebook?
评论 #11447901 未加载
Mandatum大约 9 年前
What are your main use cases going to be? These are the only ones I can think of where this is going to be &quot;very&quot; useful.. But even so, how often can companies expect to switch between these?<p>And what&#x27;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?<p>Maps Email Analytics<p>I&#x27;m very interested to see how beta turns out. Your success heavily depends on enterprise and developer adoption. The fact that you&#x27;re also baking in API analytics makes me think that you&#x27;re likely going to pivot to full-blown API traffic&#x2F;analytics platform in the next few months (ala Mashery).<p>We&#x27;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.
评论 #11443445 未加载
tedmiston大约 9 年前
Obviously this sounds a lot like Segment.<p>One friend who went through a top 10 accelerator pivoted their startup into your idea exactly about a year ago. On the surface it sounds great.<p>It didn&#x27;t work out for a few reasons, but one of the most prominent was: When you abstract an API over several services you end with the lowest common denominator of features (losing anything that makes one better&#x2F;unique... not every category is a commodity).
trjordan大约 9 年前
If I understand correctly, you&#x27;re providing a service where users wire into your API as a generic, switchable layer between their service and the service(s) they want to use. You&#x27;re also providing analytics on top of that, presumably based on the usage from your users.<p>Is there a natural pairing between &quot;monitor my APIs&quot; and &quot;switch between APIs&quot;? I guess what I&#x27;m wondering is, if &quot;monitor my APIs&quot; is valuable, do you have plans to prod them synthetically so you&#x27;re not vulnerable to, e.g. missing an outage because nobody buys things via Stripe at night?
评论 #11444269 未加载
buss大约 9 年前
How much work is it to integrate an new API into brightwork?<p>Will all of my API calls have to be proxied by brightwork? If so, is the only benefit to lock-in the cost projection?
评论 #11442819 未加载
评论 #11443365 未加载
thehorbach大约 9 年前
Do you have any other significant advantage over Stamplay.com, than API stats about the performance? It seems that they are doing the same thing
评论 #11443622 未加载
评论 #11448312 未加载
评论 #11442789 未加载
zzz157大约 9 年前
You instantly lose points for not supporting HTTPs. Not requesting an invite :(
评论 #11442949 未加载
评论 #11443346 未加载
评论 #11442829 未加载
评论 #11443347 未加载