Hacker News Reader

Comment by reidjs | Hacker News Reader

As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledge.

I’m in the middle of a mongoDB to Postgres migration for a product with 0 users. When you’re trying to scale from 0 to 1 user then everything should help you explore the user’s problem space, even if it seems backwards to build the UI before the backend.

View on HN

> As someone who leans frontend

> I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play

Do you not see the problem with these 2 statements. Of course not dealing with non JavaScript is easier for a JavaScript developer.

> You can get something in front of your users tomorrow.

This is something we’ve been able to do with Rails or Django for nearly 2 decades now. I can do something similar with more interactivity with Phoenix LiveView and Postgres these days.

The logical conclusion would be that you need more frontend than backend when you're trying to scale from 0 to 1.

The OP's premise is that you need more frontend. No comment has any information supporting it, and both are disagreeing on it.

If what you take as conclusion is the premise, you have just been a victim of confirmation bias.

In my experience, if you're not using Heroku, getting a Rails/Django app launched requires at least a day or two dedicated to devops faffing about (creating server instances, setting up CDNs, making sure the database is minimally correct, having some kind of deploy script or something). This won't even get you nice to have things like multiple environments with CI and deploy previews. Switching over to serverless can reduce that to less than one day and get you deploy previews. Is that a good tradeoff? It just depends on the app, and how long lived it will be, what the performance requirements are, the costs of hosting, etc. For my needs, it's often easiest to just use Netlify's AWS Lambda adaptors.

I’m not arguing about setting up your own infrastructure. Heroku launched when rails was 2 years old. What’s the point of this comparison if you arbitrarily handicap the most common rails deployment environment?

Agree with starting focusing on UI first. But haven’t seen a speed advantage at this stage of serverless vs a simple monolithic backend app with a bunch of endpoints. You can get something in front of users within hours. Either way allows you to overengineer and focus on the wrong thing.

Agreed, and the upside to to having a monolithic backend is that if/when your app gets serious you don't have to port it or redo it. Sure there are definitely large apps that use Firebase et al, but much more often than not for reasons of cost or compliance or customization, the backend ends up getting written later anyway and APIs usually need to change.

Agreed, I can get something up and running using Express or FastAPI (frontend + backend) easily in a few hours, whereas Firebase would be new to me. Use whatever you know/can to get something in front of the user.

I don't necessarily disagree with this, but I think the difference isn't between frontend and backend, it's between strongly typed and weakly typed, or structured and unstructured. The strength and weakness of Firebase and MongoDB is that they let you shove unstructured data into the db without defining a schema.

Once you have any users at all, you need to migrate that data every time your data model changes. When you need to migrate data, not having a schema goes from a blessing to a curse, because you're trying to change the structure of unstructured data.

For this reason, I'm skeptical of both sides of the coin. I'd almost rather start with an ephemeral in-memory store that forces you to rewrite before you have actual users, rather than be tempted by MongoDB or Firebase.

Scaling from 0 to 1 user? Is this a personal project?

Nope

+1 on Firebase. I recently helped a buddy build an app and decided to give it a try. Holy crap. All we had to was build the app! significantly faster than either of us estimated.

Be careful with this, especially with mobile apps that can't be easily updated. Using Firebase has a tendency to put what would otherwise be backend logic into the frontend, which can make it much harder to make changes quickly once your app has users.

I would recommend learning backend (which is much easier than frontend!). If you have basic backend skills then you can do the frontend and the backend just as easily, and it gives you a lot more flexibility going forwards.

What is there even to migrate??

Maybe you meant from 1 user to more than 1? I mean, unless is building dust on a shelf, anything running in a computer has at least 1 user.

Reply on news.ycombinator.com