Give dates to a Cloud Code functions is different on parse-server than Parse.com

[Kira2]

Hi,

The way that the date parameters are given to a Cloud Code function seems different on parse-server and Parse.com. This is how to reproduce it.

Create a Cloud Code function like this:

/**
 * @description Just displays the given date parameter
 */
Parse.Cloud.define("myFunction", function(request, response) {
  console.log(request.params.date);
  response.success();
});

When I call this function through the REST API on Parse.com, the date parameter must have this format {__type: "Date", iso: "2016-02-25T00:00:00.000Z"}. Then, the console displays 2016-02-25T00:00:00.000Z probably because there is a mechanism to deserialize it before calling the function.

The same call with the same parameter on parse-server will make the console display {__type: "Date", iso: "2016-02-25T00:00:00.000Z"}.

So, to be able to continue to use my Cloud Code functions with parse-server, it seems now that I have to directly use 2016-02-25T00:00:00.000Z as a date parameter, instead of {__type: "Date", iso: "2016-02-25T00:00:00.000Z"}. Is this difference normal?

Thanks.

[hramos]

IIRC Cloud Code in hosted Parse does not specify how dates must be passed to arbitrary Cloud Functions. You could use an iso date string, or use the REST API object format, whatever your Cloud function needs/expects.

It seems like the issue raised here is on how console.log(), in hosted Parse Cloud Code, handles the display of the REST API object variant (it prints the iso member, not the whole object). Any JavaScript code that works with request.params.date would still see the full object. This does not seem like a breaking change.

[Kira2]

Hi,

Thank you for your response but I don't understand. Do you mean that the date parameter must always be an iso string now, and that we must not use this format for parse-server: {__type: "Date", iso: "2016-02-25T00:00:00.000Z"}?

I put console.log here to understand why the same call gives a different result on Parse.com and on a local parse-server. And the output is different.

In the real code, I use moment to convert the parameter into a date. It works on Parse.com but not on a local parse-server although the given parameter is the same.

You can try by calling the function below with the REST API, and by passing the date into this format {__type: "Date", iso: "2016-01-10T00:00:00.000Z"}. You'll see that the outputs are good on Parse.com, but not on parse-server (today per default, whatever the given date is). It looks like that the format {__type: "Date", iso: "2016-01-10T00:00:00.000Z"} is automatically transformed into an iso string on Parse.com before being given as a request parameter to the Cloud Code function.

/**
 * @description Just displays the given date parameter
 */
Parse.Cloud.define("myFunction", function(request, response) {
  var date = moment(request.params.date);

  // Log the whole date infos. Should match the date given into the parameter
  console.log(date);
  console.log(date.toISOString());

  response.success();
});

The version of moment I use on Parse.com is the same on my local parse-server.

Thanks.

[joeyslack]

Also seeing this issue ^^

[hramos]

@Kira2 No, there is no restriction on how you pass a parameter to a Cloud function. As I said earlier you can pass dates as strings or as objects, whatever fits your needs.

What I am saying is that the difference you are reporting is a display issue limited to console.log(). The output, or display, differs between Parse.com and Parse Server. That does not change the fact that date is still a JSON object formatted like {__type: "Date", iso: "2016-01-10T00:00:00.000Z"} and your code should work the same in both environments.

[Kira2]

Ok. But none of Cloud Code functions I have on Parse.com, and that receive a date as object, work on parse-server.

[joeyslack]

Same. In mongo, I have items stored as ISODate, and are correctly identifying as "date" columns. When it gets loaded into the PFObject (in Obj-C), even though my property is marked as NSDate, it's getting assigned as an NSString. I'm having to manually convert it to a NSDate in Objective-C.

Something is very wrong here, and threads are getting closed on this issue.

[hramos]

@joeyslack that is not the issue that is being raised in this thread. Can you open a new issue with repro steps?

[Kira2]

Hi,

Why did you close my initial issue? I still have no answer to know what my Cloud Code function That work on Parse.com DO NOT WORK the same way on parse-server. Did you fix this?

[flovilmart]

@Kira2 can you log req.params.date.__type and req.params.date.iso ?

[Kira2]

Hi,

Yes, this is what I get when I try to log request.params.date._type and request.params.date.iso. My function is still this one:

/**
 * @description Just displays the given date parameter
 */
Parse.Cloud.define("myFunction", function(request, response) {
  console.log(request.params.date.__type);
  console.log(request.params.date.iso);

  response.success();
});

On Parse.com:

I2016-03-02T20:33:36.890Z]v850 Ran cloud function myFunction with:
Input: {"date":{"__type":"Date","iso":"2016-01-10T00:00:00.000Z"}}
Result: undefined

I2016-03-02T20:33:36.973Z]No Message provided => console.log(request.params.date.__type)
I2016-03-02T20:33:36.974Z]No Message provided => console.log(request.params.date.iso)

On parse-server:

Date => console.log(request.params.date.__type)
2016-01-10T00:00:00.000Z => console.log(request.params.date.iso)

As I said, even if the function is called with the same parameter with the same format, inside the function, request.params.date is not the same. On Parse.com it is handled like the iso string, and on parse-server, it keeps the object format.

Thanks.

[flovilmart]

How do you call that function? iOS, JS SDK, Android, direct CURL?

[Kira2]

I use the REST API, and I can reproduce it with this call:

curl -X POST \
-H "X-Parse-Application-Id: xxx" \
-H "X-Parse-REST-API-Key: xxx" \
-H "Content-Type: application/json" \
-d '{"date":{"__type":"Date","iso":"2016-01-10T00:00:00.000Z"}}' \
https://api.parse.com/1/functions/myFunction

[flovilmart]

Ok that helps

[flovilmart]

see https://github.com/ParsePlatform/parse-server/compare/flovilmart.troubleshoot655?expand=1#diff-181d6f6ec635edbcdf8d8c3bc329bdefR852

I can't repro the bug with a request call and properly encoded JSON

[Kira2]

Ok, I try to rephrase because you do not understand. I have several functions deployed on Parse.com that work perfectly when I call them by passing a date parameter like that {__type: "Date", iso: "2016-02-25T00:00:00.000Z"}. It seems because, on Parse.com, the date parameter is different once you are inside the function, and you can directly handle it like that, for example:

Parse.Cloud.define("myFunction", function(request, response) {
  var date = new Date(request.params.date); // it works on Parse.com, it gives you an error on parse-server
  response.success(date);
});

If you do the same thing on parse-server, it does not work. What works on Parse.com do no work on parse-server. Why?

Just try this example on Parse.com and on parse-server, and you will see that you will not have the same result.

Thanks.

[flovilmart]

@Kira2 did you get a look to the link I gave you? the req.params.date is properly set, to whatever is passed to the post body.

[Kira2]

Yes I did, but I don't understand why this function works on Parse.com and not on parse-server

Parse.Cloud.define("myFunction", function(request, response) {
  var date = new Date(request.params.date); // it works on Parse.com, it gives you an error on parse-server
  response.success(date);
});

[flovilmart]

You keep giving different use cases for that function. you start with a console.log() that is outputting a string instead of the object, then now it's new Date(). The why question is irrelevant here. the only question is what do you expect req.params.date to be, for what input.

Do you expect it to be a Date object? the object that you passed in cURL or a string?

[Kira2]

I used console.log to give a little piece of code to explain the difference between running a Cloud Code function with date parameters on Parse.com and on parse-server. The goal was to let people reproduce it with a simple code. As I had no answer that explained the difference, I tried with a little more complicated code:

curl -X POST \
-H "X-Parse-Application-Id: xxx" \
-H "X-Parse-REST-API-Key: xxx" \
-H "Content-Type: application/json" \
-d '{"date":{"__type":"Date","iso":"2016-01-10T00:00:00.000Z"}}' \
https://api.parse.com/1/functions/myFunction

Parse.Cloud.define("myFunction", function(request, response) {
  var date = new Date(request.params.date); // it works on Parse.com, it gives you an error on parse-server
  response.success(date);
});

But if nobody try to run this on Parse.com and on parse-server to understand, indeed it is useless.

The "Why" question is not irrelevant, because if there are differences between running my application on Parse.com and on parse-server, I have to know what modifications are necessary to avoid bugs for my users because of the migration.

For now, what I understand is that on Parse.com you can use either one or the other format as date parameter (object or string), it does not matter, they are handled the same way. Not on parse-server.

[flovilmart]

The goal here is to make parse-server and parse.com identical in terms of functionally, they are not.

It seems that your problem is more related to the Date constructor.

And that stil don't answer my question, what do you pass, what you you expect to receive.
Is that the .param.date that is different or when calling new Date(req.param.date) that you experience a weird behaviour?

[Kira2]

The only reason I see that explains why the Date constructor behaves differently on Parse.com and parse-server is because the date parameters are not handled the same way by the Cloud Code on both servers, and what is given to the constructor is different. But I can't spend more time on this. I will try to write a workaround to handle the difference, make my integration tests pass with a local parse-server, and be able to run my Cloud Code function on a local parse-server without a bug.

Thanks.

[flovilmart]

@Kira2, if you believe this is a serious problem, instead of writing a 'workaround' you definitely could propose a PR that solved the issue once and for all, and for everyone.

I'm trying to do my best to understand what the root of the problem is, but it seems that we can't figure it out besides.

Yes, parse.com and parse-server are different, and cloud code is not handled at all the same way as it is on parse.com. As you probably realized, you had to rewrite all your require calls.

I'm on your side here. That's painful that we both wasted our time trying to understand what your issue is without reaching a glimpse of understanding where to start to fix it.

What version of parse-server are you running by the way?

How do you load cloud-code?

How is your parse-server configured?

[Kira2]

I deploy the Cloud Code on Parse.com by using the command line tool given by Parse Parse develop "MyApplicationName".

I use the last release of parse-server 2.1.3. The problem was already here when I tried to run my own parse-server with versions 2.0.8 and above.

The index.js file is like that:

var express = require("express");
var ParseServer = require("parse-server").ParseServer;
var app = express();

var api = new ParseServer({
  databaseURI: "mongodb://localhost:27017/dev",
  cloud: "my_absolute_path_to/cloud/main.js",
  appId: "appId",
  masterKey: "masterKey",
  fileKey: "fileKey",
  serverURL: "http://localhost:1337/parse"
});

// Serve the Parse API on the /parse URL prefix
app.use("/parse", api);

app.listen(1337, function() {
  console.log("parse-server running on port " + port);
});

I would like to give more, understand what happens here and find an answer for everybody. But the only thing I can do is to give a way to reproduce what I see. Running my last example on Parse.com and on parse-server should allow to reproduce the behavior.

I really appreciate the time that people took to answer and understand what I said despite my broken english and some lack of information. When I say I can't spend more time on it, it's not to say "I'm fed up". It is real. We are a new startup and we have planned to launch our product into the next months. Our situation is fragile because I am the only person with an IT background and we do not have any money for now to hire more people to help us. I should pass the next few months to develop the missing features before the official launch of the product, but I already spent all my February month to read documentation, re-write some parts of the code to deal with the specificities of parse-server, do tests on AWS, etc.

This is why I have to move on the next step as quick as I can. Otherwise, with all this new stuff, I will never be able to respect my deadline, and our project will be compromised before starting.

Thanks.

[flovilmart]

@Kira2 what I would recommend then is not spend more time on parse-server for you, deploy with your own DB, and keep all the rest to Parse, until we stabilize the source code. Would that work for you?
Parse.com is not going anywhere before January 2017, you have time ahead!

[Kira2]

You're right, I should focus on the database now and see parse-server later. The majority of my integration tests already work on parse-server, so it will probably be easier with a future version.

Thanks.