Firebase and backend logic

后端 未结 3 816
梦如初夏
梦如初夏 2020-11-30 02:16

I am parse.com user, and now I look for another service. How can I write back end logic to firebase?

let say I want to validate all the values on server side, or t

相关标签:
3条回答
  • 2020-11-30 02:51

    2017

    Today Google announced Cloud Functions for Firebase https://firebase.google.com/features/functions/

    This is a great solution for the architectures and back end logic in Firebase.

    0 讨论(0)
  • 2020-11-30 02:53

    Here's what I would do:

    • Validade all the inputs with the ".validate" rules. No server needed for that.
    • If you have tasks to run, use Firebase Queue, a bot to run the tasks and you are done.

    If you don't do the last one, you may have two problems:

    • If you try use the diagram you posted it will be a little tricky to get the auth object at the server (but not impossible). Go ahead if you don't need to validate the user to allow the request.

    • If you use just the regular firebase app to listen to changes and respond (editing the object for instance, like Frank van Puffelen's example code), you might have scalability problems. Once your back end scales to two (or more) instances, a firebase edit will trigger the task on all of them. Each instance will notice there was a change, then run the same task once each, add/replace the response object once each and try to remove the request object once each..

    Using Firebase Queue avoids both of these problems.

    0 讨论(0)
  • 2020-11-30 03:06

    Update (March 10, 2017): While the architecture I outline below is still valid and can be used to combine Firebase with any existing infrastructure, Firebase just released Cloud Functions for Firebase, which allows you to run JavaScript functions on Google's servers in response to Firebase events (such as database changes, users signing in and much more).


    The common architectures of Firebase applications are pretty well-defined in this blog post Where does Firebase fit in your app?.

    The architecture you propose is closest to architecture 3, where your client-side code talks both directly to Firebase and to your node.js server directly.

    I also highly recommend that you consider option 2, where all interaction between clients and server runs through Firebase. A great example of this type of architecture is the Flashlight search integration. Clients write their search queries into the Firebase database. The server listens for such requests, executes the query and writes the response back to the database. The client waits for that response.

    A simple outline for this server could be:

    var ref = new Firebase('https://yours.firebaseio.com/searches');
    ref.child('requests').on('child_added', function(requestSnapshot) {
    
        // TODO: execute your operation for the request
    
        var responseRef = ref.child('responses').child(requestSnapshot.key());
        responseRef.set(result, function(error) {
            if (!error) {
                // remove the request, since we've handled it
                requestSnapshot.ref().remove();
            }
        });
    })
    

    With this last approach the client never directly talks to your server, which removes all kind of potential problems that you have to worry about. For this reason I sometimes refer to them as "bots", instead of servers.

    0 讨论(0)
提交回复
热议问题