4 ms·

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

by reidjs 5y ago

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.

awb 5y ago
Scaling from 0 to 1 user? Is this a personal project?
- reidjs 5y ago
  Nope
teaearlgraycold 5y ago
What is there even to migrate??
unnouinceput 5y ago
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.
smoe 5y ago
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.
- freedomben 5y ago
  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.
- mmcnl 5y ago
  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.
learc83 5y ago
> 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.
- mmcnl 5y ago
  The logical conclusion would be that you need more frontend than backend when you're trying to scale from 0 to 1.
  - marcosdumay 5y ago
    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.
- earthboundkid 5y ago
  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.
  - learc83 5y ago
    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?
madmax96 5y ago
+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.
- nicoburns 5y ago
  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.
nicoburns 5y ago
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.
strken 5y ago
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.

by reidjs 5y ago

awb 5y ago

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

reidjs 5y ago
Nope

teaearlgraycold 5y ago

What is there even to migrate??

unnouinceput 5y ago

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.

smoe 5y ago

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.

freedomben 5y ago
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.
mmcnl 5y ago
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.

learc83 5y ago

> 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.

mmcnl 5y ago
The logical conclusion would be that you need more frontend than backend when you're trying to scale from 0 to 1.
- marcosdumay 5y ago
  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.
earthboundkid 5y ago
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.
- learc83 5y ago
  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?

madmax96 5y ago

+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.

nicoburns 5y ago
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.

nicoburns 5y ago

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.

strken 5y ago

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.