The combination of svelte + postgrest enables rapid prototyping while reducing boilerplate, helps minimize the mental footprint, and is straightforward to grasp, all while being surprisingly flexible.
In this text I’d like to describe the reasoning and road taken to reach the tech stack that I grew to adopt, explain the choices made and suggest who in particular may benefit from using this combination of technologies.
The journey was almost two decades long. However, the presented solution began to emerge in the last two years or so.
I’ve been programming web sites & apps since 2002 or so, hitting the road with PHP4. What follows are my rather personal observations on how things went from that point to the present in web development.
Back then, things were converging around the MVC pattern. Since the client was (mostly) static content, changes to which involved page refreshes, it was sufficient to organize user actions, data flow, business logic and what the user ended up seeing in a way that made sense.
In those rather early days, no specializations existed in web development. Since the field was young and rather narrow, *everyone* was a full-stack engineer.
Needless to say, that sweet innocence didn’t last. As soon as the browser (JS) evolved towards dynamic pages (DHTML was a term back then), with JS becoming increasingly capable, the discovery of “AJAX”, permitting to query partial HTML snippets from the server, and eventually the advent of JSON, enabling “proper” SPAs, complexity sharply increased, taking its toll on the client side logic.
This entropy, in turn, was answered with new tooling to amend the chaos that client side programming was becoming.
Initially, the venerable jQuery took on as a way to streamline DOM manipulations & events, succeeded by more comprehensive attempts to marshall state, rendering and event / action flows in setups that grew increasingly complex as the front-end gained an ever more complex business logic.
To bring an order into this chaos, frameworks such as Backbone and eventually Angular and React were introduced.
As client-side development evolved, developer knowledge and focus shifted towards these new domains. Web development as a whole began to suffer from a domain split, where separate disciplines and sets of skills were required to create the backend (persistence & business logic), and a completely different skill set was emerging for the creation of an ever-evolving, more and more elaborate world of UI and UX, fueled by an ever growing matrix of Devices, increasingly capable Browsers, multiplying Operating Systems - each its own set of intricacies, features, limitations and usage patterns.
This resulted in the emergence of the front-end developer.
Their distinction from back-end programmers, and, well, of those who claim they’re “full stack”, though that latter group does not instill much trust from oldtimers as myself, given that no matter how large the volume of knowledge that a “full stack developer” with two years of experience would have, it would still be very thinly spread.
Throughout this evolution of the web stack described above, I kept bouncing between various corners of the field, never staying in one spot for too long.
Early days I wrote domain specific PHP frameworks & tooling, which were both back and front-end. Proceeded to hop on the Python bandwagon (Pylons circa 2007), then to write JS animation and graph scene frameworks in 2012-3, only to bounce back into solving scalability and performance problems on the backend (database sharding, green threads for concurrency with the advent of websockets). In the last decade I dabbled in browser extensions, and 2021 threw me into the world of Electron apps.
This experience led me to discover that what I really enjoyed was the research and architecture building activities that often characterize the early stages of a project.
This kind of activity requires rapid iterations, trial & error, and the ability to quickly throw different approaches at a problem, resulting in sweeping architecture modifications and refactoring.
This kind of activity is best done by as few participants as possible. The more people - the higher is the communication overhead, the slower the speed and efficiency.
And this, if you read this far, brought me to identify the problem:
As the field evolved, it became increasingly difficult to do the one thing that I enjoyed doing: single handedly churn out dirty proof-of-concept solutions that could later be built upon and expanded into real products.
The mere act of wrapping one's head around the entire combination of technologies required just to bootstrap any unexceptional project became burdensome.
The mental context switches required every time one’s attention moves from infrastructure (whatever form it took), persistence (SQL or any other flavor), backend business logic (be it PHP, python, or even nodejs), and, mainly, the latest choice of another ever-evolving frontend framework, with its yet-again-novel way of doing things, introduced an overhead so high, while the necessity to hold the vast and heterogenous body of knowledge to support those activities did not leave much room in that head of mine for the actual task at hand.
Well, at least the problem’s identified. And we can move on to seek a solution!
A concise, small collection of tools that allows us to deliver without getting in the way, doesn’t force us to keep too much on our mind, and at the same time be expressive and not get in the way of a product’s long term growth.
PostgreSQL is the most popular and feature-complete open source database that’s out there. In addition to providing the Relational solution (SQL), it also replaces a Document store (such as MongoDB) with its JSON(B) support and a Message broker (such as RabbitMQ).
In addition, it comes packing
PostgreSQL is so widely adopted that it has a bunch of both opensource as well as commercial solutions for everything from columnar storage through sharding and down to replication, providing plenty of room to grow. SQL is a widely adopted standard.
All of the features listed above need a way to be unlocked and made available to the front-end. The way that’s traditionally done is via a server-side solution such as Python, PHP, NodeJS, Ruby (and plenty of others).
Such server-side solutions typically also hold the business logic, enforce constraints, validate input, perform auth, using the database for storage alone, complex queries aside.
PostgREST is a tiny and concise module that utilizes PostgreSQL’s power to radically deal away (for the most part) with the need for a server-side language.
This is possible because the underlying database allows to express (and enforce) business logic on various levels (declaratively, using data definition constraints, and procedurally with triggers, custom functions, views and other abstractions), protects this logic via an elaborate role & permission system, and allows to easily define custom authentication with its JWT support.
So the only thing that PostgREST does is expose the database through a REST API, and, for the most part, does not get in the way.
While one still needs server-side code for tasks such as worker queues and functionality that cannot be expressed in the DB, it is nevertheless surprising, for someone who’s written server-side code for almost two decades, to discover that server-side code, in its traditional sense, is simply not needed.
And there’s more! Getting used to expressing business logic and constraints declaratively, brings one to the discovery that data-based constraints, other than being concise, are a very solid safeguard against errors and lacking validation in code that’s higher up. In other words:
And when we express business logic declaratively, concisely, in the database, we relieve ourselves of the need to express it elsewhere. Hell, we relieve ourselves of the need to even have a server-side app. Well, we delay that need, until it surfaces, sooner or later. But let’s not be picky.
As I was trying to force React down my throat, getting used to the excess boilerplate of redux, and trying to wrap my head around functional components, convincing myself this is the one tool to use due to its wide adoption, a friend suggested that I try out Svelte. I did, and haven’t looked back. Here’s what so good about it:
On the subject of bloat, I’m inclined to try out Tauri as an Electron alternative, now that Edge versions have mostly stabilized on Win*.
Here’s my little boilerplate template that can be used to jumpstart the above evangelized combination of tools. Caution: SvelteKit support is just fresh in, so, there be dragons.
I run a small consulting shop that specializes in rapidly churning out custom-built web solutions. And I just gave you the recipe for our secret sauce. If you like the idea, we can cook something together. Welcome to drop me a line.
© 2023 Web GMA R&D Ltd.