The last is the easiest for porting and the least confusing re. versions. But gives RAD library users little choice but to port to stay up to date with RAD. Compared to using straight Fulcro Companies using RAD have already chosen to be innovators. If so perhaps they can handle the 'breaking changes' of moving to Pathom 3 if want to stay up to date.

Looking through the code there are only really 3 things RAD does with pathom: Generates resolvers, generates mutations, adds things to the env. The parser generation adds in a few little things that are now mostly jsut standard parts of Pathom 3. It does not look terribly difficult for users of P2 to port to P3, but looks can be deceiving. Very subtle differences in behaviors can be tough to spot, and the error handling is significantly different in 3. There are many portions of RAD that have nothing to do with Pathom that are usable even if you don’t use RAD’s back-end support. Users that don’t use a back-end based on Pathom won’t care. They can just upgrade. Those using a P2 back-end will have a lot of hand-written resolvers and such that will need to be ported. Fortunately, I think 95+% of resolvers and mutations will be trivial to port, and the generation of the central “processor of EQL” is a relatively focused task. In my projects it’s mainly the differences in error handling that give me the most pause, since those paths are typically nowhere near as well-tested as the happy paths. So breakage might be there that doesn’t even get noticed until a real release to users, or even much later. So, porting definitely should not be treated lightly, but I tend to agree that I’d personally rather leave the baggage behind. That said, since there are really just 3 things the RAD libraries do with Pathom (beyond generating the “parser”), it is probably not too difficult to make some kind of Pathom interfacing that allows either version of that library to be used with the vast majority of existing RAD code.

The “guts” of those three things is identical across both…it’s just the external API that had changed.

AH, I think it is possible that almost everything I’m using from Pathom 2 results in maps. Resolvers and mutations are just maps with namespaced keys in Pathom 2. The env plugins are also just maps. So, that actually makes it possible (I think) to drop Pathom 2 as a dependency on the database plugins and such, leaving only one namespace that has to explicitly refer to P2: The main rad pathom ns that acutally builds the parser. So, I think I can switch RAD to list Pathom as a “provided” dependency, and make a pathom3 namespace to go beside the legacy pathom one. As long as you don’t require the one you don’t use, then it might be possible to only have one on the classpath.

OK, I made a decision, at least for now, which turned out to be rather easy to implement: I’ve removed all need for Pathom 2 from RAD Datomic just by re-coding everything as plain maps. The base RAD library now only refers to Pathom 2 from the pathom namespace, and I can switch that to being a “provided” dependency. That makes it possible, at least, to remove pathom 2 from your deps while still requiring almost all of the namespaces (sans pathom.clj). I can now add a pathom3.clj namespace that implemnts the p3 stuff. The other database adapters will need similar treatment, but it’s pretty easy.

The env augmentation I turned into a middleware pattern, which was bw compat with the pathom 2 plugins (which again are just maps)…and pathom 3 just lets you pass the env on invocation, so having a function that can augment the env as middleware makes the existing stuff reusable that way

@UHA0AQZ2M You may want to check the pattern I’m using (e.g. in the attributes ns. see wrap-env and the change to the pathom plugin) for how I’m dropping explicit dependency on Pathom 2. See also resolvers.clj for changing autogen resolvers to not need explicit dependency.

@U0D5RN0S1 you want to take this https://github.com/fulcrologic/fulcro-rad-kvstore/issues/1 ?

Yes sure I'll be able to do that. Not immediately but soon enough.

I am early enough in my MVP devvelopment to upgrade to Pathom 3, so I am in favor of the replacement. I would love to help out, but I am swamped right now.

no help really needed, but would love feedback on how it works. I really only have to write 2 things at this point (I think): A new ns for p3 that builds the processor for you, and an adapter that can take a p2 resolver/mutation map and turn it into a p3 mutation/resolver, which looks to be trivial.

and then I’ll upgrade the demo and make sure it works there…the error handling will probably be the biggest thing to get exactly to match internal expectations…but that’s the unhappy path and usually written generically.

Thank you @U0CKQ19AQ!

Sharing @U0CKQ19AQ’s post from earlier today in #announcements, for visibility in this thread https://clojurians.slack.com/archives/C06MAR553/p1637252389403000