We record traffic from live systems and use it to autogenerate incoming requests and API mocks. You can use it to develop against realistic simulated 3rd party APIs or throw it in your CI system to make sure new builds handle production load. Nobody likes writing tests and mocks, so let Speedscale do it using your own traffic.
Ultimately, the idea is to mock the database itself so we just return whatever the real database returned during the recording. We don't have to run create commands because we aren't actually managing a real database's internal state. We "only" need to accurately return the responses the database gives the system-under-test for a particular GET sequence. During the alpha we are limiting support to HTTP/s but protocols like MongoDB, redis, MySQL, etc are on the backlog. Until we have more database support we're asking alpha customers to deploy test data in a test database, which seems to be a fairly normal part of the CI process for big apps.
You're spot on :). We got this feedback from one of our financial services alphas so we built a DLP rules engine to cover it. That wasn't enough. So we offered to integrate with Google DLP. Still no. So in the end we architected for a split-plane architecture (similar to DataBricks) so big customers can host their own data but we can manage the control stack. It's not something we're doing during the alpha but it's part of the plan. Would that work?
We record traffic from live systems and use it to autogenerate incoming requests and API mocks. You can use it to develop against realistic simulated 3rd party APIs or throw it in your CI system to make sure new builds handle production load. Nobody likes writing tests and mocks, so let Speedscale do it using your own traffic.
Hiring Front End/Full Stack at the moment: https://speedscale.com/careers/
Latest tech including kubernetes, Go, react and cloud data warehousing. Backed by YC, Sierra and TSV.
Send me a note at [email protected] or [email protected].