17 ms·

Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News. This looks really cool! Honestly I think the Firebase comparison may be thro

by habosa 6y ago

Disclaimer: I work on Firebase but I'm always speaking for myself on Hacker News. This looks really cool! Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system, which means there's a huge base of existing tools/techniques/knowledge to build from. I like any tool which makes it easier to build an app. It's 2020 and we still start every app like this: * Pick a database * Spin up a server * Connect the DB to the server * Create a REST API for the server so the client can talk to the DB * Somehow make that secure enough * Write a bunch of CRUD code on the client What a waste of time! Glad to see people like Supabase taking on this problem as well.

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.
- 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
mercer 6y ago
I can't help but mention that I rather like the alternative approach of keeping steps 1-3, and using Phoenix LiveView (or C#'s Blazor?) for the rest. Not saying it's better or worse, but I quite like it.
- rakoo 6y ago
  If you don't pick a db, where do you store data ?
  - mercer 6y ago
    That would be step one out of the first three that I bother with :).
    - rakoo 6y ago
      I read "skipping steps 1-3" instead of "keeping steps 1-3", my bad. Do you have good resources for learning Elixir with OTP and Phoenix ? I also believe LiveView can deliver the 80% of functionalities for 20% of the price, so I'm very interested in learning it
      - joeyspn 6y ago
        Programming Phoenix 1.4 is probably the best book. Very friendly and easy to follow (and written by the Phoenix and Elixir creators) https://pragprog.com/book/phoenix14/programming-phoenix-1-4 https://pragprog.com/book/phoenix14/programming-phoenix-1-4
      - mercer 6y ago
        I can also recommend Programming Phoenix. I've also heard good things about the LiveView courses on the Pragmatic Studio. "Programming Elixir" and "Designing Elixir Systems with OTP" are also good, the former more so if you get started. From what I remember "Programming Phoenix" was enough to get started though, and these two books are better at getting deeper knowledge of Elixir/OTP.
kiwicopple 6y ago
> Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system You're correct - we're building on top of Postgres so it's not a perfect comparison. And we're a bit early to even make it a fair claim. I'm glad the crowd here has been so receptive. We were planning of launching in September, but it must have been picked up somewhere on the internet (thanks @habosa)
- dandare 6y ago
  Hi, do you plan to be a full BaaS? With Authentication, email confirmations, push notification etc?
  - kiwicopple 6y ago
    Yes! We'll let the customers drive the priorities. Right now Authentication is our #1 focus
    - pier25 6y ago
      Will you provide a Postgres instance too? If not what provider would you recommend?
      - kiwicopple 6y ago
        Yes, we already provide a Postgres instance (https://app.supabase.io https://app.supabase.io)
    - hermit85 6y ago
      Will you provide or are looking into passwordless logins? I currently deal with a lot of support tickets with most of them being for reseting of passwords.
      - kiwicopple 6y ago
        We are still planning our auth system, but this passwordless logins is something that is technically simpler than third-party logins, so I imagine we will. Feel free to create a github issue if you want to track our progress on this one.
pier25 6y ago
There are solutions like Hasura or Fauna which give you a GraphQL server automatically. How come Firebase still doesn't have some sort of agnostic querying layer?

by habosa 6y ago

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

mercer 6y ago

I can't help but mention that I rather like the alternative approach of keeping steps 1-3, and using Phoenix LiveView (or C#'s Blazor?) for the rest. Not saying it's better or worse, but I quite like it.

rakoo 6y ago
If you don't pick a db, where do you store data ?
- mercer 6y ago
  That would be step one out of the first three that I bother with :).
  - rakoo 6y ago
    I read "skipping steps 1-3" instead of "keeping steps 1-3", my bad. Do you have good resources for learning Elixir with OTP and Phoenix ? I also believe LiveView can deliver the 80% of functionalities for 20% of the price, so I'm very interested in learning it
    - joeyspn 6y ago
      Programming Phoenix 1.4 is probably the best book. Very friendly and easy to follow (and written by the Phoenix and Elixir creators) https://pragprog.com/book/phoenix14/programming-phoenix-1-4 https://pragprog.com/book/phoenix14/programming-phoenix-1-4
    - mercer 6y ago
      I can also recommend Programming Phoenix. I've also heard good things about the LiveView courses on the Pragmatic Studio. "Programming Elixir" and "Designing Elixir Systems with OTP" are also good, the former more so if you get started. From what I remember "Programming Phoenix" was enough to get started though, and these two books are better at getting deeper knowledge of Elixir/OTP.

kiwicopple 6y ago

> Honestly I think the Firebase comparison may be throwing some people off here because this is a SQL-based system You're correct - we're building on top of Postgres so it's not a perfect comparison. And we're a bit early to even make it a fair claim. I'm glad the crowd here has been so receptive. We were planning of launching in September, but it must have been picked up somewhere on the internet (thanks @habosa)

dandare 6y ago
Hi, do you plan to be a full BaaS? With Authentication, email confirmations, push notification etc?
- kiwicopple 6y ago
  Yes! We'll let the customers drive the priorities. Right now Authentication is our #1 focus
  - pier25 6y ago
    Will you provide a Postgres instance too? If not what provider would you recommend?
    - kiwicopple 6y ago
      Yes, we already provide a Postgres instance (https://app.supabase.io https://app.supabase.io)
  - hermit85 6y ago
    Will you provide or are looking into passwordless logins? I currently deal with a lot of support tickets with most of them being for reseting of passwords.
    - kiwicopple 6y ago
      We are still planning our auth system, but this passwordless logins is something that is technically simpler than third-party logins, so I imagine we will. Feel free to create a github issue if you want to track our progress on this one.

pier25 6y ago

There are solutions like Hasura or Fauna which give you a GraphQL server automatically. How come Firebase still doesn't have some sort of agnostic querying layer?