Why We Love Enterprise Codeless

Last week Google released a new product called Tables, which takes square aim at (i.e., looks exactly like) “codeless” development and workflow-management tools like Airtable, Notion, Monday, and others. These are tools that let you set up workflows and work on big data sets. People use them to do all kinds of things, from running their interview process to building mutual aid societies.

I wrote about low-code in Wired last month:

There are a host of tools like this now, “low-code” or “no-code” software with names like Zapier or Coda or Appy Pie. At first glance, these tools look like flowcharts married to spreadsheets, but they’re powerful ways to build little data-management apps. Airtable in particular keeps showing up everywhere for managing office supplies or scheduling appointments or tracking who at Wired has their fingers on this column. The more features you use, the more they charge for it, and it can add up quickly. I know because I see the invoices at my company; we use it to track projects. (Though Airtable has made its Airtable Pro plan free for certain Covid-related efforts like the mutual aid society.)

No one is sure what to make of Tables yet. It’s not fully integrated with Google’s regular office suite, and it has an enterprise pricing model, more complex than “free” or “comes with your paid Gmail.” It looks a lot like a spreadsheet, and then there are mini-programs (called “bots”) that run as you enter the data.

But it’s no surprise they launched it — consumer codeless is a big, growing space. Amazon has a new product called Honeycode that lets you write business logic right there in the cloud. Airtable is valued at $2.5 billion. The core idea is that anyone can sit down and take what’s in their brain and turn it into a software experience that other people can use, without writing a bunch of SQL statements.

Postlight is a product development services company. People pay us to design and code things. Codeless products are designed to pick our pockets. And you might think we’d be worried about codeless products. But we utterly love them. They solve a huge range of problems people have. We also think that a lot of the most interesting “codeless” work happening isn’t in the consumer products space, but on the backend.

Consumer codeless vs. enterprise codeless

“Codeless” is a good marketing term. More accurate might be:

• Spreadsheets with rules
• Databases with comment fields
• Smarter pivot table builders

You get the idea.

But the key to codeless products is that they cut out whole layers that used to be necessary. You used to need a database and a programming language that talked to that database in order to build a web app. What tools like these do is just bring everything together into one unified whole: You have all the “state” that’s in your database connected to all the “interfaces” used to access that state. So you can see a view that looks like a spreadsheet, a view that looks like a Kanban board, a view that puts everything on a map, and so forth. You give up a lot of customization, and everything tends to look the same, but you get a lot of power in return, and a lot of simplicity.

The same pattern is starting to emerge in the server/API world, too. The way it works is pretty simple: You run a program on the server and that connects to a database and provides a REST or GraphQL API to the data in that database. Let’s call this “Enterprise Codeless.”

For example, whereas before your LAMP stack — Linux, Apache, MySQL, and PHP — might look like this:

Now your stack looks like this:

Which seems almost ridiculously reductive, but is also…true. Let’s add some details about this new anti-stack stack:

• Your database is the source of all truth and everything is stored there.
• You run an application on the server that inspects the database and automatically produces a web API.
• You add more functionality to the API by writing functions inside the database, mostly in SQL, and when changes happen, these are also written in SQL.
• User management is done inside the database with tokens for security.
• You write the front-end using a component framework like React.
• Extra work (say, producing image thumbnails) is done by serverless cloud functions like AWS Lambdas.
• You put static assets into bucket-based hosting systems like AWS S3.
• You write a set of scripts to deploy and manage things.

So maybe a slightly more accurate layercake diagram would look like this:

But the key thing is that a huge layer of complexity, code where users are managed, accounts are created, data is massaged, API requests are transformed, etc., etc., etc., is just sort of…stripped away.

Here are some examples:

• Datasette, which gives you a REST API (GraphQL is under development) on top of any SQLite database. This is one of the fastest, lightest ways to create simple web services and explore ideas, and it has a nice built-in interface too.
• Hasura, which gives you GraphQL on top of the Postgres database, and is written in Haskell. VC-funded, and starting to support MySQL too.
• Postgraphile, which is like Hasura but all in JavaScript. Postlight sponsors Postgraphile, and we’re big fans.

And many others — there’s a growing list of products like these.

I’m a huge fan of the first one because it’s a great tool for hacking and exploring data sets. And we’ve used the last two in production and found them utterly manageable and effective applications for organizations like the New York City Metropolitan Transit Authority (MTA).

Challenges of enterprise codeless

It’s a great way to work but it does represent a different approach. This approach requires engineers and designers to think differently about how they’re building things. There’s more time spent thinking and much less spent building. You have to unlearn a lot. You have to think about your database as a true platform. (But it works beautifully — more on that later.)

And in general, since this approach to building things is both really old-fashioned (using the database and database-native functions to define an entire application server feels very main-frame-ey), and ridiculously modern (goodbye forever, LAMP), the tooling isn’t quite there yet. 

Postlight engineers faced challenges, in particular, with managing the large set of in-database functions they were writing. Because the functions exist “inside” the database and are not organized into libraries, or structured readily into folders, all the niceties of a modern IDE don’t apply. At some level, doing this much work in the database means working with a single many-thousand-line file filled with table definitions, functions, and index declarations, and there’s no clear set of best practices for managing those. Plus, when code changes, that might mean the entire database is changing. Modern ORMs and migration tools, combined with modern tooling for code management, provide a lot of niceties. 

Ultimately, Postlight folks noted, SQL is a language for data analysts. So there’s friction between how SQL sees the world and how modern API-driven web services work, and you need to learn about that and think it through.

Advantages of enterprise codeless

So, okay, there’s still plenty of complexity!

But here’s the advantage: When you have a rough sense of business requirements, and you understand this stack, you can sit down and write an SQL schema, and have a fully functioning modern GraphQL API in an afternoon. Then you can glue some React components to that on the frontend — using something like React Admin means that you’re just building with predefined widgets and writing very little code. That’s it. That’s the whole thing. You built an app. Now you can start to focus on design, experience, scalability, and enhancing the feature set of the API.

Here’s the other huge advantage: This ridiculously modern way of writing code is totally enterprise compliant.

PostgreSQL is deeply established and can be purchased by the hour on most cloud platforms; Node.js and React are standard now, too. GraphQL is still fancy but not exactly bleeding-edge. Hasura is written in Haskell, but you run it as a binary, and it has a venture-backed company behind it; Postgraphile is fully open and all in JavaScript.

What this means is that you can use these tools in your giant organization. They’re simply libraries on top of existing, approved, well-understood technologies. PL/SQL, which is the language for writing PostgreSQL functions, was created by…Oracle.

Let’s imagine everyone said, “No, forget it, we want to go back to the old ways. Rip out the JavaScript and put Java in, instead. Let’s use SOAP.” All that would happen is you’d have a well-defined database schema with a set of database-native functions. That’s it. 

There’s no risk. You’re looking at a set of tools that are endorsed and supported by Microsoft, Amazon, Google Cloud, IBM — places like that. It might feel new and different, but it’s just…simpler.

Watch this space over the next few years. This is a powerful, less expensive way to work and I’d expect more and more developer tooling and simplifying frameworks to emerge.

Data models over code

In that same Wired article, I also wrote:

Programmer culture tends to devalue data. The database is boring, old, staid technology. Managing it is an acronym job (DBA, for database administrator). You set up your tables and columns, and add rows of data. Sure, 80 percent of your code in Swift, Java, C#, or JavaScript is about pulling data out of a database and putting data back in. But that other 20 percent is where the action is!

What Enterprise Codeless lets you do is own up to that 80% — stop trying to abstract it away, go inside the database, and get the schema just right. The paradox is that by doing this, taking this time, really thinking it through, we make everything go much, much faster — and we can ship working products inside of giant organizations with legacy IT systems and do it in six months.

So that’s the key. You might wonder how a services firm would feel if suddenly a new stack came along that made a lot of their work redundant. And the answer is, we feel great. There’s enormous opportunity and growth here, and the chance to move ever faster. In software, no matter what, speed is always a virtue. Which means that sometimes old, slower ways fade away and accelerants appear. That’s not a risk to our business. That’s literally the best thing that can happen.

Paul Ford is the CEO and co-founder of Postlight. Talk to him about digital transformation at hello@postlight.com and find him on Twitter @ftrain.