Skuid co-creator and principal software engineer Zach McElrath hosts Reddit Expert AMA
Yesterday, Skuid’s principal software engineer and co-creator of the product, Zach McElrath, hosted a Reddit Expert AMA (Ask Me Anything). For anyone who isn’t familiar with the channel, the AMA is one of Reddit’s mainstream features where experts put themselves on the line to be questioned in their area of expertise by Reddit users everywhere.
Zach and colleague Ben Hubbard are the brains behind Skuid. Tired of and frustrated with writing repetitive, boilerplate user interface code, they created Skuid so that customers could customize their apps on their own. Zach’s background is in software engineering, programming, and user experience.
Here are some highlights from the conversation, as seen on Reddit.
Explain low-code versus no-code.
Q: What’s the difference between “no-code” and “low-code”? As a programmer, does “no code” make you nervous?
A: This is a fantastic question, and one that is very important to me in helping folks to understand the value proposition of Skuid. To me, a “no code” application is one where all changes that you make with the app are “declarative,” which means that every setting you set has a meaning and function which the application is responsible for supporting and leveraging with each new iteration of the app. All “declarative” settings that you customize within the app are the application vendor’s responsibility to translate into runtime “code,” and with each new version of the app, the vendor is responsible for making sure that the original intention of the user when that property was configured continues to have a corresponding meaning and manifestation in the next version of the app. Put another way, each “declarative” setting is the vendor’s responsibility to maintain. What the setting does may look a little different between versions of the application, but the vendor should not break the functionality. A declarative setting is an application programming interface (API), and the vendor is making a promise not to break the API contract.
A “low-code” platform allows you to build most things without writing code, but gives you appropriate areas to drop down into code where it makes sense, in a supported fashion.
As a programmer, I would be worried about making an investment in a framework that is 100% no-code, because there are always, always things that would be best done with code, and there will always be areas that your application does not support out of the box, that you could do with code, at least until your application supports it.
In that sense, Skuid is both a “no-code” and “low-code” platform, and I think that is a huge reason for developers/programmers to use Skuid, as well as business users/non-technical folks.
We built Skuid to let you do the work that should be declarative using our drag-and-drop composer, which lets you connect to data sources and create “windows” and “views” on your data using our “models,” and then assemble pages using our “components,” which connect to models. All of this can be done without using any code—completely declaratively.
Q: What apps are a good fit for a “no-code” solution like Skuid? Surely not everything is a candidate. Or, put another way, aren’t there times when you actually have to write code?
The bread-and-butter use case for Skuid is for data-rich business applications, whether it’s internal apps or customer-facing community/portal apps, Skuid is the perfect fit for this market. I’d say Skuid is the SquareSpace/Wix of business apps.
Talk about the Skuid Platform.
Q: Aside from allowing Skuid users to filter the data they need when they build a model, how do you handle system and app performance within the Skuid architecture? It seems to me that there are a lot of moving parts inside the Skuid setup, and now that you’re managing your own platform on Amazon Web Services (AWS), there’s even more things to cache and optimize. How do you keep it all humming and fast?
A: First thing to say is that we have a “Page Performance Guide” which covers a lot of the ways that we recommend that Skuid users optimize the pages that they’re building, available here.
I’ll speak to three main aspects of performance here, and try to say a few things in each area: component rendering, model operations and server communication, and internal server-side code execution within Skuid Platform.
component rendering performance is a concern common to both Skuid running on Salesforce Platform and on Skuid’s Platform. We run an extensive unit test suite against our client-side code, and this allows us to monitor the performance of component rendering over time as we can see whether our tests are taking more or less time than usual. We also keep track of memory leaks, particularly within our models, components, and Pub/Sub Event frameworks, to ensure that we’re probably cleaning up memory when various objects are rendered and unrendered. Within data-rich components such as Table, Queue, Deck, and Calendar, we try to ensure that we only re-render UI components when absolutely necessary in response to model events. For example, when you create a new row in a Table, we don’t re-render the entire table, only select portions that we actually need to display the relevant change.
We also minimize the interaction with the DOM to avoid unnecessary re-paint events, which are time consuming and expensive for the browser. We do most of our DOM manipulation in memory and then do batch DOM adjustments. To this end, we are working to roll-out a new Skuid Design System, and as part of this we will be rewriting most of our components from the ground up, as well as rolling out some killer new components. One of the key libraries we’re using as part of this initiative uses “virtual DOM” concepts to further minimize our interaction with the actual DOM, to maximize performance.
Regarding model operations and server communication, we try hard to minimize the number of network requests that Skuid makes to target data sources, and make these requests as efficient as possible. For example, we ensure that concurrent outbound requests to identical URLs using GET are consolidated, so that we don’t make multiple duplicate requests. We try to send requests in batch whenever possible, e.g. leveraging OData’s BATCH request mode when it’s available in an OData implementation, or sending multiple concurrent insert/update/delete requests to Salesforce in a streamlined request format that allows the operations to be performed in bulk and consume as few Salesforce API calls as possible (or none, usually).
In Skuid Platform, our new offering hosted in AWS, there’s so many things to think about regarding performance that it’s hard to know where to start. We are constantly thinking about how to improve database query times by optimizing which fields we’re querying for and on, caching expensive query results in-memory to avoid database calls altogether, performing efficient loops over long arrays, minimizing the serialization and deserialization of data structures… lots and lots to think about! If there’s any specific area you’re most interested in, would be happy to answer a follow-up question about that particular area.
Q: Skuid Platform, what database architecture (MySQL, PostgreSQL, MongoDB, etc..) did you decide to go with, and why?
A: PostgreSQL. It’s the open-source gold standard for an Atomicity, Consistency, Isolation, Durability (ACID)-compliant, industrial-strength relational database. The data types we needed to store were a pretty straightforward blueprint for a relational database use case, and PostgreSQL was the natural choice for this. We also leverage Redis as a write-through cache of the most commonly used data, to minimize traffic to the database and maximize performance.