Am I Using Ox Correctly?

[objektwerks]

I've been following Ox since its inception: https://github.com/objektwerks/ox

I recently added Ox to this project: https://github.com/objektwerks/house

See: Endpoint, Dispatcher and Handler.

Am I using Ox correctly in this app?

Any comments would be most welcome. Otherwise, I'll assume I'm an Ox genius. ;)

[objektwerks]

Am I the only one using Ox? Gosh, I sure hope not. :)

I've refactored my above house project to minimize Ox exposure / usage.

To do so, though, I had to use IO.unsafe directly in Dispatcher.

Otherwise, using IO would have threaded itself through Handler and Dispatcher.

And the Ox docs recommend against using a class constructor to pass using IO.

Yet IO.unsafe hides the classic using IO from entry point method signatures.

For instance, def dispatch(command: Command)(using IO): Event = ... is replaced with:

def dispatch(command: Command): Event =
  IO.unsafe:
    command.isValid match
    ...

...
Any comments, confirming my choices, would be most welcome.
...
Can the Ox plugin be enhanced to output useful info on IO usage and the like?

[objektwerks]

By adding a Tapir endpoint and removing the Helidon server, I was able implement the ideal Dispatcher with:

def dispatch(command: Command)(using IO): Event = ...

Yet, I was unable to add required Schema(s) to implement Jsoniter support for my Tapir endpoint. Nothing worked.
...
And that closes my experiment with Ox and Tapir. Cheers! :)

[adamw]

Let me address these one by one :)

First - is anybody using Ox? no idea :) But I think it would be be to post usage questions to the forum, as not many people might be following new GitHub issues. Also, Ox is still an 0.x project, hence it might (and I hope it will!) experience changes to the API.

Secondly, your project:

• Endpoint - looks good, one thing I'm not sure about is what is Thread.currentThread().join() for? Is it for blocking indefinitely? If so, never might be better. Also, jdkHttpServer.stop(0) should probably be added as a cleanup step, before blocking, using releaseAfterScope(jdkHttpServer.stop(0))
• Handler - why Try+recover instead of try-catch?

As for IO - I know it could end up being threaded through multiple classes, and hence a bit cumbersome to use. That's what I somewhat discussed here. However, if we want signatures that don't lie, the IO information needs to go somewhere. I'm still not certain on IOs future, though.

Can the Ox plugin be enhanced to output useful info on IO usage and the like?

Probably, but you'd need to write more on what you exactly mean by that :)

Yet, I was unable to add required Schema(s) to implement Jsoniter support for my Tapir endpoint. Nothing worked.

Some more details would be needed here - what kind of error messages did you get, and what did you write in code.

[objektwerks]

Thanks for the reply, Adam!

Sorry, I don't do Discord; hence my post on Github.

Using Thread.currentThread().join() blocks the main thread from exiting and shutting down the JdkHttpServer. It works fine as is; but I added a sys.addShutdownHook { ... } block for a more elegant look. ;) Some of Tapir's other http server options are more sophisticated and don't required this technique.

As for Try: recover:, I suspect it's a habit vis-a-vis Try: catch:. I see your point, though. :) Thanks!

No worries on IO. I understand Ox is in flux. I was just trying to follow the docs. And I'll adjust as Ox evolves.

I was thinking the Ox plugin could print out any and all IO relevant information useful to developers. I figured you and your team might have some ideas. :)

I wrote my thoughts down on Tapir here: https://github.com/objektwerks/house/blob/main/README.md I wouldn't read too much into it. My experience with Tapir is quite limited. And the old-school approach works just fine.

Thanks, again, for your time. Cheers! :)

[adamw]

Sorry, I don't do Discord; hence my post on Github.

I also dislike Discord ;) The forum is Discourse - something quite different.

Using Thread.currentThread().join() blocks the main thread from exiting and shutting down the JdkHttpServer. It works fine as is

Ah ok. That's what generally never is for, but both do the job equally fine

but I added a sys.addShutdownHook { ... } block for a more elegant look.

That's also what OxApp is doing - adding a shutdown hook to release any resources allocated within the main Ox scope (the top-level one that is provided to the app)

Thanks for testing Tapir & Ox, if you would have any specific questions on the derivation problems, please open new threads / issues.

[objektwerks]

Ok, Adam, I just plugged in releaseAfterScope and never and Endpoint works as expected! I'm fully Ox-compliant, now! ;) Thanks!

I've located the Discourse SoftwareMill forum. I'll check it out. And, perhaps, I can get my Tapir schema issues resolved. ;)

Note: Via this project Sttp-Tapir, I managed sort out the schema derivation issue with Scala 3 enums --- which will require a fair amount of code for my House project. I'll resort to Discourse should I have max inline errors and the like.

Thanks, again, for your time! Cheers! :)