Disable Database
How to disable database? I am building an APP that just proxies API calls to Gemini and do not intend to store any data.
11 Replies
Hi @chilled_techie. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Unfortunately, the knowledge sources provided do not contain specific information about how to disable the database in a Wasp application. Wasp is designed to work with a database by default, and there isn't a straightforward way to completely disable it based on the information available.
However, I can provide some relevant information that might be helpful:
1. Wasp uses Prisma as its ORM and supports both SQLite and PostgreSQL databases Docs > Data-model > Databases > API Reference (https://wasp-lang.dev/docs/data-model/backends#api-reference).
2. If you don't need a database, you could potentially minimize its usage by not defining any entities or database operations in your Wasp app.
3. For your specific use case of building an app that just proxies API calls to Gemini without storing data, you might want to focus on creating custom API endpoints in Wasp. You can find information on how to do this in the Custom HTTP API Endpoints documentation (https://wasp-lang.dev/docs/advanced/apis#using-the-api-externally).
If you really need to completely disable the database, you might want to reach out to the Wasp community or maintainers for more specific guidance, as this seems to be an uncommon use case not covered in the provided documentation.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @chilled_techie, 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?
Hey @chilled_techie. Unfortunately, that isn't possible in Wasp. Wasp is a full-stack framework and most of its features depend on there being a database.
But, most apps need a database at some point, so you might want to consider using Wasp and having one anyway, just in case 🙂
@miho @martinsos Another reason to reconsider allowing SQLite in production (or even no database).
Thanks @Filip for the clarification. I will go with an empty DB for now.
@Filip what if I am building BFF (backend-for-frontend) and really don't need a DB in production?
In that case, I don't think Wasp is the best fit for your use case unfortunately.
I'd love to tell you otherwise and keep you with us, but the reality is - Wasp is made for building full stack apps. If you only need a frontend or a backend, there are probabably better solutions out there.
With that in mind, like I told Techie above, if you like other features of Wasp and would like to keep using it even for a BFF, you must have the production database even if you don't need it.
I understand the point about "full-stack", but in general, persistence layer might not only be a database, but also some web api, or redis key-value store, or some event bus, which is far beyond what prisma can offer. But it is still a "full-stack" application, and it still will benefit from what wasp offers. Maybe it is worth to consider that usecase in the future framework design, especially because rails, laravel, asp, spring, etc. already support that.
inb4 nobody asked sorry, don't want to bother you, just thinking out loud
Hey @dexie, you're not bothering me at all - we love getting feedback like this!
It helps us see what people want and prioritize features.
Anyway, you're completely right - Wasp's configurability is lacking in the database department (and some other departments too).
The grand vision is to turn Wasp into a full-stack web framework that supports all that stuff and then some. I'm talking about things like message queues, in-memory caches and databases, horizontal scaling, different languages and runtimes, different frontend frameworks, mobile clients... Anything you might expect to find in a full-stack product.
But we had to start somewhere. And, since relational databases can effectively cover 80% of use cases, we started there. Of course, Wasp is nowhere near Laravel, Rails, Spring and the other big guys feature-wise. It's still in its infancy (we're not even 1.0 yet).
The idea is "let's first build a full-stack solution that works well for a basic web app configuration, and then focus on expanding options on each layer," and we're still in the first stage of it.
That said, we haven't given up on the grand vision. We hope to get there some day, we just don't currently have the manpower. Here are some issues addressing these ambitions:
- https://github.com/wasp-lang/wasp/issues/2207
- https://github.com/wasp-lang/wasp/issues/1074
- https://github.com/wasp-lang/wasp/issues/1088
- https://github.com/wasp-lang/wasp/issues/1261
Some might come to life, some might not.
At the moment, what we lack in configurability (compared to the bigger players), we try to make up in other ways. This mostly comes down to building and polishing end-to-end solutions for the most common use cases (e.g., easy full-stack auth, easy RPC with smart cache invalidation, etc.)
Yup, I very well understand that wasp is just getting up to speed. Your approach totally makes sense, sorry for doubt! Glad this feature is not off the radars 🙂
Glad this feature is not off the radarsNow that you mention it... I can't find the issue that talks about disabling db in production (or allowing SQLite). I know we talk about it all the time though. @miho @martinsos Do you maybe know if there's an issue for this or should I create one?
sorry for doubtNo problem at all! In fact, I'd prefer you keep up the doubt 😄 Sometimes, we (the team) are in too deep to notice all the things an outsider can. And I see from your questions/issues that you're both 1) experienced and 2) willing to put in effort when reporting bugs and giving suggestions. That's a tough combination to find in a user, so we'd love to hear what you have to say. Rest assured, it won't fall on deaf ears 🙂
Now that you mention it... I can't find the issue that talks about disabling db in production (or allowing SQLite). I know we talk about it all the time though.We talked about enabling using Sqlite in production if connecting to a remote Sqlite: https://github.com/wasp-lang/wasp/issues/1265 because we assumed stateless deployments (the file system is not something we can count on). The bit about disabling the database - some of it happens implicitly, migrations are not ran if there are 0 entities defined. But we never created an issue AFAIK for explicitly disabling the database.
Do we want to add an explicit setting to disable the database or just make the implicit support better so that the app works without a database?
GitHub
Consider supporting supporting external db hosting · Issue #1265 · ...
Consider allowing users to host DB on some external hosting provider, like PlanetScale (in this case we also need MySQL support for Prisma enabled), or maybe Supabase (they have free postgres). We ...
Do we want to add an explicit setting to disable the database or just make the implicit support better so that the app works without a database?I think the biggest blocker for the implicit support is that Wasp won't run if it can't connect to the DB. On the other hand, if we removed that, many users that actually need the database would end up pretty confused with all the errors they'd get. Maybe we can allow "implicit no database support" by being explicit. For example, a user sets the env var to "i-am-sure-i-dont-want-a-db-trust-me"), we then allow them to start your app without the db 😄