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.
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. :)
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.
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.
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.
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!
'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 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.
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.
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.
I have not seen anything in the terms that would put us of of compliance.