Following up on the onboarding notes, I have cloned the repository to review the overall status, starting with the app directory.
Generally in a Nuxt 3 application structure, anything related to the backend logic should be nested into the server/ directory. With this, we can bring more UX integrations such as server/utils auto imports, and narrowed-down types. Also, this makes sure we do not leak code and dependencies. Because of this, I highly recommend moving all server-related stuff (app, app-composables, drizzle to the server dir)
For choosing between the Class vs Composables convention, you would probably benefit from Nitro and H3 architecture performances the most by choosing the former option of composables. They will be imported into the bundle only by usage and exactly where we use them.
For the implementation of cache (and in general storage), we can use built-in useStorage() Nitro exposes a powerful and well-tested layer out of the box for storage. It works similarly to UNIX mount points, where you can mount to the /cache using [nitro.storage](http://nitro.storage) option inside nuxt.config and then access it via storage.getItem('/cache/session/{id}'or useStorage('cache'). Nitro also provides caching utilities out of the box to consume cache storage. You can read more in https://nitro.unjs.io/guide/cache)
I probably need to have more clear requirement description for user session support. Nitro exposes useSession(event) utility that uses sealed (encrypted) barear tokens. Such tokens can be used with serverless deployments and scaled up to be used across instances. We can implement out useVingSession() utility based on the built-in session and extend to add more utilities. I have made a small example in https://github.com/nuxt/examples/tree/main/auth/local for giving you an overall idea how usage looks like. But we can also discuss about extension requirements and User DB integration method.
I am not opinionated to choose an ORM either. Both drizzle and mikro-orm looks good options. You might also have a look at https://typeorm.io/ . As long as it is typesafe and multi backend supported, it should be a safe option. So far usage of Users and Tokens schema can be implemented easily even without an ORM to reduce protype complexities.
We could even try https://www.npmjs.com/package/db0 for prototype it is a (currently private and under development) project we are making for Nuxt based on built-in storage for simple database implementations. It is type safe, and supports validations out of the box and perfect if we don’t need complex DB queries and relations. We probably need to migrate to a real DB engine but it can give a fresh-air to rethink about database once a full-functional prototype is delivered.
Small library suggestion from unjs (the ecosystem powering nuxt and nitro)
While i am trying to focus on server-side first, i noticed some types are being imported from app. Since we might better to isolate server code to server directory and avoid cross imports, you might move shared types such as TVingOption to a top level typs/ directory and use import type {} syntax. This reduces chances of accidental code leakage from server to client bundle.
Following up on the onboarding notes, I have cloned the repository to review the overall status, starting with the app directory.
Generally in a Nuxt 3 application structure, anything related to the backend logic should be nested into the
server/directory. With this, we can bring more UX integrations such asserver/utilsauto imports, and narrowed-down types. Also, this makes sure we do not leak code and dependencies. Because of this, I highly recommend moving all server-related stuff (app, app-composables, drizzle to the server dir)For choosing between the Class vs Composables convention, you would probably benefit from Nitro and H3 architecture performances the most by choosing the former option of composables. They will be imported into the bundle only by usage and exactly where we use them.
For the implementation of cache (and in general storage), we can use built-in
useStorage()Nitro exposes a powerful and well-tested layer out of the box for storage. It works similarly to UNIX mount points, where you can mount to the/cacheusing[nitro.storage](http://nitro.storage)option insidenuxt.configand then access it viastorage.getItem('/cache/session/{id}'oruseStorage('cache'). Nitro also provides caching utilities out of the box to consume cache storage. You can read more in https://nitro.unjs.io/guide/cache)I probably need to have more clear requirement description for user session support. Nitro exposes
useSession(event)utility that uses sealed (encrypted) barear tokens. Such tokens can be used with serverless deployments and scaled up to be used across instances. We can implement outuseVingSession()utility based on the built-in session and extend to add more utilities. I have made a small example in https://github.com/nuxt/examples/tree/main/auth/local for giving you an overall idea how usage looks like. But we can also discuss about extension requirements and User DB integration method.I am not opinionated to choose an ORM either. Both drizzle and mikro-orm looks good options. You might also have a look at https://typeorm.io/ . As long as it is typesafe and multi backend supported, it should be a safe option. So far usage of Users and Tokens schema can be implemented easily even without an ORM to reduce protype complexities.
We could even try https://www.npmjs.com/package/db0 for prototype it is a (currently private and under development) project we are making for Nuxt based on built-in storage for simple database implementations. It is type safe, and supports validations out of the box and perfect if we don’t need complex DB queries and relations. We probably need to migrate to a real DB engine but it can give a fresh-air to rethink about database once a full-functional prototype is delivered.
Small library suggestion from unjs (the ecosystem powering nuxt and nitro)
I have seen the usage of
rocess.env.KEYV_PROVIDER_URLin code. You might migrate to runtimeConfig (https://nuxt.com/docs/getting-started/configuration#environment-variables-and-private-tokens) it is a universal and standard API in nuxt and nitro meant to pass such configuration and also compatible with standard environment variables
While i am trying to focus on server-side first, i noticed some types are being imported from
app. Since we might better to isolate server code to server directory and avoid cross imports, you might move shared types such asTVingOptionto a top leveltyps/directory and useimport type {}syntax. This reduces chances of accidental code leakage from server to client bundle.