51–60 of 61 posts
Is this concept against the terms of third party APIs like Twitter/Facebook?
Earlier quoted context omitted.
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.
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 tha…
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?
I have not seen anything in the terms that would put us of of compliance.
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
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 :)
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
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, Dat…
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?…
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…
Earlier quoted context omitted.
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…
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. :)
Earlier quoted context omitted.
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! :)
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).