Hacker News Reader

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

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

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

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?

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) 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!

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. :)

Yes to all of this! :)

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

Absolutely. I'll reach out. Thanks!

Clicky: http://brightwork.io

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.

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.

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!

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?

You can abstract in your code using a Provider pattern but if this product can provide it out of the box along with the other features I wouldn't spend time on coding the Abstraction.

See https://segment.com/

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.

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.

Very well said. Thank you for the feedback.

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

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.

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!

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!

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?

API auth tokens are per user per app.

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

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.

This seems too risky with their obstacles ahead.

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

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?

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.

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?

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.

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.

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

The Dashboard houses all the information about the API. So you can see performance (jitter, packet loss, etc), usage data, and cost projections. So you can tell if an API is costing you more than a competing API. This way, when you want to switch APIs, you can do so knowing you're switching to a better API that will cost you less money. The API switching on the fly is just a bonus. :)

To be clear we solve some of the same problems. We just provide different solutions. StamPlay appears to be a visual development workflow where as Brightwork leverages the skills you already have and just provides a way to speed up backend development.

Both solutions offload infrastructure hosting and management.

To get started on the Brightwork platform all you need to understand is basic RESTful services, JSON and JavaScript.

Our hopes is that on boarding a new developer on the platform who has the aforementioned skills will only take about 10 mins of setup and learning time.

The main reason is that you only need to learn the Brightwork constructs: BrightStacks (vertical APIs, Data, Storage, etc), BrightPacks (pre-bundled code and workflow, e.g. user registration) and BrightBots (your code).

In the future we hope to build a community around BrightPacks. Allowing users to contribute. For Example, the Core BrightPack will offer user authentication and registration. However, it will not offer secondary SMS verification. Maybe someone would want to build that and offer it as a public BrightPack for others to leverage.

Thanks for all your feedback!

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 :)

Thanks for jumping in. Very well put. :)

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.

Agreed but they act as middleware - security should be top priority.

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.

You said, "Our beta is open now if you're interested.", to another intrigued commenter 1 hour ago. It's changed since then?

Feel free to sign up. We can add you to the list of interested users. We're hoping to onboard more and more each week.

It is interesting however I feel it is best to wait for your platform to mature. I lack environments to test your product and refuse to use this with anything sensitive. Configuring SSL/TLS is a minuscule process taking only a few minutes, vital for security, that has been neglected. I'll keep your product in mind until these rudimentary basics have been addressed.

Thanks, Josh.

Appreciate the candor. The beta is really meant to "test drive" the platform. Hopefully you keep tabs on what we're doing. Thanks!

I'd like to disagree with the statement that this can "only take a few minutes" by pointing out, done correctly, essentially everything takes 15+ minutes to accomplish.

As far as SSL/TLS you've got to generate a CSR, get it signed, go poke around in your load balancer and/or application server to reconfigure appropriately, and very probably iterate on your cipher list until SSL Labs (or equivalent) looks good.

If that isn't a contentious view, then I'll go further, building a product has hundreds of these "miniscule" tasks (your words) and added together that's significant time. Whilst you might not agree with the prioritisation, the response that they'd prioritised feature work over ticking off this box was at least honest.

Hat tip to the team for communicating so well in this thread.

Thanks nixgeek! I didn't have the energy to explain this yesterday, but you nailed it.

I acknowledge your disagreement and find it to be inexperienced. You should follow the standards, not trial-and-error until a third party gives you a thumbs up. Re-configuring your internal structure is only as extensive as the complexity (which is usually nil).

If you need an instructional video on how to complete such a trivial task, let me know. I guarantee it will be less than 5 minutes on a variety of environments. What "hundreds" of these tasks are you speaking of? Please meticulously explain rather than fluff your speech to make the process seem more debilitating than it is.

Also: minuscule

Apply HN: Brightwork – Making APIs More Intelligent