Testing APIs shouldn’t feel like a chore. Yet, here we are, copy-pasting URLs into Postman, manually typing headers, rebuilding request bodies from...
For further actions, you may consider blocking this person and/or reporting abuse
While I applaud the effort and I see the appeal of a playground, I think tests provide more robustness.
Maybe the library should have the option to generate tests?
Thanks for commenting! Nimbus is not meant to replace testing. They are not mutually exclusive and serve different purposes. It is meant for flows like when you want to quickly interact with an endpoint, a frontender wants to check endpoint content and interact with them when they are working on the client side of the feature, a QA wants to run pre-conditions by interacting with the APIs, etc. These things cannot be done via testing suites (integration + unit tests).
I understand it is not replacing testing. My idea for the generating test option came because the context of the endpoint is known in your library. And it can change on the fly, so that could be great to make sure tests are checking the actual features.
In the frontender case the output should be communicated. If the output is not what is communicated the fault is with the backend. They can check the output when they debug the API request, no need to enable the library.
For the QA situation, do you want QA's to set up the project on their own computer? My experience with QA people is that they test on the acceptance/test environment. If the library is enabled on a server it is used too far in the development process.
You can write end to end tests if there are situations that you can't test with less expensive tests. If you can't write tests, how can you be sure the features will keep on working in the future?
Thanks for the insight!
The philosophy of the package is to do one thing and do it well: be a playground for API interaction. Adding test generation would drift from this core purpose. Nimbus focuses on the immediate "I want to see what happens when I send this request" moment during development.
Absolutely, but documentation and real interaction serve different purposes. Even with perfect docs, developers often need to:
This is also valuable when you're NOT doing TDD, you write the code, want to see it work, then write tests. Nimbus fits that exploratory phase.
Not necessarily a local setup, as you mentioned, it can be enabled on staging environments if your organization allows it. But you're right that this is optional. The primary audience is developers during active development.
To clarify: Nimbus isn't a replacement for tests. It is about having a PLAYGROUND. It's for the exploratory phase before you write tests, or when you're iterating quickly and just want to see if something works, or when you just want to interact with an endpoint for whatever reason. Think of it like using dd() or var_dump(), you're inspecting behavior, not ensuring correctness long-term.
I have no problem with that stance. I was just thinking out loud about the testing option.
The real interaction is when you write the tests. If you need to mock a lot of things then you have a problem with the design of the code.
Write tests and if they fail fix te code. You don't need to do TDD. You can write the code and add the tests after you written the code. Why would you do a manual test and then write a test, work smarter not harder.
That was my point, your library shouldn't be enabled on a server.
I didn't check if the endpoint for the playground needs authorization or not. But even if it does it means the code is going to production, and that could become a data leak in the worst case.
My end to end test statement is not about the library but about good code practices.
I think you did a good job with the library, I just wanted to point out a few of the consequences when adding the library.
That’s not entirely accurate. A test will never represent a real interaction. Tests validate expectations; they don’t simulate the full behavior of an active system.
That approach can work, but inspecting responses through tests alone is often inefficient, especially during early development. The point of a playground isn’t to verify correctness; it’s to explore behavior against real data and context. The distinction between a Playground and Automated Tests is important here.
Developers can use it briefly during early development, or later if they need to interact directly with an endpoint with as little friction as possible and with as much kickstart as possible. It’s flexible and can be tailored to whatever needs you have.
Correct. Nimbus supports environment-based control. It’s disabled in production by default.
If preferred, it can also be installed as a development dependency via:
Tests should represent real interactions, if hope you are not only writing happy path tests. But they should intercept the interaction on the lowest level, so that it is not needed to create more expensive tests.
Don't do end to end tests, do transformer tests. If you are writing an endpoint and only test the output, that will take longer than testing each part that makes up the endpoint separate.
That was my point. The code should not be on a production server, not even disabled. That is the same as keeping the test code on production. The only thing that is does is creating a potential cause for problems.
I think there’s some confusion about the intent of this package. It has nothing to do with automated testing, CI, or TDD practices.
Nimbus is an in-browser API client, similar in concept to Postman or Insomnia, but it operates within your Laravel codebase. That integration gives it advantages that external tools can’t provide, such as automatic route and payload discovery, cookie decryption, user impersonation, and making requests as the currently authenticated user.
There’s no disagreement on the value of tests or coverage depth. However, that’s separate from what Nimbus is designed for. Automated tests validate expected behavior. A playground is about direct interaction: running endpoints manually, seeing real responses, and observing side effects against actual data. It’s a complementary tool, not a replacement for tests.
I don't want to dictate what people should do. By default, Nimbus is disabled in production. It can be explicitly enabled only when needed. For example, in a controlled internal environment behind role-based middleware or a VPN. One use case can be to debug production issues or to inspect session state by impersonating a user. Whether to allow that flexibility is a decision for each organization to make. But if they want to, they should be able to.
There is no confusion. I just reacting on you statements about testing.
The data input is also an expectation so it doesn't matter if you get the full response or just raw data from the database or a test set. It are always fun times when you let a test framework run mutation tests.
Side effects can be checked with integration tests.
The only time you have actual data on your computer is when you connect to a production database. And you only want to do that to check data fetching queries, not data manipulating queries.
It might be convenient to have a playground for instant gratification, but I think it promotes bad practices. Like it works on my computer.
That is a good mindset. It is the developers responsibility use the library wisely.
I just wanted to add a warning for people that didn't think of that consequence.
Fair! I only mentioned testing because you brought it up. The point I wanted to clarify is that testing and the package’s purpose are not mutually exclusive. They serve different goals.
Why is this? A Playground is inherently personal. It’s not meant to prove correctness or enforce practices. It’s about convenience for developers to execute endpoints quickly. Nimbus is simply an alternative to Postman, Insomnia, etc., designed to give a head start with less friction.
The fact that similar tools have millions of users shows that many developers find them valuable. Here is also open source famous tools:
The core idea is straightforward: if you want a fast, integrated way to explore your Laravel endpoints, a Playground exists to make that process easier. Nothing more, nothing less.
I think the main task of Postman and alternatives is to create interactive documentation. I think it is better to generate industry standard documentation and interaction, like OpenAPI and Swagger.
With a playground there just is the interactive component. Which means the developers don't need to do the documentation part. It is not the library I am against, it is the possibility to take shortcuts.
It is not because something is popular that it is the best tool.
I think we can agree to disagree here. In my experience, there have been many situations where a playground was genuinely useful. Even with comprehensive documentation and 100% test coverage (including mutation testing), there were moments when interacting directly with the endpoint was more convenient.
If you don’t see the value for your workflow, that’s completely fine; but many developers do find this kind of tool helpful in practice.
That's on developers, not the tool. I stated in many places in the wiki and article that it is not meant to replace documentation tools, it is not meant for production, and is solely a playground tool. For instance, in my current workflow, I have the OpenAPI documentation, Insomnia (now I'm using Nimbus), and tests (including mutation tests). They are not mutually exclusive.
In fact, I'm thinking about making OpenAPI schema an input for Nimbus, so it can read the routes and payloads from the documentation and give an interactive interface with the exclusive features that you can only get in an integrated package.
This looks awesome! Testing APIs inside the app environment feels like the upgrade we’ve been waiting for.
The validation rule auto-discovery and instant updates after edits — pure magic ✨
Can’t wait to try Nimbus and see how it changes my workflow.