I am considering the pros and cons of moving an app from Sashido to something self-hosted at i.e. Heroku or some other hosting platform. Would love to hear what the community see as pros and cons with moving vs staying with Sashido.
Thanks!
Claes
1 Like
For me biggest pro is everything is under my control. But this also leads a con which is i have to manage everything. Self hosting is also cheaper in long run. Also sashido doesn’t support latest parse servers. İ guess latest version they support is 3.6.0 which is older. You can’t take advantage of latest parse server features like file triggers which introduced in version 4.2.0
Self Hosted
Pros:
- Everything is under your control.
- Cheaper in long run especially if your app will serve many people.
Cons: - You have to manage everything.
Yes you have to manage everything but when I do stress test against my servers, parse server doesn’t crash except if there isn’t enough ram. When available ram is zero, parse will crash. But this also depends on your usage. Parse generally uses little ram. Ram only got full if you are fetching over 100.000 parse object. And even for 100k objects 1.5gb ram will be more than enough. For few hundred objects ram will not be an issue.
2 Likes
Thanks a lot for your input! Much appreciated 
That is a great question and it means embarking on an exciting journey full of new discoveries.
This autodidact crash course will teach you to look at your app from many new angles. You will take new considerations into account that will help you build a more efficient, secure and resilient app. You will learn a lot about topics you may have never heard of or which you only knew by name.
Generally, you will likely encounter challenges of the following categories when moving from a hosted provider to self-hosting (provider agnostic):
Concept
- Some of your current approaches may become unfeasible or inefficient. You may need additional services that come included with a hosted provider. For example, you may need to look for a CDN provider to cost-effectively serve content to clients, something your hosted provider may have done for you in the background.
Migration
- If you want to migrate a live app, you will benefit from a migration plan that allows you to plan transitioning the database data, any storage content, APIs, DNS entries, client connection URL, etc. It is usually beneficial to test this out with a sample environment and plan safe points you can return to if you need to abort the migration.
Costs
- The maybe most often encountered surprise: Make sure you fully understand the new cost structure when self-hosting. You may suddenly be billed separately for things like log storage, DNS queries, and load balancer traffic. It is nothing that you didn’t already pay before in an all-inclusive pricing model, but suddenly a minor configuration change can mean a significant change in cost. To manage that, you are provided with a detailed billing dashboard that allows you to break down costs on a per-component basis.
- Support packages may suddenly become a separate cost point. While hosted providers often include basic support as part of your flat-rate, this is usually not the case with cloud service providers.
Scaling
- While a hosted solution gives you just a handful of scaling sliders, you suddenly have to consider scaling separately for every component in your entire architecture. That means you will develop a more differentiated understanding of scaling as you go along. This will allow you to optimize and provision your components exactly as you need them and give you additional cost saving opportunities.
Security
- You will have to secure the architecture components yourself. Especially if you consider migrating an existing live app, that is something to pay attention to from the start, otherwise you may create vulnerabilities that you may not notice until it’s too late.
- Security means not just protecting against data theft or service interruption, but also protecting your environment from unexpected costs. For example, a DDoS attack will suddenly not just mean that your service is impacted, but your bill can go up into the thousands. This risk is usually carried by the hosted provider, but cloud service provider usually explicitly shift the risk to you. You are billed for your resources, regardless of who or what is using them. Some cloud service providers even offer some sort of insurance package against these risks, but you could also look for external insurance cover.
Time
- You will need to invest time to learn as you go. You will go from mainly worrying about your business logic to worrying about many new aspects and topics that you may not have encountered previously.
If this sounds like a lot, it should not discourage you. Quite the contrary, the time and effort you invest will be worthwhile through the knowledge and competence you acquire. You will never look at an app the same way as before.
2 Likes
Hi, I am evaluating a self-hosted option over the back4app due to 2 reasons:
- I want to integrate ElasticSearch
- Back4app does not give the control over the versions of MongoDB and Parse Server
Do you think we could use my very limited knowledge as an advantage and write a detailed guide on how to deploy a simple, but easily scalable self-hosted solution? I could imagine that I would go through that painful learning process under your advices and supervision and I would write down a guide with that would track all my steps? I believe that it could help someone in future as it has to also explain it in detail (because I have never worked with any backend and can do programming only in swift).
I understand that every app has different needs and also depending on how the scale of the app changes and maybe I simplify it too much, but I think there must be a starting point that suits the most applications that can grow like:
- Put this and that into Kubernetes on such and such machine…
- These are the steps to set Kubernetes for one microservice of MongoDB that might be scaled later…
- These are the steps to set other microsercices like Parse Server, ElasticSearch…
- Set these and these parameters to make it a bit secure…
… not really trying to over-optimise everything, just keep thing flexible and then I could also document the costs of each feature/part…
I am sure this would be a lot of work and I would also need a lot of assistance, but it might be worth of doing for me to understand and learn and also could be great help for some independent developers that are trying to bring app a new idea and don’t want to build up technology debt due to limited knowledge.
What do you thing?
I’m not sure you’ll find a free 1-on-1 tutor for your project here, but you could just document your learning process and post any issues you encounter in the respective forums (Parse Community Forum, StackOverflow, ServerFault, etc) as you go along and then share the document with the Parse Community.
There are a lot of Parse Server deployment and performance optimization guides out there, so you may want to start with a search, for example: https://community.parseplatform.org/t/share-your-performance-tips
@claesjacobsson So I recently prototyped an app using Sashido. Overall I was very happy with the experience … EXCEPT - and this is a BIG but … I can’t bring myself to launch my production app on the platform because the age of the libraries they are using is unacceptable from a security perspective. This a reply from Sashido’s (very responsive) customer service team and it was the deal breaker for me, sadly, as I really wanted to use them as the performance of my queries and cloud functions was just great. … not firebase-fast but fast nonetheless.
Currently, the Parse Server versions supported from SashiDo are v2.3.3, v2.8.4, v.3.0.0, v3.1.3, v3.5.9 and v3.6.0 and the MongoDB version for all applications is 3.4.X. You can check the Parse Server version of your application from the app’s Dashboard → Runtime → Parse Server version. The MongoDB version can be seen, once you connect to the database.
Parse Server has stopped support for MongoDB versions 3.2 and 3.4 since Parse Server 4.0.2, as you may see from the Changelog. Therefore, it won’t be possible to interact with your SashiDo database and local Parse Server version 4.5.0.
Regarding the MongoDB version, according to the manual, for versions < 4.2 there is a limit of 1024 bytes for an index entry. For MongoDB versions greater than 4.2, there is no limit. This may be giving you troubles, especially in the case you have at least one larger entry.
To save you time looking all this up, they are using a version of Parse Server that was released Feb 28 2020 - 18 months old - and the latest version of Mongo they support was released 4.5 years ago.
It’s worth noting that serveral great innovations in later versions of Parse server (such as passing context variables to cloud functions) isn’t thus available. So you have to be aware of these limitations as you develop, if you must use Sashido.
For me, this was all a deal breaker and I’m forced to either self-host … or use back4app, who for me during testing had much slower response times and is waaaay more expensive than Sashido, based on my anticipated use calculations.
2 Likes
I think our current (more or less undefined) release model makes it somewhat difficult for hosted providers of Parse Server to stay up to date, as it does for developers who host themselves or with a cloud service provider.
That will change from Parse Server 5 (late 2021) going forward with fixed release cycles (incl. phased deprecation, etc.) to make releases more predictable and make it easier for developers to keep their deployments up-to-date.
Hi @kulanu, I’m charles from Back4app. Regarding your points, please, see my comments below
-
Price: Our team is very accessible, and you can reach out to us to check the best plan based on your usage, and even though offer you a tailor-made plan, if you didn’t do that yet, you can contact us through our Support Page, or book a time with a member of the billing team here.
-
Response Time: For the issues that you’re facing, please, contact us and I’m sure we will be able to figure out the issue and looking for a solution.