5 ms·

The term Serverless is meant to illustrate that by using things like the Firebase ecosystem and namely the Firestore database, the most common database operatio

by vfc1 7y ago

The term Serverless is meant to illustrate that by using things like the Firebase ecosystem and namely the Firestore database, the most common database operations such as CRUD operations can be done in a secure way straight from the client side without having to develop server endpoints, such as for example REST endpoints. This is possible because the data modification operations are triggered directly on the frontend using a SDK, and they are sent straight to the service provider, which will then validate if the operation can go through, like for example checking if the user is authenticated and has write access to the data. No application code is involved in this process, other than the client-side code. Not having to constantly hand-code REST endpoints just for doing secure CRUD is huge!

pjc50 7y ago
Indeed. Firebase seems to be the leader here, who else is competing on "Not having to constantly hand-code REST endpoints just for doing secure CRUD"?
- vfc1 7y ago
  I thought there would be competitors, I don't know why Firebase is not getting more adoption then, it's still a bit of a niche and Google does not seem to be pushing it as much as a couple of years ago, even though the product is better than ever.
  - sojournerc 7y ago
    In our case, it's because we have more than web/mobile clients talking to our API. If the business case doesn't require partner/3rd party API access, then maybe Firebase is appropriate. Mentioned elsewhere in the comments here is the risk of vendor lock-in. Given Google's history of EOLing products from under developers, there is real risk in putting all the business logic eggs in the Google basket.
    - vfc1 7y ago
      Firebase is like a web developer friendly version of Google Cloud, that it bases itself on. It gives easy to use serverless CRUD (with Firestore), authentication, authorization, secure file upload, hosting and server-side functions for things like image processing or database triggers. I don't think Firebase will be end of live anytime soon, worst case it's user base would get migrated to Google Cloud, as it's really just Google Cloud under the hood. I don't think it's an option for Google to give up on the cloud at this point, even though AFIK Amazon has the biggest market share.
  - latchkey 7y ago
    AWS Amplify is the competition.
latchkey 7y ago
I use firebase, heavily. The issue with that design pattern is that you end up with those hand-coded REST (or GraphQL) endpoints anyways. You can't push all the business logic into the client because as soon as you do that, you end up duplicating all the business logic twice when you want to add a different client (especially in a different language). For example, I have my Flutter phone app which is primarily for inputting data. I'm not going to put all the logic for talking to the firestore in the app because I also need to have a backend management app for viewing/editing all the data, which is web based. So, instead, I built the logic into firebase functions via a graphql interface. Now both the phone and web clients can talk to graphql and share that single typesafe interface. It is really nice that firebase is this flexible though. You can pick and choose and it is still relatively easy to secure the backend by using firebase functions.

by vfc1 7y ago

pjc50 7y ago

Indeed. Firebase seems to be the leader here, who else is competing on "Not having to constantly hand-code REST endpoints just for doing secure CRUD"?

vfc1 7y ago
I thought there would be competitors, I don't know why Firebase is not getting more adoption then, it's still a bit of a niche and Google does not seem to be pushing it as much as a couple of years ago, even though the product is better than ever.
- sojournerc 7y ago
  In our case, it's because we have more than web/mobile clients talking to our API. If the business case doesn't require partner/3rd party API access, then maybe Firebase is appropriate. Mentioned elsewhere in the comments here is the risk of vendor lock-in. Given Google's history of EOLing products from under developers, there is real risk in putting all the business logic eggs in the Google basket.
  - vfc1 7y ago
    Firebase is like a web developer friendly version of Google Cloud, that it bases itself on. It gives easy to use serverless CRUD (with Firestore), authentication, authorization, secure file upload, hosting and server-side functions for things like image processing or database triggers. I don't think Firebase will be end of live anytime soon, worst case it's user base would get migrated to Google Cloud, as it's really just Google Cloud under the hood. I don't think it's an option for Google to give up on the cloud at this point, even though AFIK Amazon has the biggest market share.
- latchkey 7y ago
  AWS Amplify is the competition.

latchkey 7y ago

I use firebase, heavily. The issue with that design pattern is that you end up with those hand-coded REST (or GraphQL) endpoints anyways. You can't push all the business logic into the client because as soon as you do that, you end up duplicating all the business logic twice when you want to add a different client (especially in a different language). For example, I have my Flutter phone app which is primarily for inputting data. I'm not going to put all the logic for talking to the firestore in the app because I also need to have a backend management app for viewing/editing all the data, which is web based. So, instead, I built the logic into firebase functions via a graphql interface. Now both the phone and web clients can talk to graphql and share that single typesafe interface. It is really nice that firebase is this flexible though. You can pick and choose and it is still relatively easy to secure the backend by using firebase functions.