Thanks very much everyone for your replies. Lots to look into!
One tech conspicuous by its absence is Datomic Ions. Any stories from folks
going that direction?
Thanks again!
Tom
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this grou
Hi Rick and list,
Rick Moynihan writes:
> Thanks again for all your hard work on this James, it's a great piece
> of work and I believe worthy of much wider community adoption.
+1 for the thanks! I aslo use integrant and appreciate it a lot.
I learned a lot by studying this project:
https://g
On Mon, 24 Sep 2018 at 18:29, James Reeves wrote:
>
> The latest alpha version of Integrant also adds a 'prep-key' method, which
> allows default references to be added to an Integrant key without the need
> to resort to modules or external configuration modifier functions.
>
This should be
I don't want to derail the conversation, but on the subject of Duct and
Integrant, it's certainly possible to use regular Duct libraries in
Integrant without buying into Duct's module system, should you want
something more straightforward.
The latest alpha version of Integrant also adds a 'prep-ke
I'm a massive fan of integrant on which duct is based. In my mind it takes
Stuart Sierrra's component to its logical conclusion, which is essentially
treating the system as EDN configuration. I think most moderate/large
component projects tend to want to convert systems into config.
Essentially i
Duct looks interesting.
I found luminous useful for when I first started with web dev in clojure
but started running against its project layout.
On Sun, Sep 23, 2018 at 15:17, Rick Moynihan
wrote:
> I really quite like weavejester's duct, because it's essentially a
> familiar / standard ring app
I really quite like weavejester's duct, because it's essentially a familiar
/ standard ring app, but with integrant based configuration modules, and
sensible defaults. It's not perfect though, e.g. ataraxy is somewhat
under-developed, so I'd look at swapping it out for bidi or something more
matur
Pedestal isn't cross-platform -- doesn't support Windows.
Yada's documentation is not complete (several chunks of the documentation
have said "coming soon" for years).
Luminus is a great choice, the only downside is that as luminus improves,
there's no easy way to incorporate those improvements int
Luminus is great. Something people might not know about Luminus is that
it's more of a project template than a framework per se. It solves the
choice paralysis of what libraries to use when starting off. It generates
a project, and you can take or leave the decisions it makes because after
project
I'd take a look at yada. It's a batteries included library for writing HTTP
APIs with good documentation. I ported a Ring-based app to Yada. The commit
diff for the project file looked like this:
https://twitter.com/borkdude/status/857979807358910464
On Monday, September 17, 2018 at 11:27:17 A
Most of the choices are, or can be, wrappers around at least one
battle-tested server - Jetty, Netty, Tomcat, etc. If you care, then decide
that first. If you don't care, then how about Jetty. Next: if Jetty, then
you will wind up in Pedestal sooner or later, so why not start there.
Pedesta
Having built a couple of apps with Luminus (including a SPA), my vote
definitely goes there. I've even been able to cherry-pick functions and
project organization from the leiningen template and inject them into a cli
app which had a server component. Extremely well organized and
documented.
For me,
pedestal as a backend. UI - om.next for complex projects, reagent for
simpler.
I prefer remixing smaller basic building blocks to "ambitious libraries"
like replikativ or even re-frame.
Datomic is ideal for most business cases except when its license is somehow
incompatible or
the arch
13 matches
Mail list logo
