Mocking

So I needed a Ditto to mock some object in a frontend application. The reason for this was I just wanted to mock the entire library and so whatever would be called in whatever order would also return a Ditto as to make it possible to chain ridiculous things like Ditto.a.b.c.d().f and it would work and return a Ditto.

The way you do this is to use a Proxy object in JavaScript. What it does is you provide a target and a handler which means you can intercept and augment some behaviour. For example a simple audit log as to who touched what objects, or maybe click behaviour or even as a form of Synthetic Monitoring. You could also make objects immutable with this behaviour as it would be when you freeze or seal objects.

Target

The target is whatever object you want to add the behaviour to. It can be a function or an object.

Handler

The handler holds the behaviour you want to want the target to obtain. So on an object you can specify a get key with a function that will be executed on getting an object. You can also set an apply key which will be executed on calling a function. There are several others you can call, even adding behaviour to when new gets used.

Ditto was born

The following piece of code creates a Ditto.

const Ditto = new Proxy(() => {}, {
    get: () => {return Ditto;},
    set: () => {},
    apply: () => {return Ditto;},
});

What it will do is on getting a property you will return the Ditto. On setting a property nothing will happen. So it will not be stored. Then when you execute the Ditto on any property it will return a Ditto.

#code #javascript

var greetings = {
 hello: function() { console.info("Hello"); }
};
greetings.hello();
greetings["hello"]();

This is how functions could be shipped around. So the idea is simple, especially the second one. I started to wonder if we can have a Map of String -> Function in other languages like Java, Python, PHP and more?

Java

We sure can. I was working on a JSON-RPC project where you don't send entity bodies but you send what method to invoke and with what arguments. In the backend we made it so internally a consistent object was shipped around (RPCServiceResult) and we had Enum for the methods that were allowed. So I set up an EnumMap of Enum -> Function. This made it so the entrypoint of each service was the same. See if the method key exists, if so execute the corresponding function with the given input otherwise throw a MethodNotFound error. This meant we could extend the Enum and EnumMap and the Function mapping but never had to change how the services called each other.

Python

In Python I was working on a silly hacking simulation game in the Console. I wanted to have a list of commands and execute the corresponding function that was that command in game terms. At this point I just came from PHP and there it is completely normal to execute the string itself. I will come back to this in a bit. This is more difficult to do in Python and so I came up with a dict where command name was the key and function references were the values. This made it super simple to maintain.

PHP

So in PHP this is normal:

function a(){ echo "A"; };
$a = "a";
$a();

However it is really difficult to maintain and see what is going on, let alone insecure to do this if the input to $a is user input. The following makes more sense and is easier to maintain.

function a() { echo "A"; };
$commands = ["a" => function() { call_user_func("a"); }];
if ( array_key_exists("a", $commands) ) { $commands["a"](); }

Granted this is a contrived example but I hope it gets the point across.

Scala

I was working on the Advent of Code 2020 and one of the puzzles had a lot of validation rules. Immediately the structure came to mind of having a Map of Functions, for each field to validate the corresponding function. This worked like a charm and it is very easy to see what each rule does.

Java

Another example was that in a particular flow there was a need to either create a User of type A or type B and then continue the flow. It was first like the following:

if ( type == "UserA" ) {
    return new UserA();
} else {
    return new UserB();
}

Now never mind the bug of always returning type B, I suggested the following:

Map<String, Supplier<User>> userSupplier = new HashMap<>(){{ put("UserA", UserA::new); put("UserB", UserB::new); }};

Now you could replace it with one entrypoint:

return userSupplier.getOrDefault(type, UserB::new).get();

You still have the bug, but it became a feature. So we leave it in. The colleague immediately said, this happens in way more places in the code and I can change all of them.

The nice thing again is, we can extend the map to support more types but it does not change the logic of calling the service.

Conclusion

I hope this concept proves useful to you, I find it quite powerful and easy to construct and it gives lots of nice patterns.

#code #javascript #java #python

I just have one thought/question; why?

Why indeed

Well it seems like more and more was pulled into the frontend as time passed on, mainly to free up the backend to do the real processing. Like number crunching, data processing and so on. Which makes sense, but now it is weird to say the state of an application should be as close to the user as possible. Also servers are now more than capable of doing both work, and therefore the natural conclusion is that since most of the things were in the frontend anyway now; why not move the whole thing to the frontend?

The thing is that it makes the codebase more difficult to manage, you introduce unwanted complexity let alone making it secure. The whole codebase has so many extra dependencies and vulnerabilities since a lot of Server Side Template Injection (SSTI) plague the landscape now and have been fixed/found already in the old backend languages.

Of course it seems convenient, but let's take the data models that you want to use. You define them either from the frontend perspective or backend perspective first. In the frontend you might only want first name and an e-mail address, for example. Then in the backend you want to have maybe something more than just first name and an email address. How about a password to login? Or a session id, or maybe just an id in general for the databases so you can store multiple combinations of people? Then you have to transform schemas or build them differently. So you get views or something equivalent and suddenly everything is back to this again.

I would steer away from having the whole application in one language with one library/framework since nothing so far checks all the boxes and covers all the bases.

#100DaysToOffload #frontend #JavaScript #devlife