bun for a large scale app
hello, im going to make a large scale app and i asked about the best options for that. some friends recommended either hone with bun or fiber with Go, im not into learning a new language yet so i was wondering if using bun at this version for this type of app levels is a wise choice.
I'll be happy to knw which framework is the best choice for such an apps like this
68 Replies
It’s not really worth your time if your still newish/learning
But I am hesitant to tell someone to learn brand new thing. The perf you get from node js is fine for most workloads (async web APIs). Basically don’t do CPU heavy stuff and you won’t need anything else
So should i stick with node instead?
If that's the case which framework should i take?
Yeah it’s fine even deno if you want to try something new but not as new. But if I was you I’d just roll fastify and it’d be perfect
Fastify
Fastify looks interesting. However what do u think about Django or Rocket.rs since i also use python and rust
I use Axum with rust
I like it but what are you trying to make?
No feelings on python stuff that’s like the one language I haven’t touched by choice
Go w fiber is something I also use
Its a c2b and b2b management system
Tracking transactions, expenses, operations in a company
It has workers who has to submit forms when dealing with clients
Node js will be fine dw about it just get to building
And to ship some products from providers
With Fastify :>
It sounds like trivial async stuff which node is very very good at it. And yeah
Thanks
be careful of spreading yourself out too thin.
I wasted a lot of my time when I was younger jumping between stuff that wasn’t really useful to meYeah. I guess i'll stick with the near comfy langs for me which they're js and rust.
No need to jump to other things for the current time
My problem is i always look for the optimal framework or solution
Unless you have specific domain knowledge you are 99% of the time spinning your wheels and prematurely trying to optimize.
Btw my main focus is performance and ability to expand the codebase with more features. Does fastify help with that?
Nodejs perf even python perf is fine enough for most cases
Thats more so on you then a lib that just makes http apis easier to wrangle
It gives you enough perf so don't worry about that
Im worried about scalability
How do you scale something?
You aren't gonna be doing it in your code base is what I'm trying to hint at here.
You can throw resources at the problem to be more scalable or just refactor into something to address a specific issue (monolith -> microservices) but these are things you do down the line
or up front if you've done it before and know the domain
And ultimately if you end up (never releasing, not finishing, not finding a market yadda yadda) not even needing the perf gained its not really an issue to be worried about
I guess if fastify is fine for large scale apps. It won't have scalability issues
If i can turn this into a yes/no question it would be like
Is fastify a good choice for large scale apps
Your service can have scalability issues if the requests are getting bogged down because the overall system can't handle this many. The thing is there are so many reasons this can happen like your database running out of connections so some tasks spend time waiting on it which leads to longer request times. This issue lies with the database and you could remedy that by scaling up the instance but fastify is not the issue here
You shouldn't even be saying "large scale"
you don't know what that is yet
As in you don't have metrics in front of you dictating needs that need to be met or aren't being met so choosing a solution like fastify for your api is fine
I mean't large scale by a really complex app with lot of features
Its just a monolith its fine
You can look at breaking it up into microservices later if it causes you issues
A monolith can still have domains is why i'm correcting that
Wdym by domains
Its just an idea to bound things together. Say a "Payment service", a "Auth service"
Do u have an idea about how to split it up to domains? Cause thats what im looking for
I'm not a DDD wizard but you can look at that later if you really wanted to. In general these bounded contexts make it a little easier to encapsulate ideas and features into groups
prob could read up on domain driven design but I think its fallen a little out of fashion
So we're talking about a DDD architecture here🤔
i've never bothered w it tho. Its very very enterprise-al
The idea is nothing new
And what do u suggest?
the "Domain idea" or just bounded contexts
uh idk really. I would just go "reddit learning ddd books" and see what they say
I don't work in a company that benefits from stuff like this so I haven't really bothered implementing some of the hard stuff they say.
I just apply some of the ideas to what I'm doing and just rely on simple stuff like namespacing to contain things together or a service layer
Hmmm, to get an actual idea from an expert i guess I'll ask u this:
Did u ever made a really big project for a company? If yes what techs and architecture methods u used to make it.
I"m not an expert lol
Anyone will tell you that premature optimization is very much a trap and if you don't know what you are doing you will likely spin your wheels for no reason is the point of this
Since u use Rust u're an expert for 
i wish
I'm no wizard lol
I'm just a generalist that has some more experience then you
There are design patterns people implement to fulfill needs but you really need to know what you are doing to take advantage of these things
Makes sense. But lets say u're going to make a large app what u'll do
for what you said, t3 can do it all without an issue
Design patterns, and architectural designs yes still don't knw how to use them
Next!!
t3 just lacks stateful stuff but thats just serverless woes. If you need to run something like reports every day there are ways around it with t3 that aren't too nasty but generally t3 is very good at most things you need to build
What about going for separation between front and back
you can still do t3 just make calls to your services
I do that all the time
how else can i write rust in production
but you are taking away the scalability serverless provides you doing this way unless the service it communicates with is set up similarly
*serverless is not the best thing ever but going from t3 to t3 +api server is gonna be "less scalable" since you have a hard set cap on the api server for fulfillment assuming you arejust referring to a bog standard server
THERES ALOT OF STUFF TO DISCUSS WHEN YOU TRY TO MEASURE SCALABILITy
i'm not even a wizard at that its just things I've read about that people care about.
I see
Im not thinking to go serverless
Nd i think using t3 for this project is not the wise choice
Why, the stuff you laid out is nothing crazy
You are just interacting with databases and serving up json
So lets bring the scenario where we don't have t3 oe serverless as an option
OR SERVERLESS I SEE
Sockets, FFI, ML, third party api's, react native, tauri
look at you using ffi now
all grown up
ML is already a problem with any web api since its gonna be doing cpu heavy tasks. Just separate the service for that part problem solved
Sockets are easy async shit, ffi doesn't really matter if the workload doesn't change
third party apis are just async work
react native and tauri are just clients so it shouldn't matter either in a sense of "performance of the server"
they are prob just making http requests
You are spinng your wheels here like i said
Have you started working on this yet?
its not hard to translate code between languages so its not entirely wasted effort if you pick "the wrong language"
Basically im still at the planning stage and picking the right stack for this
Now u made me think between either using next js or fastify 😂
Im hella confused atm
t3 is the easiest way honestly lol
Its so fucking free in terms of developer velocity and gives you enough perf for most things. If you need to add in a service to handle ml work you can just stand up a service for that and just interact with it using http/whatever.
What about the app router 🥲
I still use pages so idk
You don't need to adopt the shiniest feature
Is there lot of changes?
to go from app router to pages?
or vice versa
aside from being done completely differently it doesn't really 
next wizard can correct me but you just need to get to building
next wizard can correct me but you just need to get to buildingSo now u suggest Next over Fastify
for the backend
No
As a means to an end for your needs
I feel like next makes me write everything in one place and making it hard to separate
Anything can do that. Thats just how you structure your code
Hmmm building the backend with Next looks cool btw🤔
The only reason i say next is because you likely have a web client yes?
Then it'll prob do the job fine
Yes
It'll be lot of traffic tho
"A LOT OF TRAFFIC"
Stop it
You have no idea
🥲🥲
What about the ML and third party api's?
ML should be a separate service likely and third party apis is just async work (AS IN I'm GONNA HIT YOUTUBE/api/v1/channels to get a list of channels then act on it) so you can fully do it in next server side of things
Its just waiting for the request to fulfill
So i guess either Next or Fastify are fine
Even tho Next is easier
Next will just kill two birds with one stone*
api + web client
its perfect for proof of concepts or things that are still building
And whats the tradeoff?
its just a serverless environment
thats the main point to discuss
Next api should be able to do most things a web api needs
There probably are some edge cases but i don't know them off the top of my head
stop spinning your wheels jsut go work on your project
Yeah u're right i'll think about this more.
Bun is still kind of a bleeding-edge technology at the moment, but hopefully the 1.0 release bleeds less. I’m going to do some prototyping with Bun next week and I’ll report back after I do.
Sounds awesome! I'll wait for it.