What about introducing a new microservice using gRPC ?

[agoncal]

@edeandrea had introduced a new Location Microservice that uses gRPC. What about introducing a new microservice ?

quarkusio/quarkus-super-heroes#394

[edeandrea]

The new service I added also is written completely in Kotlin :)

[agoncal]

Oh, I thought @cescoffier mentioned that there were some issues with Kotlin and gRPC. Did you solve them ? So we could do that also on our workshop. Could be interested to show Kotlin and gRPC

[cescoffier]

It works but it cannot use kotlin gRPC. So for kotlin developers, it is not what they would have done.

[edeandrea]

It doesn't use kotlin-gRPC.

@cescoffier is there a reason it can't? Is it just that our code generator doesn't include the kotlin gRPC plugin? Or are there bigger issues?

[cescoffier]

there are bigger issues. We would need someone with a deep expertise around co-routines and netty/reactive.

[holly-cummins]

I like the new service a lot, but I wonder how often we envisage teaching it in a workshop. We normally can't get through all the existing material, so "lack of material" is not a current problem for us. :) That doesn't mean we shouldn't add new content, ever - we want to keep the workshop modern and include the things that will get people excited. And length is less of a problem since we can make tailored workshops. Still, I'd want to be confident there's some demand for content before making the investment in the extra teaching material. "Because it's there" probably isn't a good enough reason to add it. @agoncal, do you see demand for it?

[agoncal]

Well, due to my focus on Java, I don't see a lot of demand on Kotlin... but yes in gRPC.

As @holly-cummins mentions, the workshop is getting bigger and bigger... but on the other hand, we know now how to have several flavours of it (thanks to guards and documentation generation) and we will also introduce #382. This will allow to totally skip developping the CORE of the workshop (Hero, Villain, Fight and UI) and focus on other technical areas. gRPC could be one.

[holly-cummins]

Well, due to my focus on Java, I don't see a lot of demand on Kotlin... but yes in gRPC.
allow to totally skip developping the CORE of the workshop (Hero, Villain, Fight and UI) and focus on other technical areas. gRPC could be one.

Ok, sold! :)

[edeandrea]

I'll just add a bit more here - when I was at JavaZone back in September it seemed that the vast majority (>= 80%) were generally using Kotlin and not Java regardless of framework. I'm not sure if its a Nordic thing or not, but Java was in the minority based on people and customers I talked to.

[holly-cummins]

Yeah, I'm just trying to envisage the flow here. I agree Kotlin is popular and Kotlin users are important. Like, if we want to target Kotlin users, would we really do it with one module in a workshop, that people actually won't get to most times we run the workshop? The workshop is different from a reference application, stuff in the workshop only counts if people do it.

It's a bit like having one vegetarian option on a menu in a restaurant, and it's usually out of stock (ie people don't have time to get to it in a 3 hour workshop), and all the starters have meat in them. It looks like you thought about vegetarians, but any vegetarians who come to the restaurant will usually end up having to eat meat-y starters, and then they won't even get to try the vegetarian food.

That kind of "maybe you will get to try a bit of veggie food, if you're lucky" offering would be good if there's not many vegetarians, and also for allowing meat-eaters to try vegetarian food. But as a way of catering to vegetarians, it's not good enough. So if we anticipate a need to run workshops for actually Kotlin users rather than Kotlin-curious people, is there something stronger and more satisfying we should be doing? I guess I'm trying to understand what problem we're trying to solve, beyond the low hanging fruit of "we have existing code that does cool stuff, we could incorporate it."