|
|
|
|
|
by mattbrewsbytes
1053 days ago
|
|
You didn't provide any details on what performance you need, what you're doing and why the stacks you listed don't meet that need. Typically with DB based apps with an API, a performance bottleneck that happens more often than the web language is in the DB layer: bad queries, poor/missing indexes and bad table design. Writing poor performing code happens in every language. One aspect of picking a stack is the options available in the ecosystem around the stack for various things you may need to do. Think of common solved problems like generating PDFs and parsing/generating Excel files even if you don't think you'll be doing those (hint you'll probably be doing those). Use those two problem domains as a rubric to evaluate if the ecosystem around your stack choices have options for simple, solved problems like those. If you aren't finding a lot of options that's an indicator you may not find options for other problems where you don't want to DIY a solution and just want a library to do the heavy lifting. I will call out that you did mention startups so likely performance isn't a concern until you have paying customers. If your stack is a completely separate frontend, that provides an abstraction layer via the API definition where over time you could change out your API stack if you find its performance is lacking. Spend time solving problems you have now while making sure your overall design gives you options for future potential problems. |
|