Jint VS Polly

Jint https://github.com/sebastienros/jint

There are quite a lot of ways to run scripting languages in C#. I've no idea what JSR223 is but .NET has DLR for example. There are also multiple libraries: IronPython, NLua, Jint and Jurassic for Javascript. There's also older version of CS-Script working with .NET Framework.

You can. Embeding lua is a trivial task, and I'm reasonably sure there even are plug-and-play solutions for that, and for JS there's JINT.

I personally use Jint (a multi-platform Javascript interpreter) since Roslyn is not available on mobile. It basically has the same kind of functionality as Roslyn, but it's JS. JS is well-known and accessible to everybody, but Roslyn might be faster since there's no double indirection when interpreting the script. It also depends on what language your users are comfortable with or could learn easily.

Ah yeah, I looked into it more and decompiled the game to find that it appears they're using Jint to interpret the Javascript, and from testing with someone's REPL BBS server I can find that it's a pretty well isolated environment. Only ways around it I can think of are by exploiting some vulnerability in the sandbox to do external requests, modding the game itself to update the api, or running a parallel server to do some janky communication through the save state data.

We used https://github.com/sebastienros/jint for scripting, it's ES5 JS implementation.

Jint is a JS interpreter with an integrated engine built in C#, like V8, he is responsible for all the base code execution as well as EcmaScript implementations such as default constructors, syntax, Promises... I studied its features in depth to start and it was a bit hard (in the beginning).

MelonRuntime is based on Jint, a JavaScript interpreter created by Sébastien Ros, software developer in the ASP.NET team at Microsoft. Melon works from bindings and functionalities injected into this interpreter together with external typing (provided by another package that comes with the default project generated by the command npx melon new) and built-in tools.

In our applications, we should wrap all requests to remote services in code that implements a retry policy that follows one of the strategies I listed earlier. If you are a .NET developer like myself, you may be familiar with the Polly library. Golang has a library called Retry, and there are numerous third-party libraries for Python and Java.

Another question that rises is, would it be better to use some HttpClient package to handle the requests, like Refit in combination with Polly. But then again, it seems Refit also uses the HttpClient factory, which was a bad thing according to the previous?

D'Oh! Sorry, not PolySharp. I meant Polly. Too many similarly-named libraries!

Everywhere I've worked with AGs, we've worked with the application team to add retry logic to help make things a bit more seamless to end users. There are libraries out there that can make this pretty easy - Polly is one that I've used a few times, but there are others.

Fallacy 1: The network is reliable. If system 2 works perfectly well, but is not accessible for service 1 due to network issues, service 2 is still unavailable. This is why timeouts, service breakers and retry policies exist. A great tool for .NET to handle common network issues is Polly, but even when using a tool like this, the network is still not completely reliable.

I see. Then I don't have any better idea right now, but I do want to suggest that if your script is mostly API calls and you want to be able to deal with failures then take a look at the polly library: https://github.com/App-vNext/Polly

Runs in containers nicely, has good integration with Kafka, RabbitMQ, gRPC, etc. for Microservices communication. Implements resiliency patterns you'd want in Microservices via Polly. Has a decent Dependency Injection framework built in by default.

It's in no way hidden. But I use Polly all the time.

Depending if the sender or the reciever is down, you can also try Polly http://www.thepollyproject.org/