Implement {save,remove}Locations resolver #13
Conversation
c-w
force-pushed
the
save-remove-locations-resolver
branch
2 times, most recently
from
64f0b91 to
94d4003
Compare
c-w
force-pushed
the
save-remove-locations-resolver
branch
from
94d4003 to
3e57727
Compare
| 'We now automatically filter events down to only those ' + | ||
| 'locations defined in the geo-fence for your site' | ||
| ); | ||
| }); |
There was a problem hiding this comment.
Do we need to keep these just for backwards compatibility?
There was a problem hiding this comment.
I was wondering that as well. Also, does saveLocations in /resolvers need to be changed, too?
There was a problem hiding this comment.
Yes, the idea is to have the cassandra-based resolvers to be 100% backwards compatible with the Fortis-v1 UI. This has the advantage that once all of our Fortis-v2 backend work is done, we can just hook up the v2 backend to the v1 frontend for a first milestone and then focus on revamping the frontend as a second milestone without having to worry about an in-flux backend.
The methods in /resolvers don't have to be changed as those are the Fortis-v1 implementations which we're not touching. The GraphQL+Cassandra work is entirely localized to Fortis-v2.
As mentioned in project-fortis-spark#17, we no longer need these endpoints as the functionality is now handled directly by Spark.