Awfully quiet today. 🙂 In the template .edn file, is it intentional that :db.install/_attribute :db.part/db is used in the example of a norm? I understand from the docs that this is no longer needed.

That change in Datomic came more recently than the samples.

The samples can be updated as long as we add a note about the minimum revision of Datomic supported.

Is the minimum version documented somewhere? I'm happy to add in this kind of thing as I'm learning/proofreading, but I've not yet found enough reference docs. The Vase docs still seem to be strongly example driven.

Right now there isn't a minimum. You could use Vase on any release of Datomic ever.

Still, seems wrong to have the :db.install stuff in a beginner's doc. In trying to understand the .edn file, I had to browse through much too much of the Datomic Schema docs in order to just learn that I didn't need to pay attention to that line. 😞 (I had tried an exercise of rewriting the complex norm as a simple one, to ensure that I understood it completely. This line was a sticking point. FWIW, so was :unique vs :identity; also only answered by reading through the datomic docs)

I think what we need to do is make two docs.

"your_first_api.md" today is really meant to be "your first Vase API" for someone who already knows Pedestal and Datomic, but wants to learn Vase.

I think you're aiming at something more like the Pedestal getting started guides.

That sounds right to me. Also, two .edn files. (See my #2 comment yesterday, about the awkwardness of being instructed to shorten a sample file)

Not just two files. Two different directories.

Yup

The minimum necessary for a Vase app is quite small. The template generates a more full-features, production-ready app... but that's not helpful to learn from.

Yup. I was blown away (in a very positive sense) by how little code was in my lein new vase foo.

It would make a lot of sense to have two templates.

It's still more than I'd like. 😉

That's a great goal. As a newbie, I've found that one of the weaknesses in the Clojure client/server ecosystem is that it is evolving so quickly and so much knowledge is embedded in the codes generated by templates, that it is very hard to upgrade a project to take advantage of the changing landscape.

I agree. It's not just frustrating for a newbie. Way too much capability is tied up in templates and build tool plugins.

I know I'm going to hit a learning curve in a few days when I try to introduce the client code into my toy Vase project.

Do you mean front-end ClojureScript? Or do you mean call-outs to other services?

Until now, I've used the framework-like templates that put all the pieces together -- paying the price of manually upgrading each time the landscape improves -- so I don't really know how to hand-code all the goodness of figwheel + cider + production builds + etc. and Vase doesn't have this all rolled together. (for better and worse)

Front-end Clojurescript. I like the idea that Vase is client-agnostic; it's certainly the right way to go. But, I write my clients in CLJS, and it is very convenient having both sides started by the same template framework. I don't know the right answer.

One thing I'd suggest is this: keep the client app and the Vase service separate. As in, different directories, different project.clj files.

There's no need for them to occupy the same project and it just makes everything harder to configure and build.

So for the front end, feel free to use a figwheel template app. It'll work just fine with Vase services.

They just meet at the URLs.

Once you get a ways down the road, consider creating a third directory, with .cljc files that describe the specs for your data interface.

Then include that from both front and back end.

There's a lot of power in creating a metadata driven contract between components.

Is there a standalone figwheel template? That does sound much more right. My last project was Luminus-based. It was very easy to get started, but I still have no friggin' clue what's going on in the project.clj.

Yep. lein new figwheel hello-world

https://github.com/bhauman/figwheel-template

Thx. I'll take a look at that soon. I definitely like the idea of separate, understandable, projects.