Table of contents
- You specify your API, we serve it
- API spec is like GraphQL (but an actual query for a concrete database)
- Works the way HTML works – forms and links
- Any UI can be broken down into fiddles
- A 25-screen app built for a client
- Hyperfiddlin' feels like this
- More hyperfiddlin'
- Automatic backend and web service
- Managed cloud platform, managed database, no ops
- UI coding is Real Functional Programming
- Markdown is first class, because good software is self-documenting
- Fiddle graph
- Technology – how it works
You specify your API, we serve it
- complete working API
- user interface scaffolding out of the box
- managed cloud backend and database
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
- business logic
- hooks for third-party integrations (identity verification, bank verification, blockchain wallets)
- customer service dashboard
- admin interfaces
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
For more tech stuff, see Technology.