Biff and Site #107
Replies: 2 comments 9 replies
-
|
Great comments and I agree 100%. I am familiar with both Site and Biff. I probably have somewhat quirky needs but the two use cases hit my needs perfectly and will probably work for a lot of others. A combination would be awesome! I have not looked at HTMX yet but one thing that excites me about it is that it recognizes that React/javascript/clojurescript is not the only way to create a web app. It seems to me that the pendulum has swung a little bit too far on the client side. One of my needs is for content that changes over time but the time frame is weeks rather than seconds. There is no need for the complications of the React world when server side HTML is fine. Also this has the advantage of being allowing you to work in Clojure as opposed to Clojurescript. Another aspect of Biff is the deployment story which is provided for you and it can be deployed almost anywhere. Linnode for example can be very easy and economical. Site is not bad but Juxt's infrastructure is more complex and requires a little more work. I think that Biff is more focused on what a small startup would be able to deploy and manage. Finally including site within Biff is brilliant. I had looked at apex for API use but why not the whole things and if Jacob includes the deployment scripts it shouldn't be much harder to get running than Biff alone. One thing I would add and it may already be there in Biff is a good container based aproach for deployment. This could be simpler and it is almost as widely supported as the more bare metal aproach. All the major services have container support and I see Kubernetes becoming mainstream and becoming easier to deal with. It may not be needed for most Biff applications but solid container support will make it easier to scale anything that needs it. Good work Jacob - I look forward to digging in on this. |
Beta Was this translation helpful? Give feedback.
-
Good to know! Some time after the next release, maybe you/we can get one of your projects set up with Biff and Site. Then it'll be clearer if a Site integration should be included in the default project template, or if there should just be a separate blog post with instructions for those who want to set it up. (Currently my guess is that it'll be best to do the latter).
Site seems about as easy to deploy as Biff I think? i.e. it's just a jvm process you run anywhere. One thing I would want to figure out is if Site can easily be ran from the same process as the rest of a Biff app (basically can it be used as a library instead of as a standalone appliance?). If it does work well as a library then including it in the default project template would be plausible. I'd like to keep the default Getting Started flow to a single server. Apex is another interesting Juxt project I hadn't seen until just now! It'll be informative to see if many people want to use Biff to make public APIs--I suspect integration with Site (and/or Apex?) will mainly depend on that.
This is another good topic which probably deserves a whole other writeup. In short, I've investigated options for managed container deployment a bit, and so far my conclusion is that sticking with VPSes as the default is likely best; however it would could be useful to have guides for deploying elsewhere (e.g. "Here's a step-by-step guide to deploying the Biff example project on Google Cloud Run"). (Edit: or maybe just throw in a Dockerfile). I'll wait for people to ask about it first though. |
Beta Was this translation helpful? Give feedback.
-
|
I think that Apex should be able to provide most of the functionality of Site as to OpenAPI also there is a juxt Graphql library called grab. I do think that with the server side HTMX as opposed to client server Biff needs an API solution |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to mention that Apex is deprecated, most of it got transplanted into Site's repo at https://github.com/juxt/site - the name was kept to keep the OpenAPI namespaces apart from the rest of them. Site is a project that brings together jinx, pick, reap, apex, grab, https://rest.guide and, of course, xtdb. I'll get round to communicating this properly on the Apex project site. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the analysis & write-up 🙂 I should point out that GraphQL is the current schema strategy for Site, in particular using the Schema Definition Language (SDL) with a few custom directives (for Datalog queries, "Lambdas" etc.). This means that the OpenAPI implementation now prefers to wrap GraphQL by default - although standalone-OpenAPI + JSON Schema remains a secondary schema option (it was the main strategy previously...but it turns out that GraphQL covers more ground and offers more potential). Site's webapp strategy is to defer everything UI-related to Jamstack frameworks with slick GraphQL integrations, e.g. see https://github.com/armincerf/site-wordle I wonder whether anyone has attempted to generate SDL using Malli yet 🤔 |
Beta Was this translation helpful? Give feedback.
-
Very much this right now, sorry 😞 |
Beta Was this translation helpful? Give feedback.
-
|
No need to apologize! I'm just curious about Site's scope. I take it they are in scope. |
Beta Was this translation helpful? Give feedback.
-
|
I’m a bit late to this party but think I can add some clearer answers to some questions here (I’m working on site)
|
Beta Was this translation helpful? Give feedback.
-
|
Sounds good, thanks for the clarifications! |
Beta Was this translation helpful? Give feedback.
-
I think that's a very good summary.
It's comparable to Hasura, definitely. While you can use Site as a web-server and host applications, you can also host them on Netlify and use Site as a pure API server. There's some temporary notes about authorization in Site here: https://github.com/juxt/site/blob/mal/sessions/test/juxt/pass/authorization-notes.adoc |
Beta Was this translation helpful? Give feedback.
-
@refset brought up that it could be handy to have a clear explanation of what are the differences/similarities between Biff and Site (https://github.com/juxt/site) and how they might be used together. I've spent a tiny amount of time looking at Site and reading various docs just now. I'll give my current understanding of things, and if anyone more familiar with Site wants to provide corrections/clarifications that'd be great. I am only about... 70% sure I understand Site. (In particular I may have blind spots due to ~all my experience being in the solo-developer-entrepreneur, imma-hack-together-this-janky-app-idea-asap space).
I think the problem Site addresses is "I want to provide an API for my database but I don't want to write a bunch of tedious CRUD endpoints by hand." You write up a declarative OpenAPI description and presto, instant REST (and GraphQL?) API backed by XTDB.
Biff's scope is broader: it attempts to curate and pre-assemble all the pieces you need for a web app (i.e. it's a web framework), while making it easy to switch out the default pieces as needed. A REST API is one potential piece of a web app, so it could theoretically make sense to have Biff include Site as one of its pieces.
I think we can split up the uses for a REST API into two categories: (1) to power your own front end, and (2) to provide a public API for 3rd party clients/integrations. Biff doesn't do anything special to address point 2, so including Site could be handy for that. (I would probably wait to see if this is a common need for people; so far I mostly haven't provided public APIs for my own apps). For point 1, Biff mostly has its own non-REST ways of dealing with the CRUD-endpoints-are-tedious problem; however Site could possibly still be used for some scenarios.
To expand on point 1: instead of having the front end go through REST endpoints, the current release of Biff lets the front end submit arbitrary queries (which are formatted like XT's datalog but don't allow joins) and transactions (which provide a higher-level interface to XT's transactions sans the ability to set a custom valid time). This is also the same approach Firebase takes. It works because you write a bunch of declarative authorization rules, and then Biff/Firebase checks your queries and transactions against the rules to see if they pass or fail. While that obviates the need for a REST API, a GraphQL API might still be helpful since, as mentioned, Biff's (and Firebase's) queries don't allow joins, and thus the front end usually has to submit one query, wait for the results, use those results to make the second query, etc.
However that last paragraph is a bit of a moot point because in the next release Biff will no longer be a SPA by default. Instead there will be a single default setup that uses server-side rendering and HTMX. Thus there's no need for a REST API when rendering pages (since rendering is done on the back end where we already have the ability to run datalog queries). A REST API could still be useful for write operations. My own apps so far haven't been terribly CRUD heavy, so writing the endpoints I do need by hand hasn't been much of a burden (also the endpoints often have additional business logic anyway, so the overhead of doing CRUD by hand is minimal).
In summary: I think Biff not being a SPA obviates the need for Site for the building-your-own-front-end case (though Site still might be useful for CRUD-heavy apps). However Site would possibly be useful for any Biff users who want to expose a public API.
Appendix: Since Biff already uses Malli to define schema (which is used to check transactions before submitting them to XT) and Malli can be transformed to JSON Schema, Biff and Site could both use a single shared Malli schema I think.
Beta Was this translation helpful? Give feedback.
All reactions