- Development environment: So you can write tests. The web console helps you gain insight into what is happening in the system.
- Automatic test environment: You execute written tests in CI/CD.
No. ServerlessSpy can be useful as a developer tool to see events that are occurring in the development environment. The main benefit compared to mentioned tools is that you can see events in real time. But ServerlessSpy does not have near capabilities of those tools, especially not tracing an event through services, which is the main point of distributed tracing.
If you are using ServerlessSpy in a low-traffic environment like dev and test usually are, the costs are negligible. For high-load environments, like production, you should exclude ServerlessSpy. It has no use there, and it will just induce costs and could contribute to hitting AWS quotas & limits like Lambda concurrent executions.
Negligible, and that's only when hitting Lambda. You should exclude the ServerlessSpy construct in the production environment anyway.
Additional resources do not harm and do not cause any noticeable costs (in a dev or test environment). But if you still do not want them, you can add them just for the period of executing the test. Some similar testing libraries do that out of the box. Just redeploy before executing the tests with ServerlessSpy construct included via parameter and then again redeploy afterward with ServerlessSpy construct excluded.
The recommended way to develop serverless systems is to have a separate environment for each developer or/and each feature. You can still use ServerlessSpy if you share an environment, although discouraged. In the web console, you will see events that other developers triggered. And those events could also interfere with your tests if you do not use conditions that filter events by some unique attribute.
They are, but not directly. API Gateway and AppSync services do not support intercepting events, except via CloudWatch, which is slooooow 🐌🐌🐌. ServerlessSpy needs to be fast. You can intercept those events when they hit other supported services like Lambda.
Custom resources and s3Deployments (among other CDK constructs) are backed by a SingletonFunction which can cause a lot of issues with your deploy (circular dependencies etc.). For everyone's sanity, these are excluded. Feel free to open an issue if you have a use-case where you need this to be included.