Wasp•16mo ago

How to correctly use queries

as title says, I've been trying to implement some queries to know how everything works, but having some doubts:

I want to fetch some files located on the server side, what's the recommended path to locate these files? it works, but process.cwd() returns me .wasp/out path and idk if I should keep it or change to @src/server/files or .wasp/out/server/src
Are operations on openSAAS used like queries.ts? there's no difference right?
it works for me without using entities, if I use them, it gives me unexpected token (I'm using them wrong ik), should I figure out and use them? Maybe if I'm handling with files and not objects in some db it's different

MEE6•9/12/24, 10:40 AM

Wohooo @varo, you just became a Waspeteer level 1!

kapa.ai•9/12/24, 10:40 AM

Hi @varo. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base.

kapa.ai•9/12/24, 10:40 AM

----------------------
Sure, I can help clarify how to use queries in Wasp.

File Location: In Wasp, you typically import your queries from the directory. For example, if you have a query called , you would import it like this:

Then, you can call it directly in your code. The actual implementation of the query should be in the or file, depending on whether you're using JavaScript or TypeScript. You declare the query in your

.wasp

.wasp

file and point to its implementation in the or file. For example:

source (https://wasp-lang.dev/docs/data-model/operations/queries#working-with-queries)

OpenSaaS Operations: The operations in OpenSaaS should work the same way as in any other Wasp project. You declare them in your
```
.wasp
```
```
.wasp
```
file and implement them in your or file. There should be no difference in how you use them compared to other Wasp projects.
Using Entities: Entities are typically used when you're working with data from a database. If you're just working with files and not database objects, you might not need to use entities. However, if you do need to use entities, you would declare them in your query like this:

Then, in your query implementation, you would have access to the entity's Prisma API through the

context

context

argument:

kapa.ai•9/12/24, 10:40 AM

source (https://wasp-lang.dev/docs/data-model/operations/queries#using-entities-in-queries)

If you're getting an unexpected token error when using entities, it might be because there's a syntax error in your code. If you could provide more details about the error, I might be able to help you troubleshoot it.
----------------------
Note: you can ask me a follow up question by @ mentioning me again

----------------------

kapa.ai•9/12/24, 10:40 AM

Sorry @varo, 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?

varoOP•9/12/24, 10:42 AM

@kapa.ai , what's the recommended path to keep files in a server that are going to be fetched but do not want to be accesible directly from the user?

kapa.ai•9/12/24, 10:42 AM

Let me check the knowledge base for you. One moment!

kapa.ai•9/12/24, 10:42 AM

----------------------
In Wasp, there is currently an open discussion about supporting static assets in the server side of a Wasp project. The idea is to have a special directory, something like , and whatever you put there, Wasp would ensure to copy to the built server code while doing

wasp build

wasp build

. This would allow you to store files that can be accessed directly from the server code (loaded as a file and similar), but not directly by the user. However, this feature is not yet implemented. source (https://github.com/wasp-lang/wasp/issues/609)

For now, you can store your files in the

src

src

directory of your Wasp project and access them from your server code. However, these files would not be included in the final build that gets deployed, so they would not be accessible in production.

If you need to store files that should be accessible in production but not directly by the user, you might need to consider other options, such as storing the files in a database or using a cloud storage service like AWS S3.
----------------------
Note: you can ask me a follow up question by @ mentioning me again

----------------------

kapa.ai•9/12/24, 10:42 AM

Sorry @varo, 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?

varoOP•9/12/24, 10:47 AM

so my server statuc files may disappear when I deploy my server? @kapa.ai

kapa.ai•9/12/24, 10:47 AM

Let me check the knowledge base for you. One moment!

kapa.ai•9/12/24, 10:47 AM

----------------------
Yes, currently in Wasp, files that are not part of the source code (like static files you put in the

src

src

directory) are not included in the final build that gets deployed. This means that if you put static files in your

src

src

directory and access them from your server code, they will be accessible locally, but they will not be accessible when you deploy your app.

This is because the TypeScript compiler, which Wasp uses to build the server code, does not include non-code files in the final build. There is an open discussion about adding support for including static assets in the server build, but this feature is not yet implemented. source (https://github.com/wasp-lang/wasp/issues/609)

If you need to include static files in your deployed app, you might need to consider other options, such as storing the files in a database or using a cloud storage service like AWS S3.
----------------------
Note: you can ask me a follow up question by @ mentioning me again

----------------------

kapa.ai•9/12/24, 10:47 AM

Sorry @varo, 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?

miho•9/12/24, 11:32 AM

One way I can think of keeping the static files with you is to maybe store them on S3 or some other external storage. And when you need them, download them to a location accessible to the server and then serve the to the user in any way you like

(using the express static middleware, returning it as some sort of JSON response etc.)