I’ve been terribly lax on my blog posts, but being busy is usually a good thing, so I’ll take it. Over the last few months I’ve been getting up to speed on a new application editor, and was asked to write-up my thoughts having moved from the Bubble™ platform over to Wappler.io
If you read nothing else — keep in mind this is just one persons experience and when starting I was a complete novice with Wappler, so it is entirely plausible there are better ways to build things, but that’s what experience gives you!
Some background
I’ve been involved with web applications dating back to the mid-90’s. Back then I founded a new company with the mission of allowing small companies to disseminate their information via several channels. In the nineties that included web sites, email and faxing. Because I was never trained as a coder and could not afford to hire one, I went looking for a tool. I ended up with Tango, which WAS a drag/drop product allowing one to build web apps that used databases, etc. It was similar to Cold Fusion, and I was able to pick it up faster than CF, so it stuck. I built a business on Tango, and once I had significant revenue, I hired a friend to build it in JAVA as Tango just wasn’t going to scale well. It turned out to be a great strategy for a startup — build it fast, build it for cheap, and then built it better once the business is proven. No sense going big on the tech stack before knowing if anybody cares about the product!
I built that business, along with a great team, and eventually sold it to the biggest player in the market on the fax side — ultimately we had followed the money which was in all sorts of faxing/internet related services. Fun fact, internet faxing TODAY is still a global business generating several hundred million dollars each year. I joined their management team and spent 8 years learning about the big side of business before leaving and returning to smaller operations.
Fast forward to a couple years ago, and I found myself looking again for a product to use in building web apps. Obviously the technology has changed a lot since the 90’s, but I wanted to follow the same strategy of build fast, build cheap. I found Bubble. It was a great product that allowed me to build an app for small non-profits along with my partner in crime.
The mission of Tiny Opera House is to help the smallest of the small nonprofits. These are “kitchen table” types with annual funding of ~$100k or less, which means their needs are very different from what is available today. We believe this market is not well served today, and have started to support with financial tools, but plan to do much more.
Fast forward again to a few months ago. It was time for Tiny Opera House to build a new version of our product, and because of some limitations and frustrations I have with Bubble, I went searching again. This time I found Wappler. Three months later, we had a product launched, and this is how I got there…
Experiments
I found Wappler in June of 2019. Having come from Bubble, I didn’t at first understand they were really different products. Bubble is a complete platform, while Wappler is only the editor portion of a workflow. Luckily I know how to quickly stand up a LAMP stack, so that wasn’t a problem for me trying it out. Coincidentally as I write this, Wappler (on one of their consistent Thursday updates) has release the first step for them into the world of Docker, which will makes things even easier to try before you buy.
As I recall, my first step was to pick apart and try to recreate items from the demo apps. This helped me orient into the Wappler way of doing things. You realize quickly that there is a clear separation of the front end from the back.
I already knew what I had to build, so after going through the provided demo apps, I started prototyping some of the more complex features of Tiny Opera House, like connecting to Plaid for banking transactions. I was hoping if Wappler could handle that, the rest would fall into place…fingers crossed.
Somewhere in here a realized that while Wappler development is very GUI in nature, it still produces standard HTML, CSS, JS, PHP files for deployment, anywhere. So when one gets stuck on the GUI side, direct code editing is always available, and for me has often become faster when building out certain types of logic where copy/paste speeds things along.
Time to Build
After a few weeks, it was time to start building. We had a firm grasp of what we wanted, based on lessons from the Bubble app, and from discussions with existing users. We didn’t go with any wireframes, or documentation, just some solid conversations to choose the approach and features.
I should probably note here the infrastructure. I use a Google Compute instance running Centos 7 with a basic LAMP stack, that I configure mostly using Virtualmin since I’m no Linux expert. The database is Mariadb 10.3, PHP is 7.2 and Apache 2.4. The compute instance is currently a single core w/4gigs of ram and runs three virtual servers for our Dev, Staging, and Production runs.
Server side
I quickly figured out that Wappler has clear separation of server vs front end. The benefits are numerous. First, you can have different front end apps, using the same back end server functions. Think of having a web app version, a mobile app version, and a desktop version, each presenting data using controls that are natural for their respective environment, but all make calls back to the exact same server logic. For now, I’ve only prototyped pushing an app to the IOS app store, to know it works, but I’m looking forward to building out a true mobile experience to go along with our web app.
The structure of the “Server Actions” as they are called, is a simple folder tree of php files. The default method of creating and editing is using the GUI, but you also have the option of opening these files in the built-in editor. Actions are then broken down to a few settings, the “Globals” section for variables, and the “Execute” section which holds all the steps to be sequentially run upon each call.
Variables are simply defined, and you have access to custom variables, along with query parameters, post params, session variables and standard server variables. You just name, pick the type, and they are ready to go. It took me a bit to understand that whether you are setting up a variable, or using an existing one, you need to create the variable for each server action.
The list of actions to be used in the steps includes things like file management, api calls, setting values to variables, repeat loops, OAuth, mailers, and of course database actions.
A look at the query builder…there is also a custom builder for your own SQL statements including stored procedures, etc.
Setting up permissions using a database of roles.
Often, the purpose of the server action is to return data back to the front end. Wappler allows for each step along the way to be added to a JSON result-set that becomes available to the front end app. You have the option to return the data, or simply utilize it during the server processing, giving you direct control of what is exposed to the client.
You can also see in the screenshot that there are Catch points allowing you to perform actions on errors. You’ll also see debug options on certain actions, like a database query, so you can troubleshoot anything that might not be returned as you had expected.
There are dozens of operations that can be performed on data along the way including filtering collections, formatting dates and numbers, providing default values, etc.
And the php files have a built-in security mechanism allow the developer to control who can execute these commands.
Front End
For this post, I’ll be focusing on a web app front end, but as mentioned before, you have other options.
One of the first steps in building a page from scratch is to add the frameworks for this page (or of course, setup Wappler to auto-add these for you.)
The main front end layout gives you a design view, a code view, and as shown below, a split view. You’ll also notice a series of elements that are representations of the dom, and App Connect actions such as connecting to server actions, setting variables, getting browser settings, etc.
I tend to deal in apps with data, so Server Connect actions are common for me. Initially, I was building in a kind of 1-1 model, while I learned. Eventually I switched over to more of a bulk load scenario. For example, I’ve found that having a server action the executes on page load is very efficient — you perform all sorts of queries on the server, setup session vars, etc. all in one call, so things are not queued up at the client. The heavy work is done at the server and returns JSON results for use elsewhere on the page.
Below is a server connect call expanded so you can see some properties. For example on this call, if it is successfully executed, I’m setting a variable value. Dozens of attributes and events exist with each element having their own respective set. These allow you to dynamically (or statically) perform actions and set attributes based on data or other values.
The front end allows for server side includes so you can reuse pieces of code on different pages. SPA’s are also available, but not covered in this app.
By using a Bootstrap framework, I was able to start with a purchased theme, which can present some problems initially, but once I ironed it all out, I haven’t had to look back. Since I have no design chops, this was really the best way for me to go. All the bootstrap elements are available to you, and you just click away building up your page. I would highly encourage new Wappler users to take a course on Bootstrap 4 on Udemy or similar.
You select all elements in a similar way to the server side. The GUI presents you with the elements that are valid for the element you are inserting into.
In the middle of my build, Wappler (as they often do on Thursdays) released a great new feature integrating GIT. Now we have branching, and all the other wonderfulness that GIT brings.
This post is getting waaaaay too long, so enough on features. But suffice to say, there is a lot more that I could cover.
Performance
Coming from the shared Bubble environment, I was digging the speed with which all of this can be done. I’ve pushed as much as I can into the database calls, and can easily retrieve, add, manipulate data counted in hundreds of milliseconds, instead of tens of seconds or even minutes. It’s probably not fair to compare, but the difference is striking.
Wrap up
I just could not be happier with Wappler. When there are bugs, there is good communication from the team, and fixes are fast–sometimes with patches sent over within minutes. The Thursday releases are not simply little enhancements, they often contain significant features that speed or expand development capabilities. The forum community is solid, but as I’ve said elsewhere, because the product is standards based, you have the whole of the internet for answers. The product still has some quirks within the GUI — but with community reporting, I’m confident those will diminish over time. I myself have to balance just going around it, or taking the time to properly report it. I have to do better there!
The Wappler team is huge — there are 3 whole humans that develop and support this product. 😉 It once agains shows the small teams can do amazing things, IF they have a clear vision, open communication with the community, and a willingness to get things done. Kudos to the team, and the community that supports new users like me.
Now, back to building!!!
