Ask HN: Rapid Development API-Only One Person Stack – Seeking Performant Tech

[danielb74]

Looking for advice on building a fast, one-person API-only stack. Explored Rails API, Django Rest, and Flask, but seeking more performance. Any positive experiences using .NET, Spring, or Phoenix in startups? Can I achieve Rails-like rapid development without sacrificing performance?

This isn't important, but -> frontend will be Next.js or Svelte/Kit.

[nivertech]

Elixir/Phoenix/Ecto/Absinthe if you're OK with GraphQL APIs

and/or

Elixir/Phoenix/Ecto/Phoenix Liveview, and ditch Next.js/Svelte/Kit

[mattbrewsbytes]

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.

[reducesuffering]

Fast development with reasonable perf will be Typescript and high performance with reasonable dev. will be Go.

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.

[ilaksh]

Go and Rust theoretically could be more performant but people who say they need performance from a platform almost never really need performance in that way. They almost always are doing something in a very unoptimized way.

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.

[ecesena]

I’m happily using fiber in go. To be precise, I do definitions in protobuf, use grpc-gateway to auto build the api server, and wrap it with fiber for better middlewares.

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.

[dansult]

I use chi with 'oapi-codegen' to build my endpoints based off my hand rolled openapi spec files.

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.

[ecesena]

I don't have any example that's public atm, but the guide in grpc-gateway is pretty clear/can be followed step by step.

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

[dansult]

Thanks mate.

[logicalmonster]

You didn't provide enough details about the problem you're trying to solve in order to give an informed suggestion.

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?

[pawelduda]

For one person stack, you won't have to worry about hiring devs specialized in your tech. That makes Elixir/Phoenix even more attractive.

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.

[sebnun]

I'm starting to use SST (https://sst.dev/) and really like it so far. The local development experience is great.

So I would say Node.js lambda functions in Amazon API Gateway via SST.

[arrowsmith]

> I achieve Rails-like rapid development without sacrificing performance?

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.

[dyeje]

If your goal is rapid development, maybe consider using server side rendering with Phoenix, Django, Rails, etc.

[revskill]

Why do you need api ?

[dinkleberg]

My go to is using Gin, the Go web framework. But in your scenario, why not use nextjs or sveltekit for both the front and backend? They come with the server side aspect as well? If you’re going to be doing SSR you’ll end up have a front end and two backends.

[dylanhassinger]

Express