Structuring a Nuxt 3 server directory

Question

Context

I am creating an app which uses multiple server api points to perform different functions such as writing to Firebase Firestore. These api points are set up in the server directory like so:

server/
  api/
    foo.ts
    bar.ts
  lib/
    firebaseConfig.ts
    firebaseHelpers.ts

The two api endpoints under api/ import helper methods (such as writing to and reading from the database) from the firebaseHelpers.ts file. The firebaseHelpers.ts file imports the Firebase configuration from the firebaseConfig.ts file.

Question

My goal is to separate the endpoints, helper-functions and config files from each other. Also, the helper-functions and config files only need to be available in the server.

Considering this, my question is if this is a good structure to use in Nuxt? I have seen others use the plugins/ and utils/ directories, is that how I should divide my lib/ directory in my case? Is it okay to use a lib/ directory like this?

Answer 1

If you want to take full advantage of nuxt's auto-import feature, then you can use the utils folder or use plugins to create your server-side firebase plugin. Creating a lib folder also makes sense. Optionally, you can structure your lib folder this way: /lib/firebase , /lib/stripe , etc.

I'm also building an app with Nuxt3 and Supabase, and this is the exact problem that I'm facing. In my case, I have the following server structure:

1. middleware - nuxt middlewares
2. routes - works the same as api but without the need to prepend /api to the path
3. services - supabase DB queries. This can also be renamed as repositories as per Domain-driven Design standards
4. utils - small helper functions (eg password hashing, data coercion, etc.)
5. validations - where I validate the query params / body params for each route

Ultimately, you decide how you want to structure your project. You can take inspiration from other frameworks such as Ruby on Rails or learn Domain-driven Design Architecture. However, I recommend not to overthink it so you don't end up creating unnecessary abstractions.