Clojurians
#onyx
<
2016-02-09
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

gardnervickers01:02:00

@sirsean: that's perfectly valid, I just prefer to replace Kafka/MySQL with core-async and regular in memory datastructures

sirsean01:02:11

Like, for dev mode?

gardnervickers01:02:05

I wouldn't do it like that because I find Kafka too heavy and difficult to manage for dev mode where you want to iterate quickly

gardnervickers01:02:15

But it's supported

gardnervickers01:02:02

It comes down to in my tests I would not want to have to manage external infrastructure

sirsean01:02:08

Oh certainly, running Kafka locally would be too big of a pain. That’s kind of why we were thinking of “only running via Compose”.

sirsean01:02:43

So our tests would cover our functions that do work, rather than exercising the Onyx infrastructure.

gardnervickers01:02:51

That's fine too, it might get tricky if you want to test your assumptions about the Onyx specific features like flow conditions, state/aggregation etc...

sirsean01:02:45

Hm okay. Thank you! That’s exactly the sort of “doing it that way is going to cause me a lot of pain later on” advice I was looking for.

sirsean01:02:53

:simple_smile:

gardnervickers01:02:51

Can I ask what drove you to wanting to do that? we are actively trying to simplify the template, were any parts confusing at first glance?

sirsean01:02:08

Well, a big part of it is that when we backported the new Kafka stuff in the latest version of the template into our project (thank you for that), our code coverage dropped by 25% and it just seems like most of this code is Onyx Dev Mode Stuff that doesn’t necessarily do anything for us? So we’re trying to move toward having dev and prod being as similar as possible, including running the same way inside Docker, and focusing on tests for each step of the workflow to make sure they’re doing what we expect.

sirsean01:02:28

(I hesitate to answer the “were any parts confusing” part of that question, because I’m not familiar enough with Clojure to answer that confidently. I’m at the point where I understand smaller functions and then there’s just some insanity that, while obviously powerful, I don’t understand. So sure there were confusing parts :stuck_out_tongue_winking_eye: but that’s probably on me.)

gardnervickers02:02:16

Gotcha @sirsean thanks for the input.

gardnervickers02:02:41

If you’re fine with setup/teardown in your tests, or write your tests in such a way that you can avoid that, its perfectly valid to just use :prod. If you checkout the way we use regular functions to transform the job map, modifications to that will still apply to your job-map no matter how you construct it initially. Hopefully that addresses your concerns around backporting

lucasbradstreet07:02:53

@sirsean: I understand what you're saying. I prefer the dev mode tests to allow for quicker test turn around time - but it does have some overhead

michaeldrogalis15:02:42

Almost feels like we could make a --in-memory-io switch for the template. Sometimes you'd want core.async for dev mode, sometimes not. Just a thought.

lucasbradstreet15:02:46

It’d have to strip out or stub a lot more things, like the tests

lucasbradstreet15:02:53

That might be OK though

robert-stuttaford16:02:15

do you guys ever sleep?

michaeldrogalis16:02:03

Oh yeah, solid 8-9 hours a night :simple_smile:

robert-stuttaford16:02:33

great work, folks!

adebesin16:02:46

You sleep when your dead.. :simple_smile:

robert-stuttaford16:02:44

or when you reach 1.0? :simple_smile:

michaeldrogalis16:02:09

Whichever comes first, haha.

lucasbradstreet16:02:28

@gardnervickers: I added the better way to structure tasks to onyx-template for core.async input/output https://github.com/onyx-platform/onyx-template/blob/master/src/leiningen/new/onyx_app/src/onyx_app/tasks/core_async.clj#L44