This isn't important, but -> frontend will be Next.js or Svelte/Kit.
and/or
Elixir/Phoenix/Ecto/Phoenix Liveview, and ditch Next.js/Svelte/Kit
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.
If you're absolutely sure you're going to be hammering this API with high scale requirements, then you can spend a bit more time using Go to make a rock solid service. But more likely, you don't know if you'll really need high performance, and using Typescript will have much less context switching between your Next.js frontend.
Personally, just do it in your Next.js /api backend routes.
Exactly what is it that your Flask or whatever endpoints are doing?
The front end actually does matter. For example, plenty of people are using Next.js with a lot of logic in the front end using things like Supabase etc.
I would also argue that the next level of rapid development doesn't really separate the front and back end in a normal way but rather has abstractions that encompass everything -- front end, back end, database, network, whatever. And then it's about tying together things referencing those definitions. So you might just define a structure and then say you want a form or database record for it and it's already done.
I think the biggest factor is usually not the actual platform but the challenge of getting really reusable abstractions that still perform. For example, making sure you use an efficient and expressive query language.
Sometimes the trade off between rapid development and performance is needing to dig into database details more such as creating an index.
In general it seems as though things like Rust, web assembly, and to a lesser extent Golang, are more popular these days.
But I think you should strongly consider what you are comfortable with. And don't try to select the most performant thing without defining the task specifically and profiling it.
I get swagger ui and “all the clients” for free, thanks to protobuf.
With this said, imo it all depends on how much web dev you have to do. If it’s really just an api, that’s my current stack. If there’s a lot of frontend, I’d prob lean for a similar solution built with a js/ts backend like nextjs or plain express.
Having dabbled in grpc I wasnt aware of grpc gateway. Do you have an example of your setup? If not, no sweat I can figure it out in time.
Just really intrigued because I love using generators to save time and for documenting. Sqlc being another favourite of mine.
https://github.com/grpc-ecosystem/grpc-gateway
To integrate with Fiber, I used the Fiber Adaptor (also pretty straightforward): https://docs.gofiber.io/api/middleware/adaptor
What is your use-case? Are you building a CRUD application? A real-time game? A search engine? Where is your anticipated performance bottleneck? In some cases the database is the blocker and no programming language choice is going to really matter.
If you do have any legitimate performance concerns, can you solve them in some clever way? Perhaps with caching, pre-computing answers to problems, or reorganizing your UI to perform computation in the background?
One caveat, if your backend will be integrating with many external services, in other languages with larger active communities you may find API clients/wrappers that just work. In your Phoenix app, it will be more likely respective packages won't have solid maintenance so expect having to patch things by yourself or reinvent from scratch.
So I would say Node.js lambda functions in Amazon API Gateway via SST.
After the initial learning curve, I'm much more productive in Phoenix than I used to be in Rails, and the performance is better too. No downsides.