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
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
So should i stick with node instead? If that's the case which framework should i take?
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
Fastify looks interesting. However what do u think about Django or Rocket.rs since i also use python and rust
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
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
Keef
Keef14mo ago
Node js will be fine dw about it just get to building
Lumberjack
Lumberjack14mo ago
And to ship some products from providers With Fastify :>
Keef
Keef14mo ago
It sounds like trivial async stuff which node is very very good at it. And yeah
Lumberjack
Lumberjack14mo ago
Thanks
Keef
Keef14mo ago
ferrisHeartEyes 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 me
Lumberjack
Lumberjack14mo ago
Yeah. 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
Keef
Keef14mo ago
Unless you have specific domain knowledge you are 99% of the time spinning your wheels and prematurely trying to optimize.
Lumberjack
Lumberjack14mo ago
Btw my main focus is performance and ability to expand the codebase with more features. Does fastify help with that?
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
Im worried about scalability
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
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
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
I mean't large scale by a really complex app with lot of features
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
Wdym by domains
Keef
Keef14mo ago
Its just an idea to bound things together. Say a "Payment service", a "Auth service"
Lumberjack
Lumberjack14mo ago
Do u have an idea about how to split it up to domains? Cause thats what im looking for
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
So we're talking about a DDD architecture here🤔
Keef
Keef14mo ago
i've never bothered w it tho. Its very very enterprise-al The idea is nothing new
Lumberjack
Lumberjack14mo ago
And what do u suggest?
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
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.
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
Since u use Rust u're an expert for blessjmg
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
Makes sense. But lets say u're going to make a large app what u'll do
Keef
Keef14mo ago
for what you said, t3 can do it all without an issue
Lumberjack
Lumberjack14mo ago
Design patterns, and architectural designs yes still don't knw how to use them Next!!
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
What about going for separation between front and back
Keef
Keef14mo ago
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.
Lumberjack
Lumberjack14mo ago
I see Im not thinking to go serverless Nd i think using t3 for this project is not the wise choice
Keef
Keef14mo ago
Why, the stuff you laid out is nothing crazy You are just interacting with databases and serving up json
Lumberjack
Lumberjack14mo ago
So lets bring the scenario where we don't have t3 oe serverless as an option
Keef
Keef14mo ago
OR SERVERLESS I SEE
Lumberjack
Lumberjack14mo ago
Sockets, FFI, ML, third party api's, react native, tauri
Keef
Keef14mo ago
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"
Lumberjack
Lumberjack14mo ago
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
Keef
Keef14mo ago
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.
Lumberjack
Lumberjack14mo ago
What about the app router 🥲
Keef
Keef14mo ago
I still use pages so idk You don't need to adopt the shiniest feature
Lumberjack
Lumberjack14mo ago
Is there lot of changes?
Keef
Keef14mo ago
to go from app router to pages? or vice versa aside from being done completely differently it doesn't really Shruge next wizard can correct me but you just need to get to building
Lumberjack
Lumberjack14mo ago
So now u suggest Next over Fastify for the backend
Keef
Keef14mo ago
No As a means to an end for your needs
Lumberjack
Lumberjack14mo ago
I feel like next makes me write everything in one place and making it hard to separate
Keef
Keef14mo ago
Anything can do that. Thats just how you structure your code
Lumberjack
Lumberjack14mo ago
Hmmm building the backend with Next looks cool btw🤔
Keef
Keef14mo ago
The only reason i say next is because you likely have a web client yes? Then it'll prob do the job fine
Lumberjack
Lumberjack14mo ago
Yes It'll be lot of traffic tho
Keef
Keef14mo ago
"A LOT OF TRAFFIC" Stop it You have no idea
Lumberjack
Lumberjack14mo ago
🥲🥲 What about the ML and third party api's?
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
So i guess either Next or Fastify are fine Even tho Next is easier
Keef
Keef14mo ago
Next will just kill two birds with one stone* api + web client its perfect for proof of concepts or things that are still building
Lumberjack
Lumberjack14mo ago
And whats the tradeoff?
Keef
Keef14mo ago
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
Lumberjack
Lumberjack14mo ago
Yeah u're right i'll think about this more.
owenwexler
owenwexler14mo ago
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.
Lumberjack
Lumberjack14mo ago
Sounds awesome! I'll wait for it.
Want results from more Discord servers?
Add your server