6 ms·

Maybe I am an old fart, but what’s wrong with the steps you mention? What would your ideal sequence of steps be? If the answer is “just call an api to handle y

by pm90 6y ago

Maybe I am an old fart, but what’s wrong with the steps you mention? What would your ideal sequence of steps be? If the answer is “just call an api to handle your data” sure that works for POCs/Small apps. But I’m a bit hesitant to put all my businesses data inside a proprietary data store that I don’t control and which isn’t collocated with my app (Ie every data store request makes a round trip to the google server hosting the firebase app... maybe not a huge deal if the app itself is in google cloud?) Disclaimer: I’ve only used firebase tangentially, haven’t built an app from scratch with it.

time0ut 6y ago
I've used Firebase for a couple MVPs. It is very fast to develop on. It makes it easy to get a web or mobile app up in a few hours once you know what you're doing. It is definitely possible to be that fast using other technologies, but the learning curve is higher. When you're just experimenting, trying to find market fit and get something to stick, Firebase is a decent solution. I haven't tried anything sizeable on it though. Eventually, I'm sure we would've migrated if we were successful enough.
- ta17711771 6y ago
  I've seen this sentiment echoed a few times. What are the advantages, or class of advantages, you get by moving on from Firebase to something stronger/harder?
  - varrock 6y ago
    I’m very junior, so take what I say with a grain of salt. But when I was determining if I should use Firebase or not, my biggest hesitation was simply that if Firebase ended today, I have to completely transition my application’s architecture. Though that is unrealistic, even thinking about it was enough to make me want to be in full control of my application’s various layers.
    - nogabebop23 6y ago
      This is not a junior consideration and it's not unrealistic that firebase ends in say, the next 60 days which in terms of porting your entire application is essentially today. You're right to weigh this as a concern in evaluating approaches and everyone should, regardless of experience. All PaaS providers work hard to couple you to their platform not (necessarily) for nefarious reasons, but because that's how abstractions work. You need to be continuously vigilant and aware of when and how you are tied, do a cost/benefit analysis and have risk mitigations for things like your original thought, so good for you.
    - marcospolanco 6y ago
      You are bringing a senior consideration to the table; they can and do change their pricing at any time for any reason. Also, every single day you rely on them is a day that your architecture grows on that volatile cornerstone. Would look at https://parseplatform.org/ https://parseplatform.org/ or https://postgrest.org/ https://postgrest.org/ as alternatives; turnkey, hosted solutions are available for each.
  - time0ut 6y ago
    I expect that our business logic would eventually have outgrown rules and cloud functions. We used algolia to do full text and geo search. It worked, but I expected eventually it'd be really painful to reindex. Same sort of thing with analytics. Firebase analytics is pretty powerful, but eventually we would want all our data mirrored somewhere we could use regular BI tools. Then there is cost. We would have to weigh the cost of rewriting against the GCP bill, but at some point I expect it'd make sense. Take this all with a grain of salt. We didn't get far enough to test any of these assumptions.
    - agustif 6y ago
      You can leverage Postgres full-text search, and GeoJSON/PostGIS support. Also for replacing algolia ElasticSearch comes to mind, that should work for most of those use cases. For analytics and in the SaaS part you have both mixpanel and segment, and also some nice privacy-aware alternatives to Google analytics like fathom and some other indie startup. Recently some open source segment alternative came along in HN... MS PowerBI connects with lots of stuff, although it's paid ELK is open source Also metabase is a nice open source tool for BI. Lots of tools!
      - time0ut 6y ago
        What I was trying to say is that I was anticipating having to write and maintain a bunch of glue between firebase and these tools and maybe eventually outgrowing this glue. A benefit of using a traditional SQL database is much of this stuff exists already off the shelf. Maybe Firebase is there or is getting there. It's almost two years since I built something on it.
eatonphil 6y ago
It's not bad doing it once. Furthermore I'd suggest you do it truly from scratch once just for the learning experience (no framework [Go makes this easy] or from TCP socket [synchronous with Python is easy]). However it's ridiculous going through the same sequence for every single app you build over a career. Nothing changes, it's all just boilerplate. I don't want to ever write this sort of boilerplate code again, I want it generated from a DB schema or something similar [0]. There are better things to spend time on. [0] https://news.ycombinator.com/item?id=23322300 https://news.ycombinator.com/item?id=23322300
- halfdan 6y ago
  Ruby in Rails has this as a feature called "scaffold". https://www.rubyguides.com/2020/03/rails-scaffolding/ https://www.rubyguides.com/2020/03/rails-scaffolding/
  - eatonphil 6y ago
    Rails is probably one of the best ways to not waste time. I knew they had some of this capability but I wasn't sure if they generated the whole controller, fully hooked up to the models, too. The only thing that turns me off about Rails and .NET is that it's a big learning curve _because_ the projects are so feature complete. Since I haven't worked professionally in either of them, I haven't been able to get myself to learn either well enough to do rapid prototyping.
    - freedomben 6y ago
      Agreed, this is a real problem. I recently did a test. I have about a year of rails experience but it was so long ago that I forgot most things and had to look them up. I also wrote quite a bit of node/express but it was in the node 0.10 days so I had a lot of catch-up to do. I started a new app and I got a basic Users and Sessions model with endpoints running (I like this test because dealing with passwords and API tokens requires writing some code instead of generating it all, but also leverages libraries). These numbers aren't useful by themselves since you don't know the details of the work I did, but they may be useful side by side: Express/TypeScript: Took me about 24 to 30 hours to get it all implemented. I started with no ORM (node-postgres) then tried out Knex, then settled on Slonik.js. Because of that I had to re-write some stuff a few times. However, in a bare-bones "framework" this is part of the penalty. Rails: Took about 10 hours (mostly reading documentation and Michael Hartl's book). I think I prefer the Node approach simply because I know exactly what is going on under that hood. That said however, if I were a second developer coming into the code base I'd prefer the Rails approach because I'd have to learn "the framework" anyway and a widespread standardized one like Rails would be preferable to learn IMHO. In conclusion: My numbers are highly individualized and don't tell the whole story of course. In related news, I actually threw both of them away and went back to Elixir/Phoenix, my third love. I'm quite happy there at the moment, and I don't anticipate moving again.
beisner 6y ago
Excellent for deploying small auxiliary apps that are not necessarily your company’s core competency, or a side project.
DarkWiiPlayer 6y ago
What's more, in the days of IaaS you can just as easily spin up a new server in some web interface, copy-paste a setup script you wrote once and after getting a coffee you come back to a working database server that does 90% of what you need. How much automation we use is independent of how much of this automation we decide to outsource. EDIT: But hey, maybe that's just me not understanding the 2020 mentality of "Take my data and make it work" well enough
grizzles 6y ago
My ideal would be sqlite in the back, sqlite in the browser, with a sync table that uses database triggers for managing a log of the normal tables. I've written a few more thoughts here: https://github.com/ericbets/erics-designs/blob/master/funcdb.md https://github.com/ericbets/erics-designs/blob/master/funcdb...
- midrus 6y ago
  That's pretty close to the pouchdb + (couchdb|cloudant) combo...
  - mauflows 6y ago
    If pouchdb was better maintained I feel like it would be much more popular. IBM should really sponsor it considering they even list it as a cloudant client

by pm90 6y ago

time0ut 6y ago

I've used Firebase for a couple MVPs. It is very fast to develop on. It makes it easy to get a web or mobile app up in a few hours once you know what you're doing. It is definitely possible to be that fast using other technologies, but the learning curve is higher. When you're just experimenting, trying to find market fit and get something to stick, Firebase is a decent solution. I haven't tried anything sizeable on it though. Eventually, I'm sure we would've migrated if we were successful enough.

ta17711771 6y ago
I've seen this sentiment echoed a few times. What are the advantages, or class of advantages, you get by moving on from Firebase to something stronger/harder?
- varrock 6y ago
  I’m very junior, so take what I say with a grain of salt. But when I was determining if I should use Firebase or not, my biggest hesitation was simply that if Firebase ended today, I have to completely transition my application’s architecture. Though that is unrealistic, even thinking about it was enough to make me want to be in full control of my application’s various layers.
  - nogabebop23 6y ago
    This is not a junior consideration and it's not unrealistic that firebase ends in say, the next 60 days which in terms of porting your entire application is essentially today. You're right to weigh this as a concern in evaluating approaches and everyone should, regardless of experience. All PaaS providers work hard to couple you to their platform not (necessarily) for nefarious reasons, but because that's how abstractions work. You need to be continuously vigilant and aware of when and how you are tied, do a cost/benefit analysis and have risk mitigations for things like your original thought, so good for you.
  - marcospolanco 6y ago
    You are bringing a senior consideration to the table; they can and do change their pricing at any time for any reason. Also, every single day you rely on them is a day that your architecture grows on that volatile cornerstone. Would look at https://parseplatform.org/ https://parseplatform.org/ or https://postgrest.org/ https://postgrest.org/ as alternatives; turnkey, hosted solutions are available for each.
- time0ut 6y ago
  I expect that our business logic would eventually have outgrown rules and cloud functions. We used algolia to do full text and geo search. It worked, but I expected eventually it'd be really painful to reindex. Same sort of thing with analytics. Firebase analytics is pretty powerful, but eventually we would want all our data mirrored somewhere we could use regular BI tools. Then there is cost. We would have to weigh the cost of rewriting against the GCP bill, but at some point I expect it'd make sense. Take this all with a grain of salt. We didn't get far enough to test any of these assumptions.
  - agustif 6y ago
    You can leverage Postgres full-text search, and GeoJSON/PostGIS support. Also for replacing algolia ElasticSearch comes to mind, that should work for most of those use cases. For analytics and in the SaaS part you have both mixpanel and segment, and also some nice privacy-aware alternatives to Google analytics like fathom and some other indie startup. Recently some open source segment alternative came along in HN... MS PowerBI connects with lots of stuff, although it's paid ELK is open source Also metabase is a nice open source tool for BI. Lots of tools!
    - time0ut 6y ago
      What I was trying to say is that I was anticipating having to write and maintain a bunch of glue between firebase and these tools and maybe eventually outgrowing this glue. A benefit of using a traditional SQL database is much of this stuff exists already off the shelf. Maybe Firebase is there or is getting there. It's almost two years since I built something on it.

eatonphil 6y ago

It's not bad doing it once. Furthermore I'd suggest you do it truly from scratch once just for the learning experience (no framework [Go makes this easy] or from TCP socket [synchronous with Python is easy]). However it's ridiculous going through the same sequence for every single app you build over a career. Nothing changes, it's all just boilerplate. I don't want to ever write this sort of boilerplate code again, I want it generated from a DB schema or something similar [0]. There are better things to spend time on. [0] https://news.ycombinator.com/item?id=23322300 https://news.ycombinator.com/item?id=23322300

halfdan 6y ago
Ruby in Rails has this as a feature called "scaffold". https://www.rubyguides.com/2020/03/rails-scaffolding/ https://www.rubyguides.com/2020/03/rails-scaffolding/
- eatonphil 6y ago
  Rails is probably one of the best ways to not waste time. I knew they had some of this capability but I wasn't sure if they generated the whole controller, fully hooked up to the models, too. The only thing that turns me off about Rails and .NET is that it's a big learning curve _because_ the projects are so feature complete. Since I haven't worked professionally in either of them, I haven't been able to get myself to learn either well enough to do rapid prototyping.
  - freedomben 6y ago
    Agreed, this is a real problem. I recently did a test. I have about a year of rails experience but it was so long ago that I forgot most things and had to look them up. I also wrote quite a bit of node/express but it was in the node 0.10 days so I had a lot of catch-up to do. I started a new app and I got a basic Users and Sessions model with endpoints running (I like this test because dealing with passwords and API tokens requires writing some code instead of generating it all, but also leverages libraries). These numbers aren't useful by themselves since you don't know the details of the work I did, but they may be useful side by side: Express/TypeScript: Took me about 24 to 30 hours to get it all implemented. I started with no ORM (node-postgres) then tried out Knex, then settled on Slonik.js. Because of that I had to re-write some stuff a few times. However, in a bare-bones "framework" this is part of the penalty. Rails: Took about 10 hours (mostly reading documentation and Michael Hartl's book). I think I prefer the Node approach simply because I know exactly what is going on under that hood. That said however, if I were a second developer coming into the code base I'd prefer the Rails approach because I'd have to learn "the framework" anyway and a widespread standardized one like Rails would be preferable to learn IMHO. In conclusion: My numbers are highly individualized and don't tell the whole story of course. In related news, I actually threw both of them away and went back to Elixir/Phoenix, my third love. I'm quite happy there at the moment, and I don't anticipate moving again.

beisner 6y ago

Excellent for deploying small auxiliary apps that are not necessarily your company’s core competency, or a side project.

DarkWiiPlayer 6y ago

What's more, in the days of IaaS you can just as easily spin up a new server in some web interface, copy-paste a setup script you wrote once and after getting a coffee you come back to a working database server that does 90% of what you need. How much automation we use is independent of how much of this automation we decide to outsource. EDIT: But hey, maybe that's just me not understanding the 2020 mentality of "Take my data and make it work" well enough

grizzles 6y ago

My ideal would be sqlite in the back, sqlite in the browser, with a sync table that uses database triggers for managing a log of the normal tables. I've written a few more thoughts here: https://github.com/ericbets/erics-designs/blob/master/funcdb.md https://github.com/ericbets/erics-designs/blob/master/funcdb...

midrus 6y ago
That's pretty close to the pouchdb + (couchdb|cloudant) combo...
- mauflows 6y ago
  If pouchdb was better maintained I feel like it would be much more popular. IBM should really sponsor it considering they even list it as a cloudant client