Splitting your Wappler App into a separate font and back end?

Hey All,

As I was going for a run this morning, and as I’m always thinking about my project, Wappler and future-proofing my platform architecture and deployment plans, I started thinking about separating my front-end and back-end (but both still being in Wappler)

The main use-case was about having a the database existing on a different server/instance than the front-end web data and still being able to deploy and update both in Wappler.

Currently my project is set up as a NodeJS / Docker project, with everything in the docker image

I figured there were two ways to go about this:

  • Set up a new database, with its own IP and credentials etc
  • Create a new DB connection in DB manager
  • Go into all the server connect files/steps and simply change the DB connection in each step/file
  • The front-end will now work the same, the server connect calls will simply connect to a different DB connection.

Ok, so this isn’t really separating the font and back end, its relaly like a normal project, but being that i’m currently on a Docker project it is using a DB outside of the docker image.

The problem is its still really all deployed as one App, font and back end together.

  1. (this is the real way I think)
  • Create new Wappler project

  • Clone all the my existing Server Connect action file/steps etc

  • Set up a new DB connection for a regular DB sitting on a server

  • Save project, no need to build any front end or web interface.

  • Go back to existing project

  • Change all current server connect elements in the front-end to an API data source and point to the endpoints just created in back-end Wappler project
    *Update all forms etc to be API forms instead of SC forms, same as above

Hey Presto! Separate front-end and back-end projects. They can be managed and deployed separately through Wappler.

So… How is my logic? Is this roughly how it would be done?

What’s some of your thoughts on this approach?


Organizing your app infrastructure with separation of concerns is always a good thing and the power of Docker to make this easy for you.

However if your database is your most central key element, you might want to consider using a managed database service for your database alone. So it is all well managed, software kept up to date and backup-ed. Hosting providers as Digital Ocean and AWS already provide Managed Database solutions out of the box.

The advantage of having your database separate is that then you can have multiple sites/apps - that can even span multiple servers, or working in a clusters of servers - all using the same database.

And you don’t have to make separate projects for this in Wappler - the Database Manager can connect your straight to your Managed Database and you don’t have to use databases with docker.



I’ve not used Docker… @George, could you explain some more about Docker to illustrate this?

Yes, this is one of the key reasons I use AWS, to have all their database management tools.

Here you have some resources to introduce people to Docker:


Hey Philip,

With our main project we are trying to move to Wappler this is our setup:

1st Wappler Project (the app)

  • local environment in Docker with Docker MySql8
  • staging environment hosted on AWS EC2 - with Docker and Dockers MySql 8
  • production environment hosted on AWS EC2 with Docker but DB is a managed AWS RDS MySql8

2nd Wappler Project (marketing site + directory)

  • local environment is Docker
  • staging environment is Docker, hosted on AWS EC2 but the DB connection is to Project 1’s Staging MySql within Docker.
  • Production environment is Docker, Hosted on AWS EC2 - but connected to the AWS RDS MySql 8 managed database.

both of these come together to for the www.project and the app.project of the same domain.

Wappler makes this easy to do - I do however find connecting to DB’s outside of Docker can be a little sensitive and doesn’t always work for whatever reason, often the credentials just simply don’t save in Wappler - but perseverance it gets there eventually. Using a manged DB outside of docker is significantly faster, especially if the DB is central to your project then it’s going to be important. If you are using PostGre you’ll have to figure out pooling, too.

One note on AWS - it does sometimes seem expensive, but they offer so many ‘free’ tiers for add on services like the emailing system (SES) - and they also have free tiers on managed DB’s to offset your costs.

This may not be exactly what you are considering - but happy to answer any questions if you have any.