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

31–40 of 61 posts

Re: Apply HN: Brightwork – Making APIs More Intelligent

#31

Post by ebbv »

josh_carterPDX wrote: post #14
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.

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

Re: Apply HN: Brightwork – Making APIs More Intelligent

#32

Post by SwimAway »

josh_carterPDX wrote: post #30
SwimAway wrote: post #29

Earlier quoted context omitted.

'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?

Re: Apply HN: Brightwork – Making APIs More Intelligent

#33

Post by philtaylor »

thehorbach wrote: post #5

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

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!

Re: Apply HN: Brightwork – Making APIs More Intelligent

#34

Post by josh_carterPDX »

SwimAway wrote: post #32
josh_carterPDX wrote: post #30

Earlier quoted context omitted.

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.

Re: Apply HN: Brightwork – Making APIs More Intelligent

#35

Post by [deleted] »

josh_carterPDX wrote: post #8
buss wrote: post #3

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

[deleted]

Re: Apply HN: Brightwork – Making APIs More Intelligent

#36

Post by SwimAway »

josh_carterPDX wrote: post #34
SwimAway wrote: post #32

Earlier quoted context omitted.

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.

Re: Apply HN: Brightwork – Making APIs More Intelligent

#37

Post by nostrademons »

philtaylor wrote: post #28
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…

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…

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.

Re: Apply HN: Brightwork – Making APIs More Intelligent

#39

Post by 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?

Re: Apply HN: Brightwork – Making APIs More Intelligent

#40

Post by josh_carterPDX »

SwimAway wrote: post #36
josh_carterPDX wrote: post #34

Earlier quoted context omitted.

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!
Post reply on HN