The specification process is interactive and looks like this (click to play movie):
See how out of the box you get free user interface scaffolding. We say “scaffolding” because this UI is just a jumping-off point. Customize it with ClojureScript, or throw the whole thing away and bring your own frontend.
The big idea here is that there is no backend coding. You spec your API and the backend is done. There’s a user interface out of the box. The client/server data sync is taken care of, you’re not coding HTTP requests.
API spec is like GraphQL (but an actual query for a concrete database)
All fiddles have a Datomic query
Datomic is a database, immutable model, specifically designed for functional programming
Hyperfiddle is functional programming and needs first-class immutabilty in the database
Cannot be built on mutable datastores like Postgres, MongoDB, Neo4j
Leaky database abstraction is the deep reason that all "app-builders" fail
Works the way HTML works – forms and links
Hyperfiddle is like HTML for user interface and API
Fiddles have links to other fiddles (fiddle graph)
Three types of link: anchors, buttons and iframes
Buttons submit forms and invoke database transactions (a Clojure function)
Any UI can be broken down into fiddles
HTML has scaled amazingly well to vastly more complicated applications than it was originally intended for. We designed Hyperfiddle to scale APIs the same way. Efficient composition of APIs has profound implications.
A 25-screen app built for a client
Back in Q1'18 we built this MVP in 2-3 man-weeks? Would take less than a week, now.
user accounts and profiles
user onboarding and other workflow states
hooks for third-party integrations (identity verification, bank verification, blockchain wallets)
customer service dashboard
Essential complexity is:
Understanding the requirements
Modeling the database
Figuring the queries
Hyperfiddle provides sensible defaults for everything else, which you can customize with code, later.
Hyperfiddlin' feels like this
Automatic backend and web service
Every fiddle is URL addressable
Every fiddle has a UI view, an Admin view and an API view
The API view shows what information was sent over the wire.
Your fiddle API view will not necessarily match the information in your web browser's network inspector
auto UI, if you are using it, also depends on your fiddle metadata, your Datomic schema, etc.
hyperfiddle editor (toolbar) also has dependencies
transport is optimized
We compose (batch) your fiddle APIs with any other APIs where sensible. That is deeply interesting so I will say it again: Hyperfiddle APIs compose (automatic batching is a byproduct of this). A good way to intuit this is to recognize that the server rendered text/html representation of your API composes too.
Hyperfiddle's data loader
Traverses the fiddle-graph to find the connected components for this page
Runs the queries, accumulating a resultset
syncs them to the view
refreshes the right subgraphs when a dependency changes
This is all automatic, and it's faster than you could have coded it by hand (like an optimizing C compiler).
Managed cloud platform, managed database, no ops
designed from day zero for Datomic Cloud Ions
hyperfiddle.jar slots right into your own Datomic Cloud Ions
or run it as a Pedestal service, or a Node/Express.js service, or both, or whatever
all infrastructure will soon be open source (we are decoupling from our own cloud in Q3)
UI coding is Real Functional Programming
All fiddles have a frontend view
Hyperfiddle is about immutability and ClojureScript has much richer idioms for this
Markdown is first class, because good software is self-documenting
AWS UI is 50% inline docs, 40% tables and forms, 10% custom stuff
Format text cleanly and rapidly without thinking about HTML
PMs can edit the copy, live in the app, without risk of breaking things
I am a strong Clojure/Script developer, yet still I sketch faster in Markdown.
Is there code here? Yes of course, there's always a little bit. Have your web designer google "how to format a date in hyperfiddle" and copy/paste. There's not a lot that can go wrong.
Your specification captures API and it's interdependencies (query-X depends on query-Y and query-Z) as a graph. We call this the fiddle graph.
Hyperfiddle : fiddle graph :: Chrome : HTML
Technology – how it works
Immutability makes data loading really fast
Your user interface essentially evaluates as a stored procedure in the database, which means exact and optimal data responses
After data is loaded, browser retraces on the frontend to render the views
Arbitrarily deep nesting, recursive super-forms
no abstraction loss
no object/relational impedance mismatch
no performance loss
no JOIN pain
no REST client/server round trips
no async / latency / failure
Hyperfiddle’s I/O layer is intelligent.
API-as-graph means data sync is just a graph partitioning problem – find the connected components
Fiddle graph is abstract data, so concrete I/O implementation is unspecified
Business logic decoupled from I/O
Like an optimizing compiler, it can optimize in ways that hard-coded I/O cannot