Fork me on GitHub

Can I change :com.wsscode.pathom.core/not-found to another key in answers in pathom?


Yes, I can do this even with final output without plugin. I have an issue to understand settings and possibilities for configuration.


oh there are ready plugins, I have to read pahtom code one day


Do you use fulcro ? Why? Why not?


I am trying to make a decision if I want to to use fulcro or not. I feel it is too much framework, but if I want to use pathom maybe it makes sense anyway?


It is Fulcro on the client then often Mount, Ring, Pathom on the server. It is not Fulcro or Ring, which is I think what you were saying. And once you have a server that takes EQL, why not use a client that sends EQL?


my mistake then, but the point is if use fulcro or not


Sure the client which send EQL make sense


but still not sure about fulcro . I didn’t use this one, but it looks like framework which make many decisions for me which I can’t easy change.


So do use use fulcro? Why?


I guess I can use EQL queries without fulcro


fulcro is BE and FE right? So have I to use this everywhere?


Fulcro composes the EQL that you provide to the components you create. You can still use what you want for CSS for example. You can still use JavaScript libraries. Fulcro is good for big applications as your code is declarative.


No Fulcro is front end only. It used to be back-end as well, until Pathom came along.

👍 1

But for example I have to use shadow-cljs ? At least doing this in different way will make everyhing harder


oh I didn’t know


so fulcro is FE only now


ok it changes a lot


great, thanks for clarification!


Now the pessimistic part of a Fulcro mutation is handled by Pathom resolver.


good, then maybe I will take a look on Fulcro once again


There's many layers to Fulcro. Start with app state. That may be all you need.


so far I prefered re-frame


I don’t know too much about fulcro


There is a book and you have a big head-start if you are already comfortable with EQL:


yes…. very long doc to start with fulcro


Its a reference guide. But the app state part (normalisation) is really very simple and should give you the equivalent of a re-frame application, but without writing 'subscription' style code.


(I say it is simple, but it does take some effort to pick it up).


I would disagree that Fulcro is more “frameworkey” than re-frame. Fulcro is primarily concerned with 1) managing app state transitions and 2) providing components with access to relevant state. This is really not that different from re-frame. Both share a lot of the same concepts around #1, but use different mechanisms for #2 (queries vs. subscriptions). Fulcro arguably provides more out of the box for #1, especially when it comes to remote interaction, but it doesn’t tie your hands - pretty much everything in the transaction processing pipeline is pluggable. And the things that tend to change the most are the easiest to modify. So for example, while in theory you could replace the whole transaction pipeline with something else, that would be a lot of work (and fortunately, rarely needed). However, replacing the default merge logic (which is probably sufficient for 90% of cases) with a specialized merge for a single transaction that requires special consideration is relatively easy. Or customizing error handling for a single transaction - piece of cake. One of the 4 built-in renderers doesn’t fit your needs - write your own that does? This may sound daunting, but take a look at the source code for one of the existing renderers - there’s not much there! The whole architecture of Fulcro has been refined and simplified over several iterations (with F3 finally getting rid of the old remaining Om-Next baggage). Whenever you need to customize something - which isn’t often, but will happen if you write enough “real” apps - the clean architecture and using the existing implementation as a reference makes this much less painful than you would think.


Disclaimer: what I said was about my feelings 1 year ago (I guess). So it can be not up to date.


We just went through an evaluation of the current "state-of-the-art" to see if we should continue with our current prototype or pivot. This is what we came up with (somewhat abbreviated):


As a business building an extremely ambitious product on a tight budget, we
want to be able to:

* Focus as much time and thought on building features that bring value to our
  customers, rather than, for example, building a bespoke protocol between the
  browser and back-end if a better alternative is available.

* Share early iterations of our application with everyone in our organization
  easily. Capture feedback and push out new iterations quickly.

* Be able to support new customers immediately. Our feature road-map will
  always be in constant flux, but at no point should our ability to make
  changes with confidence be compromised. In addition to feature development,
  tests and automation must be priorities. Our development and production
  environments must match.

* Be ready to onboard new team members. "Works on my laptop" is never
  acceptable. Enough of our application must be documented and automated so
  that anyone with a technical background "reasonably proficient" in our work
  can contribute without requiring hand-holding. Or course, we'd never turn
  down a request for help.

Does our current implementation help or frustrate our attempt to meet these
objectives? Assuming the answer is "frustrate," what should our next steps be?

Our new challenge now is to decide what we want to replace in our current
implementation and with what. Our requirements are:

* Clojure, Clojurescript, and Datomic are immutable choices. We love these
  solutions for their simplicity and expressiveness. We believe these are the
  best choices available for achieving our long-term business goals.

* Be measurable. Our work should be guided by data not guesswork.

* Be testable. The entire application should have 100% test coverage as
  measured by its acceptance or integration tests (not unit tests). Changes
  should be made with confidence.

* Be performant. As builders of both the front-end and back-end components, we
  should encourage cooperation between them, not purposefully isolate
  them. Our customers and the end-user experience should be our priorities,
  not artificial divisions between software components or technical teams.
  Each component of the application should cooperate to support progressive
  enhancement where every URL is a real URL that, when requested, returns a
  server-side rendered page view. Further actions by the user result in
  browser-side changes through API calls and minimal component updates.

* Be pragmatic. We should be eager to innovate when the need arises. However,
  we should be humble enough to understand that sometimes, as software
  developers, we can become enamored with new toys that are entertaining, and
  possibly educational, but offer little business value. We should choose
  existing solutions to our problems that are acceptable enough over building
  our own solutions simply because we want to. For example, a standards-based
  protocol, like , that allows
  clients to craft their own queries with little to no server-side updates is
  preferable to our current bespoke solution.

* Be documented and supported. Our choices should have active, helpful, and
  inclusive development communities built around them.

Therefore we seek to evolve the current implementation so that it helps,
rather than frustrates, our ability to adhere to these principles. Complex and
incorrect business logic will be simplified and tested. Custom built
components will be replaced with better alternatives.

Our alternatives are:

* Rum, 

  Rum is a solid piece of software, created and maintained by @tonsky, that
  provides a minimal wrapper around react for creating client-side components,
  and supports server-side rendering. Although rum does not provide a protocol
  between client and server, nor a client component state-management solution.

* Reagent, 

  Together with Re-frame, , this is by far the
  most popular choice for building reactive client components in
  Clojurescript. These do not include the server-side solutions we need.

* Hoplon, 

  Hoplon was created in-house at AdZerk, and later spun-out as an open source
  project. Hoplon is a complete solution although it uses a less intuitive
  spreadsheet-like method for building applications with little obvious
  advantage, and would not be compatible with Datomic without considerable

* Luminus, 

  Luminus is a complete solution like Ruby-on-Rails, and is tightly coupled to
  SQL. Like Hoplon, Luminus would not be compatible with Datomic without
  considerable effort.

* Pedestal, 

  Pedestal is supported by Cognitect, the custodians of Clojure and the
  creators of Datomic. Except Pedestal is best suited for building server-side
  APIs, and applications that need to stream data in "near real-time" to large
  numbers of concurrently connected clients.

* Fulcro, 

  Fulcro is based on Om.Next, provides both front-end and back-end components
  that work well together, includes tools for building and debugging both,
  supports server-side rendering, and is supported by a diverse
  community. Paid commercial support is provided by the core developer team at
  Fulcro Logic.

* Datomic Cloud, 

  Datomic Cloud is a special version of the Datomic database that is tightly
  integrated with AWS. Datomic Cloud includes a set of Cloud Formation
  templates for running Datomic in AWS, and taking advantage of AWS specific
  features, such as auto-scaling groups and load-balancers for distributing
  traffic across a cluster of Datomic peers. Datomic Cloud also includes Ions,
  , to help run Clojure functions
  as AWS Lambdas. Cognitech claims Datomic Cloud is a suitable framework for
  building complete applications. Unfortunately Datomic Cloud alone is
  insufficient. Datomic Cloud lacks a framework for building and testing
  client-side applications, and a protocol for interacting with Ions.

👍 1

Did you decide fulcro on the end? Did you think about re-frame?


Yup, we went with Fulcro (and mount and pathom). I'm pretty happy with it so far. I built a commercial product based on, reagent, and re-frame right around the time was introduced and it looked a lot like Fulcro in the end. I like reagent and re-frame, but I really did want a solution that was "more complete" - without looking like Rails or Django.


yeah, my experience as well. picked up fulcro, liked it but felt like it was ‘too much’ put it back down, went with re-frame, theen realized that all the helpers I’d written for db organization, api access, etc were a hacky fulcro-lite, picked fulcro back up lol

👍 1

ok I got an asnwer: fulcro is FE only now. I remember it as BE and FE solution. So I am fine with this.