Wanted: spryker-like approach for a self constructed middleware scenario


#1

I am on experimenting with Spryker middleware and construct a practical scenario by myself to have a better learning experience.

My constructed task: Convert some customer data through a typical spryker middleware pipeline from a csv file as input to a json file as output. During the process some real data (like name) should be anonymized/exchanged by fake data.

My approach is to use the translator step to anonymize the data. I couldn’t find a suitable default translator function so i decided to implement my own. It’s called simply “anonymize”.

It is working so far that every column/key that has this anonymize function applied is returning the corresponding “anonymized” value.

Look at the following class

class Anonymize extends AbstractTranslatorFunction implements TranslatorFunctionInterface
{
     /**
     * @param mixed $value
     * @param array $payload
     *
     * @return mixed
     */
    public function translate($value, array $payload)
    {
        return "anonymous";
    }
}

As you can see, this is not really a practical use case to return simply a never changing string. To improve that i would like to add something like a faking service.

My naive approach is the following:

As a fake library i would use the already included fzaninotto/faker library which itself provides a simple factory class for creating different fakes like names, telephone numbers and so on …
To get it in the place i need, I would add dependency injection via constructor in the translator class above. The faking service itself is created by the BusinessFactory and provided by the DependencyProvider.
Somewhere in the DependencyProvider i would simply do a “new fzaninotto/faker/factory()”.

Like i said. This is a very naive approach. The most unideal fact is the unflexibility of the used faking implementation, that can not be changed in future if you start using some methods of it.

My next thought is to wrap it in something that is not dependent on the concrete implementation (like $fzaninottoFaker->generateName()) but rather on an interface or similar (FakeInterface->generateName()).

Until here. Now i don’t know what can be a typical approach to solve this in a “spryker” way. At the moment i am to confused about possibilities and terms … plugins, services, bridges … i don’t know where to put that stuff at all.

It would be very useful to have this available at other places too.

So … what can be a good approach/good practise to realize this? Is doing it that way in the spryker middleware a fail at all? Maybe creating a service and get it via the service locator?

Many thanks.


#2

Hi!

The approach is is pretty valid imho!
The proposed solution of the the abstracted away functionality is a role-model case for a new module, like in the bonus task for the StringReverser in the Spryker Bootcamp at https://training.spryker.com/!

When you want to make it available to more multiple namespaces, then you might consider moving this into the Service namespace.

Please keep us up-to-date on how the proof-of-concept is going! :+1:


#3

@lazystar

Many thanks for your response. I put this tutorial on ice since i didn’t find a suitable solution at this time, but i will give it a try again.

Is it generally a good idea, to provide a often used functionality as a service? I remember to read somewhere that services shouldn’t be overused …

Best regards