It looks like you guys put a lot of work into it. Your main competitor here would probably be Runscope. I would advise creating small API testing tools like Requestb.in (but maybe doesn't expire) to help your platform get more exposure. Another thing that sticks out is your landing page--the sign up form could use more contrast and be bigger.
Can I also ask what software you use for your blog? Congrats on the launch!
Thanks for checking it out and for the tips on the landing page! I'll take a look at those.
I definitely agree on having focused tools and use-cases; the current plan is to work on better and more valuable assertions and integrating that into current workflows (CI, deploy, etc).
The blog is "custom". It uses React.js templates, markdown files for the content, all compiled with webpack. Maybe I'll write something up about how it works.
This looks pretty neat. Congratulations on your launch!
Looks like it also monitors uptime, which feels like a more feature-rich alternative to Pingdom, which just checks for HTTP 200 responses.
I'm not sure I understand why the focus on "production APIs," except that they're more easily accessible from the internet. I would expect many enterprises would love to be able to run this in their own private data center, sort of like an on-premise solution, against staging API's or pre-release API's. Why focus all the marketing on "production," though? Isn't it just putting test data in production? How is this better than putting the same test data in QA and testing before you release to production?
Hey, thanks for checking it out! Glad you were able to see the usefulness of it :)
I agree that staging/pre-release testing is really valuable. We want to make sure those uses-cases are supported and just as easy, ideally hooking into CI, code deploy, etc. I'll have to think about how I can re-word this a bit. If a staging site or internal service isn't behind some firewall it will already work; I'll make that more clear as we add better support for these workflows. Good points.
Monitoring uptime of any endpoint is really easy to set up! Just type it in and set a schedule. 200's are default, but you can set any status code. For me personally, I like to set up a lot of tests for 'admin-only' endpoints (eg, asserting that unauthorized requests are denied). And I agree, that's a big improvement over some of the more basic monitoring tools.
Thanks again for the feedback. We're hoping to add some more assertions this weekend, so check back up in a couple days!
5 comments
[ 2.9 ms ] story [ 17.4 ms ] threadMy co-founder and I just released Assertible - a tool for making assertions about your production API and websites.
We've yet to find a good solution for testing production API's and we made Assertible to make that not only possible, but easy and effective.
Can I also ask what software you use for your blog? Congrats on the launch!
I definitely agree on having focused tools and use-cases; the current plan is to work on better and more valuable assertions and integrating that into current workflows (CI, deploy, etc).
The blog is "custom". It uses React.js templates, markdown files for the content, all compiled with webpack. Maybe I'll write something up about how it works.
Looks like it also monitors uptime, which feels like a more feature-rich alternative to Pingdom, which just checks for HTTP 200 responses.
I'm not sure I understand why the focus on "production APIs," except that they're more easily accessible from the internet. I would expect many enterprises would love to be able to run this in their own private data center, sort of like an on-premise solution, against staging API's or pre-release API's. Why focus all the marketing on "production," though? Isn't it just putting test data in production? How is this better than putting the same test data in QA and testing before you release to production?
I agree that staging/pre-release testing is really valuable. We want to make sure those uses-cases are supported and just as easy, ideally hooking into CI, code deploy, etc. I'll have to think about how I can re-word this a bit. If a staging site or internal service isn't behind some firewall it will already work; I'll make that more clear as we add better support for these workflows. Good points.
Monitoring uptime of any endpoint is really easy to set up! Just type it in and set a schedule. 200's are default, but you can set any status code. For me personally, I like to set up a lot of tests for 'admin-only' endpoints (eg, asserting that unauthorized requests are denied). And I agree, that's a big improvement over some of the more basic monitoring tools.
Thanks again for the feedback. We're hoping to add some more assertions this weekend, so check back up in a couple days!