
Apply HN: Brightwork – Making APIs More Intelligent - josh_carterPDX
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
======
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...)

~~~
josh_carterPDX
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.

~~~
ebbv
This is a great answer and makes me even more intrigued.

------
asimuvPR
I'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:

1) What APIs has your team built before that qualifies them to build this?

2) How will you manage changes, bugs, and obscure documentation issues in the
APIs that will be made available through you?

3) Will your API cache results from participating parties?

4) What language will the API be written in?

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?

6) What kind of security (aside from having an encrypted connection) will this
system have?

~~~
philtaylor
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](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!

~~~
asimuvPR
The answer to the first question is really interesting. We spend so much time
building software and have little to show. Its nice that you are taking the
effort to build something like this. I for one think APIs are still very crude
and need lots of love to evolve into something that we can use without waking
up at 3AM on Wednesday because somebody pushed an update. :)

~~~
josh_carterPDX
Yes to all of this! :)

~~~
asimuvPR
We should email. I'm always researching new API patterns and having real
feedback would be very beneficial. Email in profile. :)

~~~
josh_carterPDX
Absolutely. I'll reach out. Thanks!

------
amjd
Clicky: [http://brightwork.io](http://brightwork.io)

------
niklas_a
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 Maps to Mapbox). How big a use case do you think
this will be? Ie if I use the Facebook API there's is no replacement. I have
to use their API if I want to use their platform.

~~~
philtaylor
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.

~~~
nostrademons
Curiously, I've seen a lot of pushback in recent years (post-2012) on the idea
that you should use an ORM. Many recent apps are firmly in the "pick a
database, use it to its fullest, and stick with it" camp, probably because

a.) a number of new databases have come out recently that don't fit nicely
into the SQL query paradigm

b.) many of the early ORMs (Hibernate, ActiveRecord, etc.) had _terrible_
performance and that unfortunately has tarnished the reputation of all ORMs.

and c.) people try to use an abstraction layer, and then they actually switch
databases and find out that the abstraction layer hasn't actually saved them
any work.

It remains a contentious topic. Most programmers I know who learned to program
in the 2000s think that you're crazy if you don't use an ORM, and setting
yourself up for a lot of pain. Most programmers I know who learned to program
in the 2010s think that you're out of touch if you do, and missing out on many
of the new features in their favorite database. Most programmers I know who
learned to program in the 1980s look on with amusement, because they know that
the tech industry is driven by fads and you're screwed no matter what you do,
so just muddle your way through it as best you can.

Be aware of this as you craft your messaging to different groups: this is not
an effective comparison for the post-Node, post-mobile-app developers I know.

~~~
philtaylor
Very well said. Thank you for the feedback.

------
dilippkumar
This appears to be a very exciting service! I wish you the best.

I have some questions:

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 "paid enterprise" solution and only (e) as potentially
continuing to pay 5 years down the line. I don't see anyone continuing to pay
for 10-15 years. I don'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.

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?

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

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?

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?

Thank you, and I wish you and your team the very best!

~~~
josh_carterPDX
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!

------
6thSigma
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's the latter, how do you handle rate limiting?

Is this concept against the terms of third party APIs like Twitter/Facebook?

~~~
philtaylor
API auth tokens are per user per app.

I have not seen anything in the terms that would put us of of compliance.

------
Mandatum
What 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.

~~~
SwimAway
This seems too risky with their obstacles ahead.

------
tedmiston
Obviously this sounds a lot like Segment.

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.

It didn'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/unique... not
every category is a commodity).

------
trjordan
If I understand correctly, you'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're also providing analytics on top of that,
presumably based on the usage from your users.

Is there a natural pairing between "monitor my APIs" and "switch between
APIs"? I guess what I'm wondering is, if "monitor my APIs" is valuable, do you
have plans to prod them synthetically so you're not vulnerable to, e.g.
missing an outage because nobody buys things via Stripe at night?

~~~
josh_carterPDX
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.

------
buss
How 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?

~~~
josh_carterPDX
It takes less than 30 seconds to standup an API with Brightwork so it's pretty
easy to get going. Our beta is open now if you're interested.

All of the API calls go through Brightwork's API and the benefit is that you
can have all of the information you're looking for in one place rather than
cobbling together a number of solutions to get the same information. In the
Brightwork dashboard you can now see performance (jitter, packet loss, etc),
usage data, and cost projections.

We also have "BrightStacks" which are pre-bundled APIs that allow you to stand
up an entire full stack in minutes.

------
thehorbach
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

~~~
giuliano84
Hey guys, Stamplay's founder here!

It's hard to say by a simple landing page but the service looks quite
different in terms of offering.

The visual workflow builder of Stamplay is just a fraction of the whole
offering and can be used by developers to orchestrate services or build
business logic of their apps quicker.

Aside from that we to offer out of the box User authentication and management
API, social signup, Data storage API with automatic generation database and
REST API on top of the data model you define, Serverless code execution to
implement any custom logic (AWS Lambda like), 3rd party API integrations
(Stripe, Sendgrid, Twilio, Firebase, AWS SNS, AWS SQS.. and more), Cronjobs,
Webhooks, CDN backed hosting for static assets with SSL + custom domain
support.

As long as you understand basic RESTful services, JSON and JavaScript you can
use all our core API. Modularity is a key factor of our platform and
developers can already share "Code Blocks" to add specific features to their
apps.

Brightworks seems more close to be an API design tool and to manage it over
the time but I look forward to see more :)

~~~
josh_carterPDX
Thanks for jumping in. Very well put. :)

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

~~~
hooande
"Be Nice".
[https://news.ycombinator.com/item?id=11440627](https://news.ycombinator.com/item?id=11440627)

~~~
seabass
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.

