[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.

[niklas_a]

Makes sense. This explanation was much better than what was on your website. Maybe you should describe yourself as the "ORM for APIs". A bit geeky maybe but would make developers get it.

[educar]

Add chat to the mix. A generic API between all the chat services these days would be awesome :)

[josh_carterPDX]

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 social integration for FB, Twitter, Github, etc.

Hope that helps.

[palakchokshi]

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.