BaaS vs MySQL

From what I’ve seen, there’s been increasing talk of using cloud services such as Google Firebase or Amazon RDS instead of a self-hosted MySQL solution.

To further this discussion, I have recently been looking in to BaaS (Backend as a Service) solutions such as Parse. It’s an open source server app that communicates with a MongoDB database. They have a dashboard app too which makes managing and creating databases/apps a breeze.

Parse can be run locally or on the cloud. It also has file storage system that can link up to platforms such as Amazon S3. It has advanced functionality too such as index management, performance tuning, backup and restore functionality and a growing library of client SDK’s.

It even has a built in REST and GraphQL API to connect applications together!

My question is, would a BaaS platform such as Parse work well with Wappler and could this replace the usual MySQL database setup?

1 Like

Yes it could, but I’d highly recommend StrapiJS instead of Parse.

2 Likes

There is also Apache Usergrid_.

But to understand the principle of BaaS, we need to know its definition:

A cloud service is any service made available to users on demand via the Internet from a cloud computing provider's servers as opposed to being provided from a company's own on-premises servers. Cloud services are designed to provide easy, scalable access to applications, resources and services, and are fully managed by a cloud services provider.

There are many instances where a cloud service can be a good investment. Personally I am all for outsourcing where it makes financial sense. This is one of the reasons why I use Wappler rather than writing my on code. And yes, BaaS is a good companion to Wappler. Think of Google maps where the product (database) is used by many a web site.

Asking the question: Will Baas ever replace the likes of MySQL? is akin to asking: Will the world end in 12 years time due to climate change? At this stage we can only assume and my assumption is that MySQL, and similar, still has a very bright future in web develpment.

image

4 Likes

Well, a BaaS can still be using mySQL, so I don’t think they’re exclusive in any way. It’s just a fancy way of abstracting the backend behind a user-friendly interface. Strapi does a great job of this and gives you a REST and GraphQL API out of the box, all with a nice admin UI to setup your models (database tables) and their relationships, all with auth and role based access baked in too. However, where most of these platforms start to fall down is when you need to do some fine-grained business logic. They don’t always have a great user-story for these scenarios. I don’t mind doing some custom node.js stuff, but you then gotta know these BaaS platforms very well to integrate with how they like to do things.
Personally, I think FireStore with Google Cloud Functions make for an awesome scalable, real-time data store, and the Cloud Functions, Cloud Storage, Machine Learning APIs etc. really open up the possibilities of what you can do. I’d be all for using Wappler to integrate with all of that cool Google tech :grin:

Thanks, my concerns with Firebase/GCP was vendor lock-in, privacy and cost. Although they offer a Free plan, it can get rather pricey when you scale up. That’s why I was looking for alternatives and came across these open source BaaS.

Understandable. Know that everything is relative.

  1. Vendor lock-in: to some extent, you will always have vendor lock-in once you begin to scale. How many SaaS apps are running on AWS and utilising all of their services? I’m pretty sure vendor lock-in isn’t a concern of those at that point as they’re very happy with the services they receive for the price they pay.
  2. Privacy: same with any provider imo.
  3. Cost: While running things on your own VPS can be initially quite cost effective, once you begin to scale, things start to add up quite a lot. How good are your devops skills?
    For example, let’s say that on sign up you send a verification email to your new user, but they’re complaining that your app becomes unresponsive as it’s signing the new user up (your app is also sending the email). One way of reducing this blocker would be to introduce a job queue, where you can push the “create verification email” job off into the background to be processed without effecting your UI.
    Are you able to implement such a solution on your own VPS? Do you want to? Time is money and the less time I can spend having to worry about scaling issues, the better.
2 Likes

Hi @niall_obrien, this is interesting. Are you using this with a Wappler project?

To be honest, I looked into this quite a bit and came to the conclusion that Wappler can already do almost everything these BaaS platforms advertise.

It can be a bit quicker to get started but I’m sure after features like the database creator are implemented we won’t ever need to discuss alternative platforms again :wink:

2 Likes

Very interesting! Thank you. Love to explore such new things! Would make simple webapp development even more rapid!

Nope, I’ve used StrapiJS with VueJS with great success though. I’ve also used it as an API server for other servers to consume (Strapi’s API wasn’t exposed to a browser client, only to other server clients). I can’t see why you couldn’t use it with Wappler though; simply ignore all of the server stuff Wappler does and focus entirely on the UI and the browser client.

I don’t necessary agree. Strapi sure makes it easy to get a secure API up and going. Sure, Wappler might help with UI and server side of things, but you’d still have to implement JWT-based auth, handle role based permissions per endpoint etc. Quite a lot of concerns go into properly designing a REST API. Strapi also support GraphQL, which is a huge advantage to a lot of developers. I believe they also just secured €4 million worth of funding.

Wappler seems more suited for building a traditional server-side rendered app with sprinkles of JS functionality (yes I know Wappler’s clientside JS framework is powerful and can do many things). If you want a true SPA communicating with an API backend, Wappler unfortunately, isn’t the way to go right now. Why you may ask? Wappler’s SPA implementation isn’t a SPA in the truest sense; it’s Pjax/Turbolinks which means that a server is still required for page rendering (and routes etc.) A true SPA can be deployed to a static web host, CDN etc. (Depending on the router used and/or the static server’s config - hash-based routing vs html5’s push-state clean URLs).
Tbh, if you’re going to go the API route, the only reason I’d recommend doing so is if you will definitely have multiple client apps and/or customers consuming said API. Otherwise, I’d probably stick with Wappler and build a traditional site/app if that’s what you’re most comfortable with.

Tbh, using Wappler is a form of lock-in. Using an iPhone or Mac is another form. I could go on. Scaling this stuff yourself is not easy and the time you spend on this stuff would be best spent on developing your app, so it might be wise to do some cost-based analysis - Google vs doing everything yourself (how much is your time worth?)
Just some food for thought.