kgni
kgni
Explore posts from servers
TtRPC
Created by kgni on 7/11/2024 in #❓-help
default TRPCError, try/catch & dealing with DatabaseErrors
Hi there! I'm quite new to tRPC and was hoping that someone could help me out with some general questions related to errors and errorhandling. Thanks in advance! 1. Default TRPCError It seems like that the fallback / default error that is thrown from the trpc server is a TRPCError with code INTERNAL_SERVER_ERROR - is this correct? 2. try/catch If the above is true, I guess in some cases I don't even need to use a try...catch block? Let's say I'm not checking any specific database errors or anything - then I could leave out try...catch all together - or is it considered a best practice to always just use try...catch for consistency when dealing with async operations, and then throw an INTERNAL_SERVER_ERROR manually? 3. Handling database errors To combat the above try...catch consistency dillema, I'm thinking about implementing a general errorHandler that handles various database errors thrown by my postgres db. This handler can then throw specific TRPCErrors depending on the the postgres errors. Additionally, I could extend the TRPCError class to include a translation string for my frontend. Does this approach sound reasonable?
2 replies
HHono
Created by kgni on 7/10/2024 in #help
Sentry - hono/trpc/cloudflare workers
Hi guys, I'm trying to implement sentry into my hono/trpc/cloudflare application. If I'm just using the @hono/sentry middleware, what errors are exactly being caught? Will this middleware automatically catch all expcetions thrown from my middleware trpc server? I guess if I want to have a bit more fine grained control (as to when I'm capturing exceptions) inside of each of my trpc procedures, I need a bit of a different implementation, right? I'm not quite sure if I understood how everything works, I would very much appreciate any feedback! Here is what I'm currently doing to get the sentry instance into my trpc server: (gist for reference): - trpc.ts - trpcContext.ts - just a function that creates the trpcContext (Sentry.init() is called here) - worker.ts - hono server running on CF workers Since Cloudflare workers run on the v8 engine, I' assuming I can just use the sentry/browser package in my workers. 1. pass in the SENTRY_DSN key as a Cloudflare binding - (file: workers.ts) 2. create a trpcServer server middleware as per the @hono/trpc-server documentation - (file: worker.ts) 3a. when creating my tRPC server I pass in my Cloudflare bindings to the trpc context, including the SENTRY_DSN - (file: trpcContext.ts) 3b. now that I have access to the SENTRY_DSN key in the context, I pass this key to Sentry.init() - which comes from sentry/browser. - (file: trpcContext.ts) 3c. I return the instance of Sentry.init() which I now have access to in every single procedure - (file: trpcContext.ts - line 61) 4. as a "catch all", when initializing the trpc server, I can in the errorFormatter check if the error.code === 'INTERNAL_SERVER_ERROR and then capture all these exceptions to sentry, before I return the error to the client. - (file: trpc.ts - line 8) Am I overcomplicating it? I'm afraid I am.
2 replies
TtRPC
Created by kgni on 5/6/2024 in #❓-help
tRPC context, NeonDB & WebSockets
Hi there! I'm currently working on a serverless app with the following tech stack: Cloudflare Workers, Hono, tRPC, DrizzleORM & NeonDB. I'm trying to create 2 Neon client instances (using DrizzleORM) on my tRPC server that is running on Cloudflare Workers. 1 for HTTP 1 for WebSockets (this is used for transactions) I'm a bit confused as to when the WebSocket connection will open. Currently I'm creating both db client instances in the tRPC context (using the Hono tRPC adapter) - so will a WebSocket connection open every single time a procedure runs, or only when I'm actually accessing and using the WebSocket db client in my procedure? I made this gist with the files I have currently
15 replies
TTCTheo's Typesafe Cult
Created by kgni on 2/9/2024 in #questions
Zustand persist individual slices (zustand-x library instead?)
Hi guys! Anyone used this 3rd party abstraction of Zustand? I want to know if I might be running into any pitfalls https://github.com/udecode/zustand-x An issue I have with the base Zustand library is with persisting only specific slices in my global store. To accomplish this I have to either create a separate store or use the partialize function which seems very boilerplatey and annoying to work with on a bigger scale (I might be wrong here, this is just what I'm getting from the documentation) However with the zustand-x library (formerly known as zustood), a lot of boilerplate is removed, and you can persist individual stores. Example (pay attention that you don't need to create getters or setters when writing your stores either - but you can extend both the selectors and actions on the store if you need to):
export const authStore = createStore('auth')(
{
session: undefined,
user: undefined,
},
{
persist: {
name: 'auth',
storage: createJSONStorage(() => zustandStorage),
},
},
);
export const authStore = createStore('auth')(
{
session: undefined,
user: undefined,
},
{
persist: {
name: 'auth',
storage: createJSONStorage(() => zustandStorage),
},
},
);
2 replies
CDCloudflare Developers
Created by kgni on 2/5/2024 in #workers-help
wrangler.toml config questions
Hi there! I just wanted to make sure that I setup my workers / understood how the wrangler.toml config actually works. Here is my current config:
compatibility_date = "2023-10-30"
send_metrics = false
node_compat = true
main = "src/worker.ts"
account_id = "xxx-xxx"


# Staging
[env.staging]
name = "api-staging"
workers_dev = true
vars = { ENVIRONMENT = "staging" }
routes = [{ pattern = "staging.example.app", custom_domain = true }]
d1_databases = [
{ binding = "DB", database_name = "db-staging", database_id = "xxx-xxx", migrations_dir = "migrations", preview_database_id = "DB_STAGING" },
]


# Production
[env.production]
name = "api-production"
workers_dev = false
vars = { ENVIRONMENT = "production" }
routes = [{ pattern = "example.app", custom_domain = false }]
d1_databases = [
{ binding = "DB", database_name = "db-production", database_id = "xxx-xxx", migrations_dir = "migrations", preview_database_id = "DB_PRODUCTION"},
]

[[d1_databases]]
binding = "DB"
database_name = "api-staging"
database_id = "xxx_xxx" # same as the staging database_id
migrations_dir = "migrations"
preview_database_id = "DB_LOCAL"
compatibility_date = "2023-10-30"
send_metrics = false
node_compat = true
main = "src/worker.ts"
account_id = "xxx-xxx"


# Staging
[env.staging]
name = "api-staging"
workers_dev = true
vars = { ENVIRONMENT = "staging" }
routes = [{ pattern = "staging.example.app", custom_domain = true }]
d1_databases = [
{ binding = "DB", database_name = "db-staging", database_id = "xxx-xxx", migrations_dir = "migrations", preview_database_id = "DB_STAGING" },
]


# Production
[env.production]
name = "api-production"
workers_dev = false
vars = { ENVIRONMENT = "production" }
routes = [{ pattern = "example.app", custom_domain = false }]
d1_databases = [
{ binding = "DB", database_name = "db-production", database_id = "xxx-xxx", migrations_dir = "migrations", preview_database_id = "DB_PRODUCTION"},
]

[[d1_databases]]
binding = "DB"
database_name = "api-staging"
database_id = "xxx_xxx" # same as the staging database_id
migrations_dir = "migrations"
preview_database_id = "DB_LOCAL"
1. No "name" at top level Since I didn't provide a name at the top level, I will always deploy my workers with the -e flag - same goes for migrations. This way I don't end up with a top level worker, but only get "api-staging" and "api-production" 2. [[d1_databases]] - last one in the config This is used for the local dev wrangler if I'm not mistaken - but how exactly? Currently I just copied whatever I have in the config for the staging environment - but this doesn't "point" to that worker/d1 instance, does it? I could literally change everything for this last config and just fix my scripts accordingly. So for example if I change the database_name to "this_is_random" then my local migration script would look something like: migrate:local": "wrangler d1 migrations apply this_is_random --local
3 replies
TTCTheo's Typesafe Cult
Created by kgni on 2/4/2024 in #questions
monorepo (turborepo) importing specific files depending on platform
Hi there. I have a monorepo with a Next and a React Native application. I have a shared file that contains all of the same providers used in both apps. let's say one of the specific providers have to be set up in two different ways depending on if it is used for web or native. How would I accomplish this the best way, given that I would still want to use a shared file containing all providers? Is it possible to add on an extension for web like specificProvider.web.tsx and then this file is used for the import only on web (while the normal native specificProvider.tsx is imported on native)? So the import would be something like: '@providers/specificProvider' but it is essentially imported from 2 different environments depending on the platform. Cheers
2 replies
TTCTheo's Typesafe Cult
Created by kgni on 1/22/2024 in #questions
create-t3-turbo issues
Hi guys, I just started diving into the create-t3-turbo monorepo. Unfortunately I'm facing some quite annoying issues setting up and running the base template. I'm following the readme and can get both apps to run with some tricks - however I was expecting it to work out of the box - and I'm not sure if it is my setup there is something wrong with. Setup: Apple M1 Pro macOS: Sonoma 14.2.1 package manager: pnpm (tried installing this several different ways) - tried every package manager and I'm facing the same issues for every one of them Issues I'm facing (I will post more info below): 1. permission denied, open - for certain files in the expo directory. Happens for the auto generated .gitignore file (can't even open it manually) - running with sudo works. Tried various recommendations online (like chmod, deleting and reinstalling the package managers etc) 2. hot reloading for the Nextjs app is quite slow (600ms - 1s to recompile), longer to appear in the browser - is this to be expected? (am I just being a brat? 🙂 ) 3. hot reloading not working in expo at all (not sure if this is can be related to issue 1) I know it can be difficult to remotely debug stuff like this, I'm at a point where I would love to give away a bounty if someone can help me out (hopefully this doesn't break any TOS 😅 ) Sorry in advance for this noob question
17 replies