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. But, we also expose a number of ways that you can use our JavaScript API to extend Skuid's capabilities, and we fully endorse and encourage this, as long as you are using our APIs and not "hacking" Skuid.
For example, you can access and interact with any of our models or components using our JavaScript API's to dynamically generate new models or components in memory.
We also let you create custom components, which you do using Javascript, and we try to get out of the way as much as possible, handing you a Document Object model (DOM) element, a component Extensible Markup Language (XML) configuration, and a component object reference, and then letting you go to town, we've seen folks make Gantt charts, Pivot Tables, Org Charts, QR code readers, all kinds of crazy stuff.
So, one of my favorite parts about Skuid is that you can always extend with Javascript where it makes sense and is appropriate, as a developer, this is what you're looking for. You need that ability.
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?
A: There are absolutely times when you need to write code. As I described in my other post, a truly good "no-code" solution should actually be a "low-code" solution, one that makes the common tasks easy and the uncommon tasks possible.
Skuid is great at letting you do just that, setting up connections to data sources, creating models, arranging and assembling user interface components in a page, deploying them to users, setting up sequences of actions to run in response to user interactions, all of this is the meat and potatoes, the "common" stuff that you can do without writing code with Skuid.
But there are many use cases for "dropping down into code,” which Skuid's JavaScript API supports and enables you to do. We expose various hooks where you can run Skuid "Snippets" to inject JavaScript logic within pages, as well as create custom components, to make possible the hard/uncommon things, for which code is the best approach.
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 un-rendered.
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.
