Preface

Not so long ago a new major version of Parse Server was released. Version 3 includes some pretty rough breaking changes when it comes to the Cloud Code and the JavaScript SDK -

• Version 2 of the Parse JavaScript SDK that is used in the Cloud Code lacks some methods on the ParsePromise type, as described here. Luckily, replacing these methods should be fairly easy since the native Promises are supported in all Parse Server versions on SashiDo. In fact, these should be one of the first changes to perform before upgrading your Parse Server version.
• Cloud Code handlers have a new interface based on promises.
• response.success / response.error are removed in Cloud Code

In short this means that the following code that works on version 2.x.x will no longer work:

Parse.Cloud.define('fetch_data', (req, res) => {
    externalService.fetch()
      .then(data => res.success(data))
      .catch(err => res.error(err));
});

And will have to be replaced with the following code:

Parse.Cloud.define('fetch_data', req => externalService.fetch());

The problems

Something is bugging you with the above? Let me reiterate, so we are on the same page... Breaking change means that you will have to change your whole cloud code and redeploy it, at the same time you need to change the version of your Parse Server to match the new cloud code and all of this without interrupting your backend's ability to serve your app’s users. That's why SashiDo has something special in store for its customers, keep reading!

We, at SashiDo also recognize that the version(2.3.3) of your SashiDo applications is not quite up to date and a smooth transition will be required. Since no software is perfect and incompatibilities are always in the realm of possibilities when changing versions, we would like to reduce the risks during the transition as much as we can. That's why we are releasing a total of 3 versions alongside 2.3.3 so you can incrementally upgrade your app. The versions are:

• 2.8.4
• 3.0.0
• 3.1.3

The way ahead

So, you want to upgrade your Parse Server to the latest version? Great! Here's what we recommend you to do.

First and foremost, we highly recommend for any production apps to be tested on a development version of themselves before upgrading. To do that, we recommend effectively cloning your existing application, which consists of the following steps:

1. Create a new application from the Sashido Dashboard.
2. Export the database from your production application and import it into the database of your newly created application. Here's a useful video on how to do that: Database import & export
3. Start the new app's Cloud Code and copy it over from your production application's GitHub repo to the new one. Optionally, you can also add your new app's GitHub repo as a new remote to your local repo, for easier development. More info on the topic here Git Basics - Working with Remotes.
4. Push the changes to GitHub.

Now that you have a clone of your application, select it in the Dashboard, go to Runtime -> Parse Server Version and set your version to 2.8.4. After your application has been rebuilt, make sure that everything is running okay. Check the logs for errors, run cloud code requests, run Parse queries, whatever defines your application as operational.

At this point, you have not modified your Cloud Code. Now would be the right moment, to verify that your Parse Server is working as expected with version 2.8.4. After the extensive testing is done and you are sure that 2.8.4 looks good, you can switch your production application to it as well.

Fearless upgrades

Alright, so we established that version 3.x of the Parse Server brings some breaking changes, we also mentioned that SashiDo has put some sort of compatibility layer for you. Let me explain that real quick.

In the latest version of the Parse Server, the Cloud Function handlers don't receive a second argument when called. The second argument was holding the success and error functions which would signal that a certain function invocation has either succeeded or failed at a given point in time, maybe immediately, maybe in 5 seconds. We should now use promises and async/await to handle asynchronous functions, such as the following example, taken from the Parse Docs:

// The new way
Parse.Cloud.define("averageStars", async (request) => {
  const query = new Parse.Query("Review");
  query.equalTo("movie", request.params.movie);
  const results = await query.find();
  let sum = 0;
  for (let i = 0; i < results.length; ++i) {
    sum += results[i].get("stars");
  }
  return sum / results.length;
});

This is great, it truly is. async/await makes JavaScript code much more readable and easier to reason about. Moreover, unhandled exceptions will now be caught and returned to the caller properly, without requiring explicit error handling in 100% of the cases. However, if you have 1500 lines of Cloud Code, upgrading it all in one go is probably not something you eagerly look forward to. That's why, in SashiDo you can have Cloud Code written in both styles - the new one (example above) and the old one:

// The old way
Parse.Cloud.define("averageStars_old", (request, response) => {
  const query = new Parse.Query("Review");
  query.equalTo("movie", request.params.movie);
    query.find()
    .then(results => {
        let sum = 0;
        for (let i = 0; i < results.length; ++i) {
          sum += results[i].get("stars");
        }
        response.success(sum / results.length);    
      })
      .catch(err => response.error(err));
});

Basically, all apps in SashiDo will have a compatibility layer injected into their Cloud Code for versions after 3.x. Which will eliminate the breaking changes, allowing you to migrate your Cloud Code at a steady and comfortable pace. At the end of the day, you get all the new features and in return, it doesn't cost a full application rewrite. That's a win in my book!

Final steps

Remember the routine we went through to verify that our application worked on version 2.8.4? Yeah, me neither, refresh your memory here. When upgrading from 2.8.4 to 3.0.0 and 3.1.3 you need to follow the same steps. Only this time, after making sure that your application is operational you should start rewriting your Cloud Code functions one by one. We strongly recommend you do that since we can't guarantee the compatibility layer will allow you to take full advantage of all the Parse Server features in its next releases.

The End

That's it. You should now be fully prepared to upgrade your SashiDo applications!

Cheers and enjoy! :)

For today's mobile applications and websites is essential to deliver a significant amount of static content to the end users. This content includes images, videos, documents and any other unique digital goods that modern businesses are producing. As these static assets grow in number and size, bandwidth usage swells and page load times increase, deteriorating the browsing experience for your users and reducing your servers' available capacity.

The primary challenges digital businesses are facing today is the latency and coverage of the mobile network. 3G or 4G networks make more than 70% of the mobile app's traffic.

To dramatically reduce page load times, improve performance, and reduce your bandwidth and infrastructure costs, you can implement a CDN, or content delivery network, to cache these assets across a set of geographically distributed servers.

How SashiDo store the apps files

As you're already aware, SashiDo is a complete managed service, and for that reason, it's our job to handle all the challenges about where our customers are storing their static content and how their apps deliver it to their end users.

To provide highly scalable and stable file storage and delivery solution for the Parse Servers we are hosting we saw that AWS S3 would be an excellent foundation for that challenge.

What is µCDN for SashiDo Files

Two years since we've launched the SashiDo Platform we decided that's time to change the way applications deliver their static assets and take it to another level.

When we started working on the new SashiDo Files Service and µCDN (MicroCDN) we set a couple of goals we must achieve.

• Performance
• Better User Experience
• Happy Customers

Why SashiDo Files Service

A year ago we announced the SashiDo Push Notifications Service, and we had a clear idea of what we want to achieve:

• Send push notifications as quickly as possible
• No notification can be dropped, ever
• Perform well under high loads and don't consume too many resources
• Save as much as possible resources into the Parse Server containers.

In other words with the SashiDo Push Notifications Service, every Parse Application hosted here can send Millions Push Notifications per minute while at the same it's handling API requests without any issues.

Following the same principles, the SashiDo Files Service was born. How we did this:

• Entirely written in Go (Performance, Scalability, Efficiency)
• Amazon S3 Transfer Acceleration enabled by default
• Deep integration with the TUS Protocol

As a result, we've achieved up to 3x better performance.

Why µCDN

With the SashiDo Files Service, we are uploading the files much faster now, but we were aware that this was only 50% of our goal. That's why we changed the way how we deliver the files from AWS S3 by adding a MicroCDN layer with microZones support.

µZones (microZones)

Today our Parse Server infrastructure is running on four continents around the globe. Following the same concept, we've launched four microZones that will handle the files delivery based on where your Parse Server is hosted.

For example, if your Parse Server is hosted in our infrastructure Europe, your files will be delivered by the Europe mircoZone and etc.

These are the SashiDo's microZones:

• Europe µZone: Amsterdam, Frankfurt, London, Luxembourg, Bucharest, Paris

• Americas µZone: Seattle, Phoenix, Miami, Chicago, Denver, New York, Dallas, Ashburn, Los Angeles, Palo Alto, San Jose, Toronto, Montreal, Sao Paulo

• Asia µZone: Tokyo, Singapore, Hong Kong, Chennai, Hyderabad

• Australia µZone: Sydney

How to enable this feature and how much does it cost?

The SashiDo Files Service + µCDN is enabled by default for every application hosted on SashiDo for FREE!

Fin

We hope that this significant change in our files delivery architecture will improve your customers' experience and will drastically increase your revenue.

So, you have created your SashiDo app, set up some cloud code and are now wondering what would be the best way to test it. Of course, one of the obvious solutions would be to do a git push every time, then test it through the API Console, another REST client, or your app directly. However, you and I both know that there has to be a better way, right?

Run a local instance of Parse Server

Running a local instance of the Parse Server with your Cloud Code is the first step you should take as it will allow you to iterate on your app much faster and consequently allow us to debug it. Here's how:

1. Clone the source of your app

You can go to your GitHub profile and find the repo of your app. It will be something like pg-app-your-app-id, or you can just use the link from the SashiDo Dashboard.

After you have the repo URL just run the following command in a terminal to clone the source:

This will download your app's source to a folder named my-sahido-app, change that to match your actual app name.

2. Install the npm modules of your app

This will require you to have node.js and npm installed on your system. We recommend node.js v8.6.0 as this is the version SashiDo uses, but later versions should work too.

3. Open the directory in your favorite Editor/IDE

Preferably, it should support Node.js debugging. In this article, we will use Visual Studio Code but others, such as WebStorm work just as well.

3.1. Configure your local Parse Server

Open index.js, where you will see the Parse Server configuration. Keep in mind that this configuration will only affect your local Parse Server. It will look something like this:

var port = process.env.PORT || 1337;
var api = new ParseServer({
    databaseURI: databaseUri || 'mongodb://localhost:27017/dev',
    appId: process.env.APP_ID || 'appId',
    masterKey: process.env.MASTER_KEY || 'masterKey',
    serverURL: process.env.SERVER_URL || 'http://localhost:' + port + '/1',
    cloud: process.env.CLOUD_CODE_MAIN || 'cloud/main.js',

    liveQuery: {
        classNames: []
    }
});

Here, you can change things like your Application Id and Master Key. You will be running this Parse instance only locally, but it's still a good practice to change your Master Key. It's also recommended to run a local instance of MongoDB, here's a good tutorial from the MongoDB docs - Manage MongoDB processes. In case you want to use the same data as your SashiDo app, you can simply import it in your local MongoDB. We have a great tutorial on that - Database import & export.

3.2. Run it

After you have set it all up, it's time to run the Parse Server.:

3.3. Check it

Check that everything is working as expected by running:

By the way, this is how the code for connecting a JavaScript SDK instance to your local server looks like, in case you would want to test some queries or test your mobile app. Note that to connect to your local Parse Server, you don’t need a JavaScript key, because by default it’s not initialized with one. When connecting to SashiDo, you will need one as per the instructions in Dashboard > Your app > Getting Started.

Parse.initialize('appId');
Parse.masterKey = 'masterKey';
Parse.serverURL = 'http://localhost:1337/1/';

Debug your cloud code

Alright, so we have started our local instance of the Parse Server, but what about the debugging part?

You have two options. The first one is to utilize console.info, console.warn and console.error. This is perfectly fine for most cases, but sometimes you might need to debug a more complex scenario, where the console just doesn't cut it. In such scenarios, you can use Node.js' debugging capabilities. The debugger will allow you to inspect variables, step through code and evaluate expressions on the fly. You can watch the video Getting started with Node.js debugging in VS Code for more detailed information.

As mentioned above, we will use Visual Studio Code for this example, however, if VSCode is not your cup of tea, the process is mostly the same for other Editors/IDEs.

You should have already opened your project in your editor. Now, click the buttons as shown in the picture below:

This will open a JSON file containing the following code:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "node",
            "request": "launch",
            "name": "Launch Program",
            "program": "${workspaceFolder}/index.js"
        }
    ]
}

You don't need to change anything here, VSCode generated by default, a debugger configuration that runs index.js, which is the entry point of our application. Now, we can create a simple cloud function just to test our debugger:

Parse.Cloud.define('test', (req, res) => {
    console.log(req.params);
    res.success();
});

Run the following curl command to invoke the function from our terminal:

curl --request POST \
  --url http://localhost:1337/1/functions/test \
  --header 'content-type: application/json' \
  --header 'x-parse-application-id: myAppId' \
  --data '{
        "myparam": "myvalue"
}'

After this, all that is left to do is place a breakpoint inside the function and run the debugger as shown on the gif below.

Related resources

1. Node.js' debugging capabilities
2. Getting started with Node.js debugging in VS Code
3. Debugging in 2017 with Node.js

The end

Hopefully, after this, you will be able to debug your applications a little more easily and develop cool stuff even faster than before!

Migrating from one backend to another is not an easy process and we know it. With enough migrations behind our back, SashiDo is here to help. By the time Telerik Platform closes its doors in May 2018, you should have already migrated your data, business logic and front end, etc. to another backend. We have covered that up in Checklist for successful Telerik Platform migration. When that happens their services will no longer respond, which would render any application using them - useless. Here's what you can do:

Prepare early on

There's a saying "Luck favors the prepared", but we don't want to leave anything to luck right? Since there are a few more months left until May, there's plenty of time to prepare. First of all, you would want to make your app aware that at some point it would have to start using your new backend of choice. That would be very easy and basic for the time being - just create a cloud function in your Telerik Platform backend. Let's call it canWeStartUsingSashidoAlready and have it return false. Now, you can add a check on app startup that calls this function. If it returns false, it will continue to work normally, otherwise, if it returns true the user is prompted to go to the AppStore and get the latest version. In the best case this check will also happen every 30 or 60 seconds, so users that didn't close the app get the prompt too. Since we are now prepared, let's move on to the next chapter of our migration journey.

Everlive.CloudFunction.onRequest(function (request, response, done) {
    response.body = false;
    done();
});

Start using SashiDo and Parse

First, make sure to go through the checklist above, so that your backend is migrated to SashiDo. Next up, you would have to change your app to work with the Parse SDK. Our blog post Crash course with Parse Server for Telerik Platform developers will be very useful here. This is the part for you where most of the work will happen. There's also a slight complication you might notice on this step. "How would my users log into my app after the migration, passwords are encrypted?" - you might ask. Don't worry we have it figured out for you. See, when we migrate your data from Telerik Platform to SashiDo, we set a field called shouldChangePasswordAfterMigration on each of your users, and it's true by default. Here's how it is gonna play out when a user goes to login with your new app:

1. He would see the login page, because he doesn't have a valid session.
2. Upon entering his credentials and clicking login, your app, will check whether the field mentioned above is set to true.
3. If it is, the user is prompted to change his password. It’s recommended that a confirmation email is sent to the user, to keep security top notch.
4. After that, the field is set to false and the app continues to work as usual.

Parse.Cloud.define('shouldChangePasswordAfterMigration', function(
    request,
    response
) {
    const { userID } = request.params;
    const query = new Parse.Query(Parse.User);
    query.equalTo('objectId', userID);
    query.first().then(user => {
        if (!user) {
            return response.success(false);
        }

        return response.success(
            !!user.get('shouldChangePasswordAfterMigration')
        );
    });
});

Alright, let's move along.

Deliver your new app to the users

After we have set the check in the old version that would prompt the user to update when the canWeStartUsingSashidoAlready cloud function returns true and have a new app ready it can be released to the AppStore. After it's release, go to the Telerik Platform cloud code browser and set the cloud function to return true. Your customers will update their applications and won't even notice that you have switched to SashiDo. That is unless you add some cool functionality using our features of course, e.g. live queries.

Bonus

Since SashiDo allows you to have custom domains, you can have a subdomain like mobile-api.customdomain.com and if in the future you decide to switch Parse Server provider, you can just point the domain to your new hosting and everything will just work.

Success

You have successfully migrated your application. Maybe it's time to take that vacation? In any case, we will see you around.

Happy coding!

If you have sent push notifications with Parse Server you are probably familiar with the issues that come with having larger audience. The way the Parse Server's push notifications work is the following: your Installations are fetched in batches, these batches are then sent respectively to FCM(Android) and/or APNS(iOS).

One of the issues is that the progress of these batches is not tracked. Let’s say your application has 2 million installations, currently the Parse Server would take roughly 5 to 10 minutes to send push notifications to all of them. In this time a number of things can happen to your Parse Server, e.g. it might crash or restart due to a new deployment. This would cause the process of sending push notifications to halt in an undefined state and some users will never receive the said notifications.

Moreover, the process is not distributed. This means that you can't take advantage of horizontal scaling because only one instance of your application is processing the workload at a time. Oh yeah, and lets face it, Node.js doesn't do really well under high loads.

Alternatives

What were our options? We could

• Create a new Parse Server adapter to address the points above - That sounds like a good plug-and-play idea, but we would ultimately still be limited to Node.js and that wouldn't be ideal in the case of millions of Installations per application.
• Use an external service, such as OneSignal or Amazon SNS - That would be a good option, however each service has its own set of limitations and we would have to work around them. Also synchronizing Installations to the respective service alternative and getting detailed response for each notification would be far from ideal.
• Create our own service - Have complete control over the whole process, which would allow us to provide great experience to our customers and also give us the opportunity to iterate over the solution further over time. This way we would also completely take the load off the Parse Server.

Introducing SashiDo Push Notifications Service

We made our choice - create an external service that will be able to handle the demands of our customers. There are a few prerequisites that we had to meet:

1. Send push notifications as quickly as possible
2. No notification can be dropped, ever
3. Stick to the SashiDo no vendor lock-in policy - we must not change the way the Parse Server is working. Should you choose to host your Parse Server somewhere else, the push notifications would continue working, just without the benefits described in this article
4. Perform well under high loads and don't consume too much resources
5. Be able to scale each component of the system according to demand
6. Keep database reads and writes within a tolerable range since we are using each Parse application's database (SashiDo no vendor lock-in policy, our customers own their data!)

First of all a fitting language had to be chosen. We could choose from Rust, Go and maybe Elixir. Due to our domain knowledge with Go, that's what we picked. We all know what Go brings to the table with its great concurrency model and easy deployment, so I will not go deep into the rationale behind this choice. It suffices to say that we are very happy with the results. If you are not familiar with the language, here's a great article About Go Language  - An Overview.</p?

To be able to scale each component of the system independently of course, we went with a microservice architecture. Interestingly enough, we started with only 2 microservices. Their numbers quickly began to grow and we ended up with a total of 8 microservices. Bellow, you can see a simplified schematic of the architecture.

Let’s go through the workflow real quick. When a new push notification gets to the Parse Server it's sent to Push Notifications Service's REST API. This request, then gets to the Installations batchers, which is group of microservices that read installations from the respective application's database in batches. "Why in batches?" one would ask. There are two main reasons for that. First - we want to distribute the process across microservice instances for fault tolerance reasons and second - this allows us to control the amount of read items from the database at a time and per query. With this approach we are able to read millions of installations with no significant impact on the database. After each batch of installations is fetched, each installation is sent to a respective Sender. Currently, we have two senders - iOS and Android, which use APNS2 and FCM respectively. And when each push is delivered to either APNS2 or FCM, the response is passed to the Status workers. In a similar fashion as the Installation batchers they make sure not to stress the database too much while saving the statuses. This way we can scale the Senders as we see fit without worrying for the workload put on the database.

"This is great but, what are Redis and NATS Streaming doing there?" - Glad you asked. We are using Redis for caching of course, but not only. Each microservice uses Redis to store progress of its operations. This is to ensure that if an instance is to die unexpectedly or another failure occurs, the next one that handles the operation will continue from the same place.

Let me tell you the story behind why we chose to include NATS Streaming in our stack. For those of you who don't know NATS Streaming is a data streaming system/message queue built on top of NATS Server. But why did we choose it? Well, it turns out when you want to have a message queue capable of processing 200 000 messages per second your options are kind of limited. For example, we tried with RabbitMQ at first, but quickly proved one of our expectations that reaching these numbers and having high availability would require some pretty solid hardware. For example, you can read a great article on how to reach 1 million messages per second with RabbitMQ by using 32 machines, 30 of which with 8 vCPUs and 30 GB of RAM - RabbitMQ Hits One Million Messages Per Second on Google Compute Engine. NATS Streaming on the other hand is simple, built with Go and crazy fast. One drawback is that it still doesn't support clustering, however our DevOps guys were able to cast some black magic to make it work with the fault tolerance capabilities it currently provides. The results? We were able to get out 100 000 incoming and 100 000 outgoing messages per second out of just 3 VMs. We also saw NATS was very stable with high loads. Bellow you can see some stats from our tests.

Results

After switching to the Push Notifications service, which is enabled by default with Parse Server 2.3.3 on SashiDo, you will be able to send push notifications to your clients about 20 times faster than before, without pushing the limits of your Parse Server and slowing down other requests. You will also no longer need to worry about restarts, crashes or deployments.

Read more about the new Parse Server version on SashiDo here: Our new Parse Server Version comes with new service for Push Notifications

Happy pushing!