Re:Traits of Serverless Architecture
by latchkey on Tuesday August 20, 2019 @12:12AM
(#20743771)
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.
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.