Low-code Application Development vs Traditional Development
Hawk Hill is one of my favorite places. When you sit there, you see the sea on one side and the bay on the other. You can clearly see the change of pattern in the water between the two sides. The bay shows the calm waters while the sea is full of waves. This view is awesome as it shows the two bodies of water at the same place (of course, the majestic view of the Golden Gate is present as well).
I was in a similar situation some time ago when our team was developing functionality for appointment scheduling for a popular retail chain.
On the one hand, we had their website written with traditional architecture and practices. And on the other, we created an application for appointment scheduling with our low-code platform. The comparison of traditional and modern RAD development never looked so enlightening before.
About the application
Appointment application included:
- Creation of the appointment functionality
- Google Calendar for appointments in the backend involving store and email notification of events
- Presentation of these appointments to the store salesperson on mobile devices (As an application in the micro-app container provided by SpotCues)
Screenshots of a few representative pages
The solution also involved changes to the existing website including:
- Adding buttons with the right styles to the website and optimizing it for different devices
- Launching the appointments functionality in a pop-up
- The dialog then needs to be sized correctly based on the device it is viewed on
- Content from the website application needs to be passed to appointments applications for locations and other details
The solution took around 6 weeks to deliver. But it clearly presented the comparison of 2 development methodologies.
Proposal and Requirements
For the proposal, we created a simple prototype of appointments functionality within a day
- Simple online database-backed storage
- Micro app for listing/filtering/searching the appointments based on the location of the store
- Email-based notification to the user and store manager
- Responsive view on all devices
All of the above was done using the ready-to-use RAD components. A real working prototype of the application presented good clarity. The proposal was quickly accepted by the customer with very few changes.
Implementation – A smooth sailing
The appointment application functionality was implemented with great-looking multi-device UI and Google Calendar-based backend and notifications. This also included authenticating with OAuth2 and using Google Service Account for calendar service. Ready to use RAD connectors were utilized to reduce the code.
The application was developed for listing/searching/filtering the appointments using reusable card layout and reusable styles. This is used by the store persons to view the schedule in a micro-app container provided by SpotCues.
This was all built using RAD and was available in three weeks. The reuse of readily available connectors, UI components, and styles generated a modern application with APIs enabled and multi-device responsive UI.
Integration and Delivery – Challenges begin
Non-availability of resources, specifically UI developers
The website changes were expected to be built by the customer’s IT team. But they were already under a lot of other work related to the website. The non-availability of the IT team specifically the UI developers to make the relevant changes is not a new challenge.
Coding is time-consuming
Our team was tasked with the changes to minimize integration efforts on the customer side. The buttons, styling, and multi-device behavior were all supposed to be handled in a jQuery script. This was all manual work. We ended up spending a substantial amount of work on that. Three weeks were spent just on the integration efforts.
APIs makes your applications future proof
A lot of information needed to be passed to the appointment application. APIs could have been very handy in this situation. The appointment application could have requested information about locations and hours of the stores to the website API if they were available. But unfortunately, the website application was but with Java Server Faces (JSF) and no APIs were available. A lot of scraping logic needed to be built which not only increased the time but also provided a solution inferior in quality and maintainability.
The codebase for multiple devices
The script handled code to generate styles for different devices. This was duplicated for different screen sizes to adjust the size of the dialog and other related things. The default application built with RAD if rendered as is would have served well for all devices by default.
Larger QA cycles for handwritten Code
Hand-coded script code took more than double the time in QA. Hand-written code comes with its own uncertainties and manual errors. Generated applications on the other hand had most of the reusable components well tested and ready to go.
Microservices based design help with faster delivery
The website was a single monolithic application. The release of the appointments functionality was completely tied to the release of the website. The release of the website itself was stuck on a lot of other issues not related to the appointment application. A Microservice-based design of the website could have helped with continuous delivery.
Working on the edge of a traditional and modern low-code rapid application clearly presented the benefits we can achieve later. Modern RAD provides great-looking multi-device UI and autogenerated backend and connectors to slash the development and QA times. Microservices and automated delivery options enable you to release much more frequently. Of course, we will also try to automate such integrations with our RAD platform in the future based on this experience.