Ask HN: Front-end devs, what is your current db and backend of choice? | Hacker News Reader

Ask HN: Front-end devs, what is your current db and backend of choice?

5 pointsjc_81118 comments

I work on the front-end usually with Vue, and am in the process of building out a full-stack project.

I'm sure I don't have to explain the sheer amount of choices (analysis paralysis, yay!), but wanted to hear how other FE devs are doing it. Below are the options I've looked into:

- Supabase

- Nhost

- Xano

Would love to hear from anybody who has experience with the above choices. Any pros/cons of each? Doing research and wading through the BS is tough, especially with lots of conflicting information I'm coming across.

p.s - I know the best answer is "just choose one and build!", but I'm more curious to hear some anecdotes about what others are liking/disliking

View on HN

My current decision tree is like that.

Web applications that can be broken into pages (displaying data) and forms: Laravel (default choice), Livewire

Do I need to have full interactivity on the frontend (Ex. Map, Media player,…): Svelte or Vue

Is it a project that I won't maintain: React (it's easier to find devs).

Do I have time to develop the backend for the SPA: Lumen, Express.js or a micro-framework in one of the languages I like (go,…)

No for the above: I used to go with Firebase. But I've look at others and they're pretty much the same thing.

When I was using Firebase, I've always coded defensively to avoid relying on its features. With React, I've built a layer of functions that interact with Firebase, then built my business logic out of hooks that use those functions. Moving to my own backend can be done with just reimplementing this layer. React-Query was my backup for the realtime capabilities of firestore.

Nhost user here.

Pros:

- The team is very approachable and responsive.

- Hasura is awesome! Especially the relationships. It took a while before it clicked but I don't see myself going back to joins. Also permissions are really powerful.

- Nhost stack allows you to do more complex stuff than with Supabase.

Cons:

- The documentation can sometimes be a bit unclear. Comparing to Supabase they can really improve on this.

- Deploying migrations can be a pain. Took a while before it clicked.

- Not a big community (yet). But they are growing.

Some initial findings I've seen are:

Supabase. Pros: affordable, production ready, and seems relatively quick to get up and running. Cons: Some have mentioned security concerns around how they handle auth, and potential complexity around having lots of application logic at the DB level

Nhost: Seems like a really great Supabase alternative, strong focus on graphQL. Con: they are new with a very small team which always concerns me in the case they need to suddenly shut down in the future

Xano. Pros: Probably the quickest to get up and running and delivering JSON to the frontend. Cons: full "no code" solution as opposed to "low code". They do advertise as being turing-complete and able to do anything code can do, but full no-code always gives me pause for a production application passed an MVP

> Some have mentioned security concerns around how they handle auth

(Supabase maintainer) Just to sure: supabase is secure, audited, pentested, and well-maintained.

You can use it as a Postgres database, connecting to it in a "traditional" way. Or you can use it with some additional tools that we provide on top, so that you don't need to worry about middleware. Both are as secure as each other, but they require you, the developer, to take responsibility for your application security.

The latter relies on Postgres Row Level Security: it's built into Postgres and isn't novel to Supabase (but we are one of the few who really advocate for it because, well, we love Postgres and we're postgres-maxis)

Hi - really appreciate the response here! This is one of the areas that's given me confusion, as a front-end dev I'm not totally familiar with how to securely set-up auth on the backend. My ideal tool would take care of this lift for me. Tbh I was surprised to see people commenting on concerns for Supabase auth as (from what I can tell) it's a battle-tested production ready platform.

> My ideal tool would take care of this lift for me.

we have several starters [0] to get you started. Eventually you will need to become famliar with any auth system you adopt though. We chose RLS, because it's incredibly flexible and compatible with other tools.

But there are a plethora of other tools if you don't want to take that route. If it works with Postgres, it also works with supabase.

[0] https://supabase.com/blog/supabase-bootstrap

Definitely agree with you! When building I fully expect to learn and become comfortable with whichever auth system I'm using, just to start I need one with everything included to avoid attempting to build one myself.

Thanks for the link, will definitely check that out

Pocketbase, it's been a total dream to work with.

How/where are you hosting it?

I have a long running project with thousands of companies using it on a pretty basic stack:

React on the frontend

Node.js on the backend

Postgres as the database (managed by RDS)

Works pretty well!

IndexedDB only, creating local-first apps with import/export and webrtc sync options and no backend, real serverless.

Super curious about your experiences with local-first. Would you mind expanding on your tooling choices and maybe how much experience you have doing local-first? Do you use indexeddb and webrtc directly or through a lib/framework? Are you using one of the big ui frameworks? Do you use wasm for any heavy lifting? Do you have any paid apps you’re shipping as local first?

Backend: been playing with remix and I like it. I need to get a larger full stack project though.

Db: sqlite3

Fresh frontends with Node.js backend + postgress DB.

Current? Hmm, Postgres is the best answer here, but I do have a fair amount of sqlite when there's only 1 write process. Lets also admit to the python pickled flat files lol.

I've used sqlite in more projects than I thought I would

Inspired by Uncle Bob's "just write them to plain files and we'll upgrade to a db later [which never happened]" case

Sailsjs all the way

Django and Postgres

Reply on news.ycombinator.com