- it just feels safer to not run a cypher statement if there is no user
in the idsOfUsers array. Why risk notifications pointing to empty
nodes? It doesn't seem like this happens, but I'm not sure how to write
a test to verify, and why run cypher statements, if there is no need to?
- I believe the cypress test is so fast that we visit the post/create
page before the relationship CATEGORIZED is added, and therefore, we
must refresh the page.
- I am not happy about this solution, but I'm not sure what we can do...
maybe wait for the post to be succesfully created with all it's
relationships?
- The default limit is only 100kb
- we are getting many requests that exceed this limit
- not sure about what would be an appropriate limit, but have seen 50mb
in many examples.
- for some reason RedisPubSub works locally, but with docker it tries to
connect to Redis and therefore it doesn't pass the build. PubSub is
imported from graphql-subscriptions which is a dependency of
apollo-server-express, and suitable for dev purposes.
- add hasBlocked query to check if userA initiated the blocking and, if
true, only them to unblock userB.
- add cypress tests to make sure we don't break this in the future.
reason: Rosie.js does not support promises. So for the time being, we
shall not use more than one `after` callback and we shall not use
buildList as it does not return a `Promise.all([])`. We have to ask the
maintainers of Rosie.js if they accept the breaking change of returning
a Promise always.
- it's questionable whether this simplifies it or not, and actually adds
one line of code, but now it looks more similiar to the code in the
notifications query
- remove the code for subscriptions to Post as we won't implement this
at this time... I've created a new branch with the code that can be
built on later
- remove unused subscription path
- add possibility to use websockets uri for production env.
- we have introduced a better way to return all the info we want without
needing to make multiple database queries. It was introduced by
@roschaefer in the PR for the notifications query, but we hadn't
refactored markAsRead yet.
- Now that we are subscribing to notifications, we need to have the same
return info as the notification query.
- Co-authored-by: Tirokk <wolle.huss@pjannto.com>
- We want to publish when a notification occurs for a specific user, not
have the client poll the backend for ever user every minute.
- Co-authored-by: @Tirokk <wolle.huss@pjannto.com>
- Also, use original verifiedAt date for emails. These users only have
newly created accounts/emails because of our blunder. Their nodes
should reflect when they became members/verified their emails.
