It’s been a while since Parse closed down completely in Jan 2017. We take pride in the number of Parse.com users who have subsequently decided to put their trust in Back4App’s Parse Server Platform. We want to share with the community some of the lessons we’ve learned since this journey begun.
With Parse.com is due to close in a couple of days (28th January 2017) we’re very excited to announce an important new feature: Fast Migration.
Thanks to the forthcoming shutdown of the Parse server in January 2017 many developers wonder how they will keep their applications online from now on. This article focuses on the solution provided by Parse: the Parse-Server project. This is an open-source version of the Parse code, but with a few key differences.
To protect their data It’s extremely important for developers to migrate their apps to others solutions, such as Back4App .
This article will provide a comprehensive report explaining what is Parse Server, the history behind it, the most important contributors for the Parse Server community and the best alternatives for the Parse shut down. Reading this article, you will know:
If you still haven’t settled on an alternative to Parse, the premier cross-platform BaaS that will be shutting down as of January 28, 2017, you’re not alone. Fortunately, Parse has open sourced the code as Parse Server. Written in Node.js, Parse Server can serve the Parse API from any Node-enabled infrastructure.
“Focus on your apps and we’ll take care of the rest.” This is the phrase that came to mind when I and many others thought about Parse.com. However, our world was rocked when we heard the news that the site was going dark on January 28th, 2007.
API developers are in a lively dispute over the respective advantages and limitations of the Firebase and Parse Backend as a Service (BaaS) platforms. Now Facebook’s decision to make Parse code open source adds more fuel to these fires of developer debate. Does this status change disarm the arguments of Parse proponents and push the balance in favor of Firebase, or perhaps it works in the opposite direction?
O presente artigo irá detalhar as vantagens e desvantagens de se utilizar um backend as a service no desenvolvimento de aplicações web ou mobile.
Um BaaS pode ser visto como uma ponte conectando o backend e o frontend de uma aplicação. Os BaaS auxiliam os desenvolvedores a acelerar a criação de aplicações web e mobile e simplificam a criação de APIs. Em vez de codificar o backend inteiro, o desenvolvedor usa o BaaS para criar as APIs e conectá-las às aplicações.
The Backend as a Service (BaaS) market has mushroomed over the past five years. App developers find that using BaaS services frees them to focus on the more inspiring aspects of their profession. They have therefore rushed to entrust BaaS service providers with those less glamorous but nevertheless all so vital development tasks. For example, BaaS offers a highly effective way of handling server coding, database hosting, backup and other tasks that create and maintain the supporting environment app development requires. “Backend” is a most appropriate choice of word since these activities provide the framework within which the more exciting app development tasks are implemented. When these activities are managed by a third party the developer has much more time to devote to the innovations that make new apps so appealing.
In this article, we are comparing expenses required to host the complete Parse solution (Parse Server + Database) in two different configurations. The first configuration covers small apps and the second covers scaling / large apps.
Small Apps – Will detail the structure required for starting apps with less than ten requests/second and minimum server-side processing.
Large and Scaling Apps – Will detail the structure required for scaling and large apps with more than 10 API requests per second.
