This question already has answers here:
Apollo GraphQL: Call a Mutation from the Server?
(2 answers)
Closed 2 years ago.
I have a Meteor app that uses Apollo and I am using SyncedCron (https://github.com/percolatestudio/meteor-synced-cron) to schedule an update operation on the database every 2 hours.
Every two hours, fetch X data from some external API and store in Y collection of the database. Rinse and repeat.
My question is this: should this update operation be implemented as a graphQL mutation, and called server-side from within the cron job (if so, how do you do it?!), or should this be implemented as a normal JS function since it will only ever execute on the server?
All the mutation examples I can find online are invoked from the client by wrapping your View component in a graphql-enabled HOC.
Perhaps I am just misunderstanding the scope of mutations, and the larger question here is whether or not mutations CAN be invoked from the server, or if they are client-side only.
Hoping to find some clarification here on mutation best practices. Thanks!
I think you would just use axios (http call) or a meteor method here. I think mutations are just for browser-to-server.
Related
Firebase documentation recommends including code snippet given at (https://firebase.google.com/docs/functions/networking#https_requests) to optimize the networking, but few details are missing. Like
How exactly does this help?
Are we supposed to call the function defined as per of recommendation
or include this snippet deploy?
Any documentation around this would be of great help.
this is an example showing you how you would make this request, the key part in this example is the agent field which by nature isn't normally managed within your app. By injecting a reference to it manually, you are able to micro-manage it and it's events directly.
As for the second question, it really depends on your cloud function needs - some users set it in a global object that they manage with all cloud functions but it's on a by-use case basis. but ultimately isn't required.
You can read more about HTTP.Agent's and their usage below:
https://nodejs.org/api/http.html
https://www.tabnine.com/code/javascript/functions/http/Agent
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent
This question already has answers here:
How do you prevent duplicate user properties in Firebase?
(2 answers)
Closed 3 years ago.
I want to add rule so that no duplicate rdate is added in database.
I am beginner to firebase and i don't know how to create rules for stopping duplicate.
This isn't possible with security rules, because rules don't have a way of performing queries for other nodes. The only way you can access other nodes in the database is using val() at the specific location you're interested in knowing about, but you have to know the full path to that specific location.
Your alternative is to make a request through a backend you control (such as Cloud Functions), and have that backend perform the query to check if there is a conflict.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am building an application and am not sure how to phrase this question in a way that would help me find anything on Google.
My question is: When using a Vuex store along with some additional classes, is it best practice for the view components to access those classes directly or should they only be accessed through the store?
More detail: Currently, my project has a Vuex store with modules (userModule manages the current logged-in user, uiModule manages certain user-interface elements' visibility and content, etc).
I also have some services. AuthService contains the methods for communicating with Firebase's Auth, DatabaseService contains Firestore read/write methods.
I import the services into the Vuex store modules that require them, and access them as needed through the Store. Reading over my code, in some cases I have accessed the services directly from the view - for instance, Login.vue imports AuthService and accesses it directly. like so:
import authService from '../services/auth.service';
export default {
...
computed() {
authService() { return authService }
}
...
}
<button>{{authService.auth.currentUser() ? 'log out' : 'log in'}}</button>
I think overall it would be better to use the Store, as it would reduce the number of times I import the same object - though I'm not sure how much of a concern it is to import the same object multiple times. Confirmation and discussion are appreciated.
Thanks!
There's no penalty for importing the same module multiple times throughout your project, the top-level code in that module will only be executed once.
I don't think there's a right or wrong answer to your question (it may get closed for being "opinion-based").
Every time you import a module, it becomes a direct dependency of the importing module. This may make unit testing more difficult – how can you cleanly mock the imported module? (Certainly there are ways to do this, I'm just playing devil's advocate.)
When you expose the service class directly on the component instance like you have, then the service class becomes dependent on Vue now because the data properties it exposes need to be reactive for it to be used within the template like that. Vue will make all the properties on the class reactive now. The class implementation also needs to be aware that this will happen and it must comply with Vue's reactivity limitations when it mutates its own data.
For something simple like getting the current user, to me that seems more appropriate to store in Vuex instead of requiring every module import auth.service.
Try to maintain only a single "source of truth", don't share the ownership of data around because it becomes difficult to maintain.
I am developing a simple farming game backend using meteor.
So Server needs to check all players farm data and based on that for example increment
production:0
field each second if player has a farm.
What is the best way to do that ?
Should i use Meteor.setTimeout()
You should use Meteor.setTimeout if you don't manually want to bind fibers to the callback function.
Related issues:
What's going on with Meteor and Fibers/bindEnvironment()?
Meteor wrapAsync or bindEnvironment without standard callback signature
However, you can also use the native JS setTimeout but you will have to manually bind a fiber to the callback (if you aim to use for example Mongo) using Meteor.bindEnvironment or Meteor.wrapAsync.
Another interesting tool is Meteor.defer which is similar to Meteor.setTimeout(func, 0) and allows to execute code in the background. Beware of several layers of callbacks when mixing with Meteor.setTimeout.
Ans yet another tool when executing complex services in a method is this.unblock.
Applying these tools in an appropriate way will make your timer based update possible.
My best guess is to use something in a Session, but say you'd want a singleton object which persists across all active sessions? Just getting started with MeteorJS and not finding a lot of answers yet on StackOverflow.
If you want it to be shared across browsers and machines, then you should use a Collection and insert/update the singleton value in it. The document will be persisted across sessions which choose to subscribe to it.
However, if meant active sessions in one single browser but possibly separated by tab and time (and you do not want to use the backend), then I would suggest using the amplify package and putting that document in the localStorage.