t3 + express or migrate to tRPC?
Hi,
I have an old project I am starting back up. I implemented it with an express.js backend and a CRA frontend. I am trying to work out what the best way to implement what I need is.
The basic functionality is to allow a testing team to monitor the progress of devices that are being updated, to facilitate faster testing. The progress of the updates is stored on a separate server which exposes a REST API. They enter the id of the device they want to monitor, and the backend verifies the id as valid via the API, and schedules it to be monitored. I calculate how frequently the device should be checked for changes based on when it was last active, to prevent overloading the external server. The backend schedules this and will periodically check each device for changes, updating a Cloud Firestore database when required. The frontend pulls the data from the backend which additionally acts as a cache to reduce db reads.
I was moved to a different project in the middle of development of this tool, recently I have been asked to work on it again and to look at making a mobile app.
I am very interested in t3 app, I would like to get some opinions on what is a good way to proceed.
1. Would a serverless (cloud functions?) implementation be suitable for this? It seems I could schedule functions to run when data changes in a db. Perhaps using tRPC for the api routes to handle input validation, and cloud functions for interacting with the external api? Basically, should I ditch the express server?
2. Is there a recommended guide for building a mobile app on the t3 stack?
Thanks!
22 Replies
1) it’s fine it’s just the orchestration part that becomes the issue. Serverless doesn’t do state so you need someone telling it to do thing which could be in the form of your express server. Quirrel is a server less task queue that handles repeatable jobs which is basically what you are trying to do if you want something serverless
2) there’s a few repos floating around here that answer this but the main issue was with next auth I think but I’m not that familiar with the limitations for Mobile
Clerk
Clerk and Create T3 Turbo
This guide shows you how to integrate Clerk into T3-Turbo so you can have user management for everyone.
Thats a very good point regarding orchestration, it looks like I could make use of the GCP Cloud scheduler. I am unsure right now whether it is best using that or sticking with deploying an express server and handling it myself, I don't suppose you have an opinion on the matter?
Thanks for that repo, I will give it a look over. I think because I will be using Firebase Auth anyway, I should be able to replace the nextauth with firebase auth direct in the mobile app
I have long running jobs that I repeat but I use a separate server for since I have a coworker thats scared of serverless but this topic does come up a bunch if you search the discord for some opinions. Cloud scheduler is probably fine for the job, I never used it but all you really need is to be able to enqueue, repeat jobs and remove them if you want them to stop executing
In our node server I use this which is JUST OK. https://docs.bullmq.io/
What is BullMQ
General description of BullMQ and its features
yeah I implemented a fairly hacky (but working!) scheduler in js just by calculating waits and executing the specific call when nextcheck < currenttime
But thinking about it, I do like the idea of separating the concerns here and having orchestration logic away from the rest api
as that is moreso database management
I will check out BullMQ
Using pub/sub might work nicely too, use topics to queue jobs
Yeah theres a lot of ways to do this 😄
BULL MQ IS JUST OK BTW so if you hate it I did warn you.
The documentation is kinda shit
kafka ❤️
RabbitMQ is better suited i think
but i'm not a Kafka aficionado
My company does use RabbitMQ elsewhere
Not heard of kafka, will check that out
Lets say I move to a serverless architecture, and I take input from the user to monitor a new device with id: 20... do you reckon I should store this in a database and react to that with functions, or publish a message and handle it that way?
I would do event driven and something that pops up a lot when you starting going pub sub is exactly once semantics and that kinda just ties in will your service blow up if it gets run twice type scenarios
This had some useful bits of information for me but alot of it is simplified once you go with a managed solution for your pub sub
reddit
r/ExperiencedDevs - Can anyone share any experiences in implementin...
62 votes and 41 comments so far on Reddit
Your app would be the one spilling off the events that tell it to start monitoring and then the serverless functions just do their thing while being orchestrated by something
Gotcha, that makes sense, perhaps a configuration document which can be set by the user to enable/disable different parts
I will have a think on it, I was generally quite happy with the serverside when i last worked on it, but it is definitely more complicated than I think it needs to be, and elegantly enabling/disabling different functionality on the server was a limitation in how i implemented it
So you use BullMQ on a node server to schedule functions?
I said earlier that I don’t serverless atm and just offered bullmq as what I use
Oh sorry yes
Sorry I’m CARRYING GROCERIES AS WE SPEAK
So I’m all over but it’s just swapping out the server with bull mq out for your cloud pub sub since the app would handle the event creation
So in terms of the frontend stuff, using t3 app, my understanding is it (and next) is aimed at a serverless architecture, if I kept my backend is it still worth using t3 or something else?
Its fineeeeeeee
Its a valid concern but server side react gives you a bit more safety and next does a bit to help your dx
TRPC is just your replacement for your api routes in your standard next app
right gotcha, makes sense. So use trpc on serverside to define the express routes, and on the clientside to interact with the server (and import types from server)
or fastify
Your next app is really your "server"
lets put it in quotes
TRPC is a way for you to run code without the client being able to see it and the pages/components are just the portals for your client to interact w your app
So you can skip the express server part and just spin off the events in your trpc calls
Riiiight i see
Alright, well I have some thinking to do, I am leaning towards ditching express, using nextjs and trpc for routing and emitting events via pubsub and reacting to those with cloud functions to populate the db/interact with external api
OK so I think I have decided to use tRPC routes to replace most of the express data getting and setting, and then use cloud functions for interacting with my remote api to populate the db. I have been checking out create-t3-turbo, and it looks pretty good, so i think I will get started with that. I think I will need to do the backend stuff first though.
I have seen that firestore is not recommended, and I didn't really use it properly anyway (just allowed me to not think too hard about schema) so I am happy to migrate to a relational database. If I am started again like this, is there any advice for properly hashing out the schema and organising things properly? (and whether to use postgres or mysql)