stack suggestions
hey guys
I've mostly worked on frontend (next.js) so far, trying to buid a full stack project on the side and want suggestions for the backend stack.
I've worked a little bit with mongo / express but I'm open to other langs as well to push myself and learn if the tradeoff is more scalable/ performant / cheaper or if there's a middle ground between the mentioned and a good dx, open to it too.
considering to use convex.dev right now with auth.js for auth. convex seems like a great solution but almost too good to be true as its open source (no vendor lockin) but im assuming there'll be too many headaches self hosting it.. I want to sustain with it for free for at least a year from launch to get people in, if I can self host it, it'd be great to use google cloud / aws credits
25 Replies
It's hard to recommend stack without any informations on what you're going to build. But you say you done next frontend work, and you want suggestions for BE. Do you know that you can write your backend in next? And if you do, why not do that?
hey juraj appreciate your response 🙂
I hear what you're saying. I know about the next.js apis and I've used them as well for handling very basic api requirements like mail triggers on form submissions and alike.
I'm not sure if it's recommended for full stack applications too?
the summary of the application is this:
Yes, next is totally valid solution for full-stack applications.
I see, thanks! 🙂 It's serverless though right? So from my understanding it spins up and execute all API calls on-demand.. wouldn't that add up costs instead of just hosting a VPS considering an app like this will need a lot of API calls especially as users and events happen in size?
It's made sense for me for small tasks here and there, just trying to wrap my head around if it makes sense using it as the backend completely for scale
not to mention I will also need cron jobs
i think vercel has a free tier that lets you to host fullstack apps for free. and if its just a hobby project then dont even worry about vps
or alternatively you can use setTimeout if the cron option is not available.
Yes, serverless is technically more costly then VPS. But I think in your case, serverless is right way to go exactly because of the scenario you talk about. If an event happens and you suddenly have big spike in usage, serverless can handle it. Going with VPS, you have the risk your server crashing.
Cron jobs are a different case. If you go with Vercel as your hosting provider, they do support cron jobs. If you go with anything else that doesn't support cron jobs, I'd just deploy very simple server to handle these cron jobs, and call appropriate serverless functions.
hmm I hear that and besides if this picks up so much that i exhaust the free tier and I want to move to a robust vps, it shouldn't be a huge pain as the next apis are all in express.. seems like a reasonable idea at least to kick off and test it out for a few small events.. plus I see about cron and a separate server as an option.. I was considering cloudflare cause of their free ddos protection.. especially now that I may do next's serverless api's but appreciate your inputs!
last time I tried to host next.js app out of vercel it caused me pain.
yeah I'm not keen on having vps right away either.. but I don't want to get locked into a service either as I can get startup credits from multiple services like aws.. I won't be able to monetize it for a good few months till it's tested on some small events and bug free
What Sifatul said. Going with Next and Vercel is a good option for you imo, but please "move to a robust vps, it shouldn't be a huge pain" is not a good attitude to have when it comes to next. 😂
haha i hear you guys.. vercel makes it crazy simple, it's literally been my go to for all basic frontend projects
im just thinking through sustaining for a few months
with light load
on a free tier
i think i might be okay with the free tier intself
yes basically the issue happens when you need to understand image optimization server + frontend separation etc etc. these are all abstructed by vercel.
im not a fan of being locked in but perhaps its just a mental block
There is something to be said about Supabase as a BE. Since you mentioned mobile app, you might be able to use their client both on FE and mobile, and it should be pretty similar. Of course, that's vendor lock in on steroids. But it might be something you want to consider.
vercel supports 2 cron jobs at most for free tier. with 13GB disk space for a moderate traffic and regular user less than 1000 a month and less than 100 active perday. I think will be sufficient for vercel
General rule of thumb I go by is, anything you write before you have your first users will be needed to be rewriten at some point. So I wouldn't stress about tech too much, and go with anything that's quick to develop.
one thing I would like to point out. the next.js infact uses express.js like approach when it comes to api. so if you later move to a vps you can copy over all your routes into a different express app and not care too much about scaling next.js app on vercel. just an idea I wanted to share.
yeah in fact i was playing around with it yesterday to get a feel of it.. it's not bad in terms of the dev ex at all.. in terms of lock in.. they allow you to self host the whole instance too
that's a great frame man.. something that's stuck with me for sure
yessir, for sure.. doesnt next in fact use express underneat the hood for it? regardless i've played around with it.. def considering it
yes that's how it's built.
supabase is also alluring lol with the ease it brings in .. especially with auth.. but I think I'll go on a walk and just pick one, build a MVP for the first few users like you suggested @Juraj98
one more thing that I'd love an opinion on too if you've explored it.. @Sifatul @Juraj98 what about trpc? is it worth considering too for this use case? i havent ever tried it yet but the typesafety and autocomplete it provides def between client / server seems very intriguing and would speed up to getting the first users for sure if i dont go for the baas route
one more thing that I'd love an opinion on too if you've explored it.. @Sifatul @Juraj98 what about trpc? is it worth considering too for this use case? i havent ever tried it yet but the typesafety and autocomplete it provides def between client / server seems very intriguing and would speed up to getting the first users for sure if i dont go for the baas route
TRPC makes the DX way better. because you get type reference. so you will less likely forget the db schema and your api responses. you can use it but no need to think too much about trpc or not trpc. because you will not forget any of your schema as a MVP is always simple and easy to navigate.
Trpc is great if you're working with only FE and BE. The only thing that stands out to me is your mobile use case. I don't know if there is easy way to connect to trpc from native mobile. But it should be possible. And I think there is also some solution to turn your trpc procedures into classic api endpoints. But I have no experience with that.
But I don't know if you're planning to have the mobile app you mentioned native. I'd maybe consider to build the MVP as a webapp that works in phone webbrowser with camera api. That way you can just take full advantage of everything you built for FE (trpc included).
Also, if you don't go with the mobile compatible webapp route, you can always combine trpc and API endpoints. Everything that's only for FE can go through trpc, and the endpoints you need for mobile could be classic API endpoints.
thanks again bud, that makes a lot of sense.. and yeah I wasn't sure about using it with mobile dev either. I'll def start with a scanning web app with the same functionality first for the mvp.. I just want to be assured that it'll be possible because it'll def be needed in the future, so will do a bit more reading on that
yeah this makes sense as well, appreciate it
and trpc works serverless too right?
Yes, TRPC creates one endpoint that it connects to.
got it, thanks a lot again guys! @Juraj98 @Sifatul i'll take a walk, pick a route and just get working instead of overthinking it.. as like you said at some point it'll need to change anyway lol but this provided me with a lot of clarity / trade offs 🙂