1 reply

how would I use validators from drizzle-zod in expo?

I am reading this on the create-t3-turbo README:

Does this pattern leak backend code to my client applications?
No, it does not. The api package should only be a production dependency in the Next.js application where it's served. The Expo app, and all other apps you may add in the future, should only add the api package as a dev dependency. This lets you have full typesafety in your client applications, while keeping your backend code safe.

If you need to share runtime code between the client and server, such as input validation schemas, you can create a separate shared package for this and import it on both sides.

Does this pattern leak backend code to my client applications?
No, it does not. The api package should only be a production dependency in the Next.js application where it's served. The Expo app, and all other apps you may add in the future, should only add the api package as a dev dependency. This lets you have full typesafety in your client applications, while keeping your backend code safe.

If you need to share runtime code between the client and server, such as input validation schemas, you can create a separate shared package for this and import it on both sides.

Currently, I am referencing the OpenStatus repo where they create the validation schemas in the db package https://github.com/openstatusHQ/openstatus/blob/main/packages/db/src/schema/users/validation.ts. How would I use these in expo if I cannot have

@acme/db

@acme/db

as a dependency?

Do I have to manually create the validators in the validators package and only use

drizzle-zod

drizzle-zod

in Next.js?

TTC

Theo's Typesafe Cult•3y ago•

1 reply

Spark

how would I use validators from drizzle-zod in expo?

I am reading this on the create-t3-turbo README:

Does this pattern leak backend code to my client applications?
No, it does not. The api package should only be a production dependency in the Next.js application where it's served. The Expo app, and all other apps you may add in the future, should only add the api package as a dev dependency. This lets you have full typesafety in your client applications, while keeping your backend code safe.

If you need to share runtime code between the client and server, such as input validation schemas, you can create a separate shared package for this and import it on both sides.

Does this pattern leak backend code to my client applications?
No, it does not. The api package should only be a production dependency in the Next.js application where it's served. The Expo app, and all other apps you may add in the future, should only add the api package as a dev dependency. This lets you have full typesafety in your client applications, while keeping your backend code safe.

If you need to share runtime code between the client and server, such as input validation schemas, you can create a separate shared package for this and import it on both sides.

@acme/db

@acme/db

as a dependency?

Do I have to manually create the validators in the validators package and only use

drizzle-zod

drizzle-zod

in Next.js?

how would I use validators from drizzle-zod in expo?

Similar Threads

how would I use validators from drizzle-zod in expo?

Similar Threads

Similar Threads

Similar Threads