philtaylor

API auth tokens are per user per app.

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

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

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!

Very well said. Thank you for the feedback.

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!

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.

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.

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!