@mtnygard, regarding your last comment, when I think of form data, I think of traditional forms and the application/x-www-form-urlencoded and multipart/form-data encodings. I’m thinking request body is a more appropriate term.

Actually, are there any good samples of CLJS clients that play nicely with Vase servers? (I know the easy answer is "Vase is REST and REST is standard so anything works") but it seems to me that the answer is more subtle than that... namespace issues; sharing schemas between client and server; dev tools and environments; etc.

I'm wresting many more issues than I would have guessed, trying to write a toy app. Much is my own learning curve, so I'm not yet sure which (if any) of the gaps are real.

Hmm, I don’t think I’d say Vase is REST. Folks throw around that term loosely nowadays.

I think the exclusion of the term REST in the README is done on purpose

You're right. I should have said something like Vase makes it easy to write REST-like and similar APIs that are designed to play nicely with any standard language for the client app, rather than forcing clients to be CLJS

re: clients, theoretically any client will do. There is a sample that is intended to be used with Om.next

although Om.next is sorely under documented 😞

Reagent is pretty easy to learn/use https://github.com/reagent-project/reagent

But, my point -- reinforced by what you just said -- is that Vase's focus is "any client will do". It makes it very easy to inter-operate, but may lose some of the extra advantages that come from using one language and, more importantly, one dev environemnt, across the client and server.

Yes, I use reagent. That part is not the problem.

It's more issues like: - namespaced keywords have suddenly become interesting in Clojure 1.9, but I don't yet have a good model of how to play nicely with them. - Sharing schemas across client and server encourages a three project design (client, server, and a shared code library including the schema). But, the minute I have two Lein packages in my CLJS environment, and actively edit both of them, then a lot of the niceties of Figwheel and friends just disappear.

My immediate problem is that the ecosystem is so vast and fragmented, that I don't know yet if (1) I'm hitting known gaps or (2) I'm doing things stupidly/unconventionally, so I'm banging my head against unusual problems or (3) tools/practices do exist to solve my problems, but I've simply not found them yet.

hmm so you don’t have to have different lein projects. You can share code that’s in a cljc file. See https://github.com/clojure/clojurescript/wiki/Using-cljc

It depends on the system you are building

But you don’t have to lose tooling support

@deg @ddeaguiar I do recommend multiple modules (possibly in different repos) for the client, server, and shared. I can offer “leiningen checkouts” as a feature that eases the pain of using code across libraries. That allows you to avoid repeated “lein install” commands on every code change.

@deg Also, if you have a REPL open to a process, you can reload a namespace that belongs to a library just the same way you would reload a namespace from the local project. It just replaces symbol definitions in the JVM.

But more broadly, I sympathize. There are so many different permutations of web framework, client library, build tooling, etc. that it’s hard to find one project that shows a canonical way to connect the parts.

I’m working on that as I have time available. E.g., there are several projects on my personal github profile that illustrate different combinations of tech.

For example: https://github.com/mtnygard/todo-backend-pedestal-vase

But I don’t have any public projects that connect the front end because that’s a new area for me. I’m just learning the best ways to do that myself.

My previous project used luminus + reagent/react + figwheel + cdier , etc. It was all very nicely integrated and easy to develop. The one tooling downside was that the project.clj was a complete bear. Except for adding new libraries, I was afraid to touch any part of it.

This time, I'm playing with Vase. I'm attracted by its leaner feel and better separation of concerns. But, I'm discovering now that this comes with a price.

I have a non-public project that uses Reagent and figwheel on the client. Vase and custom interceptors on the server. CIDER for everything.

It’s just not something I have the right to open up.

(Oh, and there’s an Electron client, to boot.)

Would you be able to get the rights to release a stripped down version of it?

Most likely. It’ll be a week or so before I can publish anything though.

Maybe we create an issue to add a sample to the Vase repo?

I’d be happy to pick that up as well

@ddeaguiar Without question.

Ok. I’ll add it

I think the samples right now kind of miss the mark. They’re either too isolated or too esoteric.

(FWIW, in my consulting business, I've long had a clause in my contracts distinguishing between code that belongs to my clients and code that belongs to my library -- and I've always kept the right to add my library while working on client projects. In decades of doing this, I've never had a client complain, and it added value for them and all future clients)

Yep, we have the same. There’s still a notification process though.

I managed to get away without the notification clause. But, that may have just been a combination of luck and small/intimidated clients. A few much larger companies forced us to sign their contracts, and kept things more isolated, so the point was moot.

But, I digress. 🙂

I'm happy to help out with making samples more usable. I think my outside perspective will help catch holes -- if nothing else, I'll be helping myself learn better.

https://github.com/cognitect-labs/vase/issues/65

OK, authorization procured. Now I need a few hours to strip it down to a manageable sample.