This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-05
Channels
- # adventofcode (138)
- # announcements (1)
- # babashka (4)
- # beginners (71)
- # biff (2)
- # calva (7)
- # cider (20)
- # clj-kondo (4)
- # cljsrn (4)
- # clojure (36)
- # clojure-europe (37)
- # clojure-nl (2)
- # clojure-norway (27)
- # clojure-portugal (1)
- # clojure-uk (4)
- # clojurescript (8)
- # emacs (3)
- # graphql (1)
- # hugsql (4)
- # humbleui (6)
- # hyperfiddle (1)
- # jobs-discuss (18)
- # joyride (2)
- # malli (17)
- # meander (7)
- # membrane (8)
- # off-topic (16)
- # pathom (14)
- # portal (4)
- # rdf (36)
- # reitit (4)
- # releases (2)
- # remote-jobs (1)
- # scittle (15)
- # shadow-cljs (13)
- # tools-deps (40)
Say I have an established path for getting :x
. Now my application is evolving, and I have a new way of getting :x
. How should I evolve my application? Options seem to be:
1. replace the code getting :x
using the old way
2. add new resolvers which also get :x
, but give them a higher priority
3. give :x
a different name when it's retrieved using the new way
4. create a new wrapper route, like [{:new-path [:x]}]
5. change the old resolver by adding a new-way?
param
6. something else?
Then i would just remove the old resolver. It should be transparent to clients if input and output are the same.
What if the old resolver may still be useful in some limited circumstances in the future and I don't really want to completely lose it?
I kind of want to keep the question abstract. But let's say they are both ways to calculate a product, but the new way is more efficient. Maybe I want to use the old one to be able to compare old VS. new performance.
In that case I would give it a new key where it's clear that it's been replaced so you don't accidentally pull it in unless you really want to for performance checks, etc.
That makes sense but I've seen it repeated many times that you should never change the meaning of a name.
hello @UPWHQK562, its right that we should aim to keep the semantics of the name consistent, but you can change the implementation as much as you want, as long as the name keep its meaning, being able to change the impl is a design goal of all of this 🙂
if you want to write test to compare old vs new impl, you can have one env
with the old, and one with the new, this run you can run the same queries and compare the results, given everything else other than this resolver is being replaced
How I understood your criteria: From the outside clients perspective, they want :x
(don't care about implementation). From the inner developer perspective, you may want to differentiate performance/implementation/etc.. but "not always".
I would actually move the original implementation into a new key :x-1
and the new implementation into :x-2
. Then have :x
resolver dispatch to :x-1
or :x-2
(maybe always to the new one, maybe via feature flags, or maybe totally dynamic 🤷)
Client always sees :x
and the internal systems may ask for generic :x
or more directly for :x-1
or :x-2
. Probably would be good to choose names and namespaces so that you know that the latter are specific implementations of the former, but if it's important to your domain (and your internal systems/developers are just more "clients" of your API), why not just use the existing EQL machinery to name and identify that this is an important distinction for you?
Thanks for the thoughtful take, @U05476190. That does indeed cover it well. Considering that the developer may have a different sense of "meaning" and that the model should accommodate for it in some way adds an interesting layer. From that perspective the implementation is part of the meaning of the thing. And why shouldn't the developer be included as a class of user? The developer probably uses the thing more than anyone 🙂 I love that there are so many ways to interpret and represent data requirements through attribute modelling. There's so much art to it.