AI cursor rules and whatnot are very biased towards operations and not APIs
What is the sentiment towards a more nuanced AI rules text that differentiates better between operations and api use cases? It would be nice if I could fill in a few details about my app like "its a mobile app so i need the default client-server communication to use APIs." as the last users edited customized rule file. Then other places it could omit saying things like "prefer operations" and give api's just as much examples in the rules. I've made those changes locally (and will be testing them out) but i'm unsure if there was a reason it is the way it is today.
3 Replies
Hi @Captain Incredible. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
The current Wasp documentation and discussions do show a strong bias towards Operations as the default mechanism for client-server communication, especially for standard web app use cases. Operations are tightly integrated with Wasp’s features (like entities, context injection, and client-side helpers such as useQuery), making them the recommended path for most scenarios. APIs, on the other hand, are presented as a lower-level, more flexible alternative for cases where Operations are not suitable—such as when you need custom HTTP methods, paths, or want to expose endpoints to non-Wasp clients (e.g., mobile apps, external services) Custom HTTP API Endpoints.
There is no explicit mention in the knowledge sources of a philosophical or technical reason why rules or AI guidance should always prefer Operations over APIs. In fact, there is recognition that APIs are necessary and valuable for certain use cases, such as supporting multiple clients (including mobile apps) or when you need more control over the HTTP layer Support for multiple clients.
Your idea of making the AI rules or documentation more nuanced—allowing users to specify their app’s context (e.g., “this is a mobile app, so prefer APIs”)—is not addressed directly in the sources, but it aligns with the direction of making Wasp more flexible and supporting a broader range of use cases. There is ongoing discussion about supporting multiple clients and even generating SDKs for different platforms, which would naturally require a more API-centric approach in some scenarios.
In summary, the current bias towards Operations seems to be a matter of default design and integration, not a hard technical limitation. There is openness in the community to expanding support and documentation for APIs, especially as Wasp evolves to support more diverse client types. Your approach to customizing the rules locally is reasonable, and there is no evidence in the sources that this would conflict with Wasp’s intended direction. If anything, it could help inform future improvements to Wasp’s documentation and tooling for non-web or multi-client projects.
If you want to see more official support for this in Wasp, sharing your feedback and results with the community (e.g., via GitHub issues or discussions) would likely be welcomed.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Captain Incredible, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
@Vinny (@Wasp) can probably give you some reasoning about the current rules today
I'd say, what ever works for you best, in the end, those rules are just some hints for the LLM models to better generate code. You should be the final decision maker in the end which path to take with your codebase 🙂
Yeah we're assuming most people are building web apps and will use Wasp operations.
You are of course free to edit the rules however works best for you. 🙂