I usually end up in pieces when writing it…does that count?

yeah, homophones always count

I heard that “clojure” is homophonic…

ah neat how are u finding lacinia/graphql? I’ve used it a little and found it to be quite nice

(ah sorry missed the thread: I haven’t used it in depth yet since wrong language at the moment)

How many mutations did you have out of interest?

Also did you use / get working graphiql?

We did get graphiql working, although I can't recall if we had any issues doing so

ah ok cool. I had some error with input-objects and never had the time to look into why it didn’t work

In terms of mutations, the system in question has (It's a legacy DB, that we were looking to build a new API on the front of to replace the existing XML one) about 60 object types, with a given object's data being spread over anything from 1-5 or so tables (nested lists of sub-objects) and objects being able to be related to each other etc

The read API was really nice and Just Worked using the schema we defined for pretty much everything. We got up to the first 2 or 3 objects for the write API and it was already confusing, so we dropped the idea

ah, i can see why that would start turning into a big mess. I think for the javascript clients i’ve seen you can separate schemas for different aspects of the code base. But so far with my experience with lacinia we just ended up having one edn file. Did you have just one big one? or did you try splitting them up as well?

We just had one big one

ah yeah even more confusing

It wasn't the schema, so much as the code

oh really?

I found having separate resolvers to make it quite easy to separate and manage

but we only have like 10-12 mutations

So scale wise its much smaller than yours

>with a given object’s data being spread over anything from 1-5 or so tables I guess this is why it became super complicated?

With the read schema you could define all the lower level objects and define their relationships to build up the higher level objects, and that matched how clients wanted to read things and meant mostly the schema defined what they could query and how, with code only doing very basic lookups at the lowest level.

yeah

With the write schema we never managed to make it do the same thing. We were effectively implementing in code the same sort of logic that the schema gives you 'for free' on read.

ok gotya i understand, thanks!

Plus of course on write you have questions like "If fields are optional, and a client doesn't provide it when updating an existing object, does that mean it should be nulled out, or just left with whatever the current value is?"

In XML it's easy, you have to provide all or nothing. But the whole point of graphql is you only ask for (and provide?) the bits you care about

But that was actually a smaller side issue

Yes i never figured that one out either

but for the type of data we used it always had to have some sort of value

well actually re-reading ur comment

if u wanted to update ur user object, we only updated the fields you sent

So you could effectively never blank out all your fields if that makes sense?

Oh yeah, but sometimes you want to blank a field. Like unsetting a parent/child relationship

And in the XML API you do that by just not providing the <parent> element, so clients kinda expect that

I think i would guess that the graphql way would be to have a separate mutation for removing that parent/child relationship

But in graphQL maybe you'd have to provide the key, but with value null? But then you have to know whether the key exists to unset

Possibly

But our objects are really quite complex. There might be 10-20 relationships like that per object type. We didn't really want to create separate mutations for all of them. The idea was to provide a simpler API than the XML

To me it “felt” like you are supposed to separate a lot of functionality into basic mutations which do maybe one or two things. That way you could start calling them one after another. Thats why i believe mutations are sequential. But i’ve had limited experience really.

Yeah exactly

I can totally understand your viewpoint haha

Yeah, you're probably right, and if the API was designed from the start as graphQL maybe that is how it would have been done

yes totally, i found that to be the case as well.

But for some things it's not valid to create those small mutations separately

Like, some things may have to have a parent, so the base object creation should fail if one is not set. But in other things it's optional

I’m going to still investigate more about graphql i reckon. I’m going to look into the more popular js libraries to get a better understanding of what is possible. + reread the spec again. I really enjoyed developing with graphql/lacinia but am pretty much just self taught so its been a bit tricky

👍

For read it was brilliant. I'd definitely consider it if we wanted to provide a read-only API to data

Theres also interesting aspects like having an ID that works across mutations/queries so you can resolve in the object is the same across different calls and things. Like the actual graph aspect of it. I read about it one time but never really found out more 😭

yeah my experience was similar in that I found read to be chefs_kiss.gif but write was a lot more involved

was only a proof of concept hack anyway, but I wasn't sure if I'd have taken it further

I like that it's giving you the query and the documentation though, so it's like a turbo-charged combo of both REST and OpenAPI/swagger

I'll be interested to see how schema stitching develops, and whether that will fit easily with Lacinia.

yeah at least they use plumatic/schema, which in my experience is quicker to stitch together

damn i would love to be able to do that!

How did you negotiate that with your employer?

I’ve always been quite daunted about asking for a 4 day week 😞

I just asked 🙂 It helps that my wife works for the same company, and it was a combo of her going back to work, and me dropping down to 4 days.

ahhhh ok cool. Thats true, if you don’t ask you don’t get. OK i’ll be braver next time :thumbsup:

My internship was half-time (because I was also full time uni student), after which I transferred to a 4 days-worth week, specifically because I asked

(also found myself more efficient this way, although I worked to 5 days, just shorter workdays)

what I also found was that it killed my career at that place, ie people from the same cohort got promotions and I didn’t because I was a part-timer.

so, ymmv but be careful about side-effects.

Yeah i’m thinking of working 4 days a week because of my kids really. I don’t mind a pause in career if i can have a better family Quality of life

If you’re male, it probably helps; at the same place I knew an older woman, a working mother who also transferred to not-full-time in order to have more time for her kids, and she got sidelined into non-contributing, busywork projects. (It’s possible they thought I was going the same route and my ask was an indication of me going off on parental leave soon.)

It’s all tradeoffs and dealing with people’s preconceptions.

Sure sure

thanks!

I’m waiting for my youngest to stop the whining phase….. 19 years and counting…might be onto a losing proposition!

np 🙂 good luck with getting a good arrangement, time with family is extra valuable

Oh: also working at a place for some time before asking seemed to help (ime) with negotiating custom arrangements. I’ve done a period of remote work for a company that officially didn’t have remote work arrangements at the time. Perhaps managers want to see that you can function in normal conditions, and are happy to relax afterwards.

Yeah - I've been at ThoughtWorks for 7 years so have a certain amount of good will there! Also as a company we are working hard to be more family friendly. It's tricky as so much consulting involves travel, but at least we are working on it.

if you just want YYYY-MM, do you know that there’s a YearMonth class in java.time ?

eg. (take 3 (iterate #(.plusMonths % 1) (YearMonth/parse "2018-05")))

I ended up with

(defn months-seq
  ([start]
   (map (fn [x] (t/plus (t/zoned-date-time start (t/zone-id "UTC"))
                        (t/months (* 1 x))))
        (range)))
  ([start end]
   (take-while #(t/before? % end)
               (months-seq start)))
  ([start end fmt]
   (map #(t/format fmt %) (months-seq start end))))

working with year-month is probably better

I think there’s a wrapper in c.j-t

there is for some of it

struggling a bit to format the year-months back into strings

ok, yyyy-MM rather than YYYY-MM then

now it is:

(defn months-seq
  "Takes t/year-months like: (months-seq (t/year-month 2017 7) (t/year-month) \"yyyy-MM\")"
  ([start]
   (map (fn [x] (t/plus start
                        (t/months (* 1 x))))
        (range)))
  ([start end]
   (take-while #(t/before? % end)
               (months-seq start)))
  ([start end fmt]
   (map #(t/format fmt %) (months-seq start end))))

after I figured out I was specifying the format wrong (and it was looking for days of the week)

(* 1 x)?

so that I can do a range of months starting with the start date (add 0 months)

changed it again as I want it to be inclusive of the end

(defn months-seq
  "Takes t/year-months like: (months-seq (t/year-month 2017 7) (t/year-month) \"yyyy-MM\")"
  ([start]
   (map (fn [x] (t/plus start
                        (t/months (* 1 x))))
        (range)))
  ([start end]
   (take-while #(t/before? % (t/plus end (t/months 1)))
               (months-seq start)))
  ([start end fmt]
   (map #(t/format fmt %) (months-seq start end))))

(comment
  (months-seq (t/year-month 2017 7) (t/year-month) (t/formatter "yyyy-MM"))
  ("2017-07" "2017-08" "2017-09" "2017-10" "2017-11" "2017-12" "2018-01" "2018-02" "2018-03" "2018-04" "2018-05"))

I don't get the (* 1 x) part -- when is that not equal to just x?

@U04V70XH6 you'd be right of course. I should maths more.

Ooh, I might have something by then in that case

THIS x 1000

OTOH the parens are like walls around our sacred code protecting it from those that would judge a book by its cover

the problem is that many would be excellent developers are insulated from a beneficial exposure to s-expressions by the cloud of baseless derision generated by all those with unthinking attachments to semicolons