you can always find examples to learn from in nixpkgs git repo. If the package can build from source, look at other package with similar dependencies. If the package is binary distribution (eg closed source), follow this guide: https://nixos.wiki/wiki/Packaging/Binaries
from now on every new machines will be easily replicated with configs from older machines: copy the config file over, type one command and let nix does the rest
nix is the solution. It's totally different from any random packager you've seen. It goes the reversed direction of abstracting dependencies away: it makes dependencies explicit (and reproducible!)
yes, it's included. Nix config files will automatically generate and run services. There's also Nixops which is a tool to push these config to remote machines ie cloud vms.
> This is actually fairly common in Clojure annd Clojure script. Sometimes using the Datomic DB as a backend for it.
What do you mean by "this" which is fairly common?
Datascript is a Datalog implementation, however you can't just bring your query from backend to frontend, not only for incompatiblity but also for security issues.
And Datascript is not that popular among Clojurescript apps.
Fulcro is defintely the go to framework. It makes use of EQL, which is a superior alternate to Graphql, for server-client communication.
EQL is surely a great alternative to Graphql because of namespaced keywords and rich data structure (in contrast of Graphql's string base). It is also inspired by Datomic's Pull API. However, it's a specification and the most popular imlementation (Pathom) has nothing to do with Datalog.
Fulcro can be too sizable to consume in one bite, most importantly the three core concepts (ident, query, state). Personally I find it useful to start with just EQL which is an Clojure native alternate to Graphql. In fact, Fulcro's predecessor, the famous Om.next was inspired by Graphql.
Introduction by Wilker Lucio https://www.youtube.com/watch?v=yyVKf2U8YVg
Yeah, long require forms, long namespace keywords, protocol methods... but they are all necessary so Fulcro can figure out a lot of things itself. It pays off really well because things that are often hard in other frameworks such as forms and server-client communication suddenly become easy as a result.