Skip to content

Node 6 implementation #2

Closed
Closed

Description

@flovilmart

Hey @ranhsd, I'm currently scaling up a bit,

I tweaked a few thing there, what do you think?

https://github.com/AmpMe/parse-server-gcloud-pubsub

Activity

  1. ranhsd commented on Feb 23, 2017

    @ranhsd
    Collaborator

    Hi @flovilmart are you running your app inside container engine? i am asking it because from your code i understand that GCLOUD_PROJECT and GOOGLE_APPLICATION_CREDENTIALS are mandatory but if you run inside google container engine or inside GCP then those params are not required. Also what about unsubscribe? I noticed that you didn't implemented the unsubscribe and i think that we must find a better solution (than SIGTERM or SIGINT) something from the platform...

  2. flovilmart commented on Feb 23, 2017

    @flovilmart
    ContributorAuthor

    I believe those env variables are set by default on container engine and app engine. I'm running on kubernetes.

    Also, we could transform those as warnings or make sure the google platforms set them.

    For the unsubscribe, I'm not sure how to correctly destroy those. We should probably add the event handlers in this code no?

  3. ranhsd commented on Feb 23, 2017

    @ranhsd
    Collaborator

    Hi ,

    1. In order to use pub/sub in container engine only need to allow access from container engine to pub/sub (a step that needs to be done when you create your cluster). I totally agree about the warnings but even if GCP set those env variables you need to know the name of them in order to check it in the app.

    2. From what i noticed there will be only 2 subscriptions (one for afterSave and another one for afterDelete) each one will be located under one topic so if this is really the case we can assume that they will be there until the user/admin will manually delete them

  4. flovilmart commented on Feb 23, 2017

    @flovilmart
    ContributorAuthor

    GCP set those env variables you need to know the name of them in order to check it in the app.

    This is part of google authentication docs, https://developers.google.com/identity/protocols/application-default-credentials I agree I should probably remove the warning and let the calls fail naturally.

    From what i noticed there will be only 2 subscriptions

    2 subs / live query server, which can add up to a lot with kubernetes if those are not destroyed :)

  5. ranhsd commented on Feb 23, 2017

    @ranhsd
    Collaborator

    I agree about the k8s one because each time you update a version (for instance) it will power off and power on the new instances according to your replica set ...
    So it looks like that we need to go with the SIGINT and SIGTERM approach until we will find a better way to do it... what do you think ?

  6. flovilmart commented on Feb 23, 2017

    @flovilmart
    ContributorAuthor

    that seems to be reasonable, unless we have a way to clear up subscriptions that are unused for a while.

  7. ranhsd commented on Feb 23, 2017

    @ranhsd
    Collaborator

    Let's tested it and see if it works well. Do you know how it is implemented in Redis adapter?

  8. flovilmart commented on Mar 13, 2017

    @flovilmart
    ContributorAuthor

    @ranhsd I added SIGINT/SIGTERM handlers to delete the subscription, works OK when removing, the process.exit(0) on parse-server CLI. parse-community/parse-server#3634

  9. ranhsd commented on Mar 13, 2017

    @ranhsd
    Collaborator

    Hi @flovilmart did you change also the pub/sub adapter ?

  10. flovilmart commented on Mar 13, 2017

    @flovilmart
    ContributorAuthor

    Yup there too: #3

  11. ranhsd commented on Mar 13, 2017

    @ranhsd
    Collaborator

    Ok. I merged it. Love the idea that we are not using babel anymore. I will also change it on the other adapter (the firebase authentication)

  12. ranhsd commented on Mar 19, 2017

    @ranhsd
    Collaborator

    @flovilmart You are using this adapter only in production or you also use it for development mode? Currently i am planning to use this one in production only scenarios and use Redis for development

  13. flovilmart commented on Mar 19, 2017

    @flovilmart
    ContributorAuthor

    We're planing to deploy to prod in the upcoming weeks. We're deploying in dev and scaling it across multiple AZ to see how it goes

  14. flovilmart commented on Apr 17, 2017

    @flovilmart
    ContributorAuthor

    Closing as implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions