Forem: GF

Unlocking Istio's Versatility: A Guide to WASM Plugins in Kubernetes

GF — Mon, 24 Jul 2023 14:36:16 +0000

Introduction

In this article, I want to share my experience with Istio Wasm Plugin and how it helped me overcome the limitations of Kubernetes and Istio. While I am not a Kubernetes engineer, I had to gain some experience with it because our team works in a "develop, deploy, and support by ourselves" mode. Many times we ran into the limitations of Kubernetes or Istio (we use it for networking) or just wanted to do something different from common patterns of usage of these solutions. I'll discuss a solution that allowed us to dynamically route external client traffic to specific pods within the cluster based on their current load.

The Need for Dynamic Routing

Our Kubernetes-based backend system comprises multiple services and scales dynamically based on the number of clients it needs to serve (by the way our scaling is quite interesting as well, we had to write our own implementation of Horizontal Pod Autoscaler (HPA) because of existing one doesn't match our requirements of how exactly to downscale pods). For the performance and for some system features, we needed a way to route external client traffic to the particular pod within the cluster, by pod name. Although Istio provides powerful networking capabilities, we couldn't find a direct solution for our specific requirement.

Collecting Workload Information

We have an internal service responsible for collecting workload information from destination service pod instances. That service determines the least loaded pod and provides that information through HTTP endpoint.

Routing

The native solution for routing as we needed is destination rules (DR) and virtual services (VS). But as I mentioned above, we have that server scales dynamically and we need to route to a particular pod, hence since our server scales dynamically, we cannot rely on static DR and VS specifications, as we do not know the exact number or names of pods in the cluster at any given time we have to change these specifications dynamically. Our implementation of HPA which is responsible for scaling our service also became responsible for adding a new record to DR and VS specs each time we scale up and remove records once we scale down to keep everything consistent. So, now we can shoot requests in a particular pod assuming we know its name. Our routing is based on a query parameter in a request URL, which looks like "http://quite-interesting-service.com/some-path?podId=service-pod-b95fcf0d03-mjz8f".

Our VS routes look similary to:

 http:
  - match:
      - queryParams:
          backend3dWsId:
            regex: service-pod-1adbfcdd9c.+
        uri:
          prefix: /
    route:
      - destination:
          host: <service>.<namespace>.svc.cluster.local
          port:
            number: 80
          subset: service-pod-1adbfcdd9c
        weight: 100

And corresponding DR:

host: <service>.<namespace>.svc.cluster.local
subsets:
  - labels:
      job-name: service-pod-1adbfcdd9c
    name: service-pod-1adbfcdd9c

Client traffic

While we successfully implemented the dynamic routing solution, a new challenge arose: how would the client know which specific pod to request? There is the option - to ask our API and include the pod name in the request, but this would introduce an additional HTTP request and increase latency. So, we came up with the following idea - what if we intercepted incoming requests at the Istio ingress gateway and modified the client's URL by adding the required query parameter? This way, the subsequent routing would just work as intended and point the request to the necessary pod.
This is where Istio wasm plugins come into play.

Wasm plugin implementation

As far I understand Istio is based on Envoy. And wasm plugin is an Istio representation of Envoy filters. So, in order to work with wasm plugins I would recommend getting at least a basic understanding of Envoy architecture; there are some terminology it's good to be familiar with.

Take a look at Envoy terminology
Read more about Envoy clusters

Configuring Gateway Envoy

To allow our plugin to call our API endpoint in k8s cluster we need to add a new cluster in Envoy specification.

If you want to check your envoy spec on a pod, you can do ks exec -n <namespace> <pod name> -c istio-proxy -it -- bash and then http://127.0.0.1:15000/config_dump
Or ks port-forward -n <namespace> <pod name> -c istio-proxy 15000:15000 and check localhost:15000. There are a lot of things you can check or tweak.

To add the Envoy cluster to the specification, we can use an Istio Envoy filter. The following example demonstrates how to add a cluster:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: awesome-filter
  namespace: istio-system
spec:
  workloadSelector:
    labels:
      app: public-istio-ingressgateway
  configPatches:
    - applyTo: CLUSTER
      match:
        context: GATEWAY
      patch:
        operation: ADD
        value: 
          name: "clusetr-name"
          type: STRICT_DNS
          connect_timeout: 1s
          lb_policy: ROUND_ROBIN
          load_assignment:
            cluster_name: cluster-name
            endpoints:
              - lb_endpoints:
                  - endpoint:
                      address:
                        socket_address:
                          protocol: TCP
                          address: "api.<namespace>.svc.cluster.local"
                          port_value: 80

After applying that to a k8s cluster we will be able to call api.namespace.svc.cluster.local from our wasm plugin.

Installing wasm plugin

Yeah, installing before coding, but I think it's a reasonable chronology for a coding explanation.
So, spec will look like:

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: awersome-plugin
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  url: file:///opt/filters/plugin.wasm
  phase: AUTHN
  pluginConfig:
    upstream_name: "cluster-name"
    authority: "<service>.<namespace>.svc.cluster.local"
    api_path: "/pod-lookup"

Here we passed some params to the plugin config which we will use later.
Also, we will need to provide plugin.wasm file in containers with envoy on path we mentioned here.

Coding wasm plugin

It's possible to use a few languages for implementing wasm plugin. The following SDK are available now:

I like Rust, so I picked Rust :)

Before all, you need to install wasm toolchain:

rustup target add wasm32-unknown-unknown

SDK has pretty simple API as well, actually I like that whole wasm plugin expandable approach. Those SDK help you to implement Application Binary Interface which is understood by the Envoy.

Reading plugin config

First of all we might want to read some parameters we have passed to our plugin via yaml spec. It's a bit tricky, but to read passed configuration is allowed only once and you have to store params in your plugin because it won't be available in the future.

I would define a struct that represents params I passed to plugin and define my plugin:

#[derive(Default)]
struct Plugin {
    config: PluginConfig,
}


#[derive(Serialize, Deserialize, Default, Debug, Clone)]
struct PluginConfig {
    upstream_name: String,
    authority: String,
    api_path: String,
}

Reading plugin configuration is only available in on_configure:

   fn on_configure(&mut self, _plugin_configuration_size: usize) -> bool {
        if let Some(config_bytes) = self.get_plugin_configuration() {
            if let Ok(config) = serde_json::from_slice::<PluginConfig>(&config_bytes) {
                self.config = config;
            } else {
                error!("Can't parse plugin config!")
            }
        } else {
            error!("There is no plugin config for plugin!")
        }

        true
    }

And to be able to use that configuration in the future, we need to implement the following:

    fn create_http_context(&self, _context_id: u32) -> Option<Box<dyn HttpContext>> {
        Some(Box::new(Plugin {
            config: self.config.clone(),
        }))
    }
    fn get_type(&self) -> Option<ContextType> {
        Some(ContextType::HttpContext)
    }

It is the way to pass config for all further requests.

Dispatch HTTP call from inside wasm plugin

There are good examples in SDK's repos, so I just mention one feature which is not covered here. If you want to dispatch HTTP call from your plugin you can't do it just like in regular code, you have to use hostcalls API, wrapped and provided by SDK.
In my case I need to catch incoming requests in on_http_request_headers and call dispatch_http_call in order to perform HTTP request to API:

impl HttpContext for MyPlugin {
    fn on_http_request_headers(&mut self, _: usize, _: bool) -> Action {

        let http_call_res = self.dispatch_http_call(
            &self.config.upstream_name,
            vec![
                (":method", "GET"),
                (":path", &self.config.path),
                (":authority", &self.config.authority),
            ],
            None,
            vec![],
            Duration::from_secs(2),
        );

        if http_call_res.is_err() {
            error!(
                "Failed to dispatch HTTP call, to {} status: {http_call_res:#?}",
                self.config.upstream_name
            );
            Action::Continue
        } else {
            Action::Pause
        }
    }
}

Keep in mind that the first parameter is the name for a cluster we added with Istio Envoy Filter, "clusetr-name" in this case.

Good, but http_call_res is not an API response. It's just a result of call itself.
In order to get response for our HTTP call we need to set one more calllback:

 fn on_http_call_response(
        &mut self,
        _token_id: u32,
        _num_headers: usize,
        body_size: usize,
        _num_trailers: usize,
    ) {
        if let Some(response) = self.get_http_call_response_body(0, body_size) {
            let path = self.get_http_request_header(":path");
            if path.is_none() {
                error!("Failed to get_http_request_header");
                self.resume_http_request();
                return;
            }
            let path = path.unwrap();

            let response_string = String::from_utf8(response).unwrap_or("unknown".to_string());
            let modified_url = format!("{}?podId={}", path, response_string);

            self.set_http_request_header(":path", Some(&modified_url));
        } else {
            error!("API responded without body");
        }

        self.resume_http_request();
    }

After that patch, HTTP request will be matching our DRs and VSs and placed to the pod with the corresponding pod name.

Convenient development

Istio gives us three options to deliver wasm plugin binary into cluster:

As a file in a pod
As a file available through HTTP
As OCI image (it's possible to store binary file in AWS ECR, for instance)

In a production environment, you probably will use the second or third option, but for development purposes, I would pick the first. But it's available only in case your file is less than 1 Mb.
You only need to patch Kubernetes deployments in pods you want to apply the plugin to with a mount of config map to a pod file system (how to do that).

To be able to produce a wasm plugin binary less than 1 Mb you might need to add some options to your Cargo.toml file, like:

[profile.release]
opt-level = "z"
lto = true
codegen-units = 1

If you are able to fit the constraint I could offer you to use the following script for developing and debugging of wasm plugin:

cargo build --target wasm32-unknown-unknown --release
cp ../target/wasm32-unknown-unknown/release/url_patcher_wasm_plugin.wasm ./
ls -s
# Update wasm plugin binary in cluster
kubectl delete configmap -n istio-system wasm-plugin || true
kubectl create configmap -n istio-system wasm-plugin --from-file ./url_patcher_wasm_plugin.wasm

# Update or create envoy filter spec (add cluster to Envoy in my case)
kubectl apply -f ./envoy-filter.yaml

# Update or create wasm plugin resource in cluster
kubectl apply -f ./wasm-plugin.yaml

# Restart gateways to apply changes
kubectl delete pods -n istio-system -l istio=ingressgateway --force

Also, despite I have set log level to trace in my wasm plugin code I didn't see the logs, until I set the log level manually. To do that you need to make kubectl exec or port-forward like I showed earlier and set log level with the following command:

curl 127.0.0.1:15000/logging?wasm=debug -XPOST

Conclusion

I think that extensibility through plugins, particularly Wasm plugins, is cool. The ability to choose from a variety of languages and build and deliver plugins according to my preferences is great.

However, I must admit that working with the EnvoyFilter configuration can be a bit challenging, especially for newbies. It involves mixed Istio and Envoy abstractions and configurations, which require getting familiar with the Envoy documentation to understand Istio's features. It would be beneficial to improve the documentation and provide more real-world examples of Wasm plugin usage.

End-to-end GraphQL error handling?

GF — Sun, 08 May 2022 08:32:23 +0000

I want to share my approach to handling errors in GraphQL resolvers (I use GraphQL Yoga on the server-side) and pass them to the frontend side (where I use Svelte + @urql/svelte).

Backend

Packing error info

As I figured out, the only way to return an error from a GraphQL endpoint is by throwing an error in a resolver. That design imposes some restrictions on transferring error data between the backend and frontend. Let's imagine some bad request came that the server can't process, and you want to return an error and probably, some details about what exactly went wrong. Suppose that we want to pack all info in the following interface:

type ApiError = {
   code: 400,
   message: "The request was bad :("
}

Back to restrictions - there is no way to put something object-like as an argument into the new Error(arg) call, but we can transform the ApiError object into a JSON string. That is the weird little trick that allows packing any information into a throwable. That's all about information transfer, but there are a couple more things about code organization.
Return error from GraphQL endpoint by throwing error could be convenient and a type safe with Typescript assert functions. There is no need to wrap return statements into if statements; just throw an error and keep a flat code structure. Let's combine that with packing information into an error object:

export const newApiError = (errorObject: ApiError) => {
   return new Error(JSON.stringify(errorObject))
}

Now it's possible to do throw newApiError(apiError).

But it's still necessary to check whether we need to throw, which means if statements. Could we do better? Yes, with typescript assert functions.

Getting rid of `if` statements

Imagine that a backend receiving a request on an endpoint requires authorization, but there are no creds in the request. It looks like we want to say, "401: Not authorized, there are no creds, you shall not pass." So, what is the easiest way to do it in resolver? I suppose that the following:

// get an auth token somehow
const authToken string | null = req.headers.get("Authorization") 
assert(
  authToken,
  "401: There are no creds, you shall not pass"
)

Custom assert

But it's the only string; as we are not allowed to pass anything like an object into an assert call, so let's write our realization of assert:

export function assertWithApiError<T>(
    statement: T | null | undefined,
    errorObject: ApiError
): asserts statement is T {
    if (!statement) {
        throw newApiError(errorObject)
    }
}

Typescript assert function allows us to have typesafe assertions in which we can throw any throwable even created by ourselves, with any data packed into error.

// get an auth token somehow
const authToken: string | null = req.headers.get("Authorization")
assertWithApiError(
  authToken, 
  { message: 'Auth token is not presented', code: 401 }
)
// there is typescript knows that token is a string

Frontend

What about a frontend part? As I said above, I use @svelte/urql package for dealing with GraphQL in my svelte app. Let's look at the code!
Start with the common @svelte/urql use case:

// mutation function is from @svelte/urql package
const editUserMutation = mutation<{ me: User }>({
   query: EDIT_USER,
})

const { data, error } = await editMeMutation({ intro })

So, the error there is CombinedError type from @svelte/urql, which includes an array of GraphQL original errors:


type OriginalError = {
   message: string
   stack: string
}

export const parseGraphqlApiErrors = (error: CombinedError): ApiError[] => error.graphQLErrors.map((e) => {
   const rawOriginalError = (e.extensions?.originalError as OriginalError).message
   return parseApiError(rawOriginalError)
})


export const parseApiError = (jsonString: string): ApiError => {
   try {
      const parsed: unknown = JSON.parse(jsonString)
      if (apiErrorTypeGuard(parsed)) {
         return parsed
      } else {
         throw new Error('got invalid api error')
      }
   } catch (e) {
      console.error(e)
      throw Error("Can't parse api error from json string")
   }
}

const apiErrorTypeGuard = (possiblyError: any): possiblyError is ApiError =>
   typeof possiblyError === 'object' && 'code' in possiblyError && 'message' in possiblyError

At the end of the story, we have custom assertions that are throwing errors stuffed with any data we want and frontend code that can extract that data; that's it.

I'm not a very experienced user of GraphQL, Svelte, or Urql, and I would be happy if you point me to any existing solution which is better than that described above and hope my ideas will come in handy for someone :)

Photo by Mario Mendez

My random thoughts on Svelte

GF — Sat, 15 Jan 2022 14:34:09 +0000

Reactivity

Svelte has cool and simple reactive model. Really easy to understand and use, when I read docs for the first time I had thought why is that wasn’t done before? However, I think there is could be more. I would like svelte to be more reactive, something like array.push could trigger render. As well as methods in custom classes, which mutate this. Probably, it’s possible to check in compile time is method mutate this or not and behavior corresponding.

Async

Asynchronous blocks look fantastic. There is even no need to have an async function in components - just pass promise as props, and Svelte will do everything that should be done. Also, I like how easy to handle exceptions and loading states. However, it's a bit unclear, at least right now, how is it possible to do some logic in case a promise fails? What if you need to repeat a request or make something else?

Template syntax

Do not like template syntax. Reminds some old times with template engines. It doesn’t look modern and elegant. Not really a downside, rather personal aesthetic preference

Event handling

Not sure about putting event modifiers into an event handler assignment. As long as we can write on JavaScript in a handler function body, we can call modifiers against event objects. Looks too much. I think a good solution should try to do as least as possible in general, and personally can't see how that feature makes code easier to read and write.

Custom events

Keeping consistent custom events names could be an annoying and bug-prone task when some wrapper could just propagate the event above in a tree. Maybe it's not a bad idea to make Svelte push developers declare an event name somewhere in a code and import it to the subscription's place

Media

Updating time for video and audio happens in requestAnimationFrame. Why don't in requestIdleCallback?

Lifecycle

Lifecycle functions remind me of old good react (before hooks era), but there is something good from hooks. For instance, the onMount callback could return a function invoked while destroying. It's really convenient, especially while we have the onDestroy lifecycle function. Also, it's excellent that Svelte allows unbound lifecycle functions with components and lets us reuse them just like React hooks! So in comparison to React, these lifecycle functions got the best parts from hooks and lifecycle class methods and did it better, in my opinion.

Layout

Tick - elegant solution, like it a lot. Easy concept, unlike useLayoutEffect. Just great.

Stores

Like everything else in Svelte, stores feel simple to use and understand. API has no complex concept; just subscribe if you wanna data! I have to admit, when I started reading the Svelte tutorial, I was preparing to understand a new complex framework with complex abstractions, etc. But instead, I see one of the best tutorials I’ve ever seen, simple, kind API (I don’t know, I feel that way), syntax, and it’s excellent! It’s like a breath of fresh air in the modern web (sorry, but especially after React hooks).

Transitions

Transitions are funky, but it looks like those features aim to substitute some CSS. To be honest, I have an undefined opinion about that. There is such a high abstraction, so it's easy to make something, but what is the price? Obviously, not performance - everything happens in compile time. Probably skill? It's incredibly newbie-friendly, in my opinion, but it is crucial to keep learning js and DOM fundamentals for beginners. There is a lot of magic under the hood; hence, it's fun and easy to make the frontend with Svelte, but it will end immediately when you need to write some code outside the framework.

Conclusion

Svelte made many common frontends development patterns less boilerplate and less annoying but left expressiveness and even added fun. Frankly, I'm a bit scared about how much framework is doing for me, like I lost control, but that fear isn't rational and shouldn't be considered as a reason to not use Svelte. Actually, the most important conclusion is that - Svelte made me want to write some frontend again 🙂

Photo by Jonny Gios

Terraform: Is it ok to "read or create" a resource?

GF — Sat, 21 Nov 2020 12:00:47 +0000

I'm very new in Terraform and I suppose that I can bring unsuitable conceptions from programming languages to terraform configs, but I want to tell a little bit about my problem which I've solved in a controversial way, invite you to discuss that solution and, possible, explain that I was wrong.

Recently I needed to deploy a few services in AWS and I used terraform for creating infrastructure. I decided to create a separate terraform config for each application/service I want to deploy in AWS and while I was writing configs it became clear that different services could require the same AWS resource, like a role to access DB, for example. For this case, in order to have the ability to reuse parts of Terraform config as a module, I moved that resource creation into independent configs and started to use it as a module in my services configs.
But very soon I met a problem - when I have the same AWS resources creation statements in different configs, terraform apply will fail with the error Resource already exists. Ok, we need something like "read or create" for resources in terraform config. In that case, we can reuse modules without errors and have independent service configs, each of them would be able to deploy independently. While I was searching for a solution for that case, I found that githib issue, where the same situation discussed, but Terraform closed this issue with an explanation:

The sort of dynamic decision-making that is being requested here runs counter to Terraform's design goals since it makes the configuration a description of what might possibly be rather than what is. We are not going to change the behavior of data sources when the response is empty or 404, and will close this issue.

Ok, we can't make read or create a resource with terraform, but I have found a way which could be controversial and I don't have a definite answer for me is it worth to do terrafrom that way.

The solution is terraform shell provider which allows to do something in shell and return json to terraform. Thus we can do something like this:

data "shell_script" "check_existing" {
  lifecycle_commands {
    read = <<-EOF
      aws iam get-role --role-name ${var.role_name} > /dev/null 2>&1
      [ $? -eq 0 ] && echo "{\"isExist\": true}" || echo "{\"isExist\": false}"
    EOF
  }
}

The script above uses AWS CLI to check if a particular role exists, and return a boolean. This value will be able in other terraform config statements as: data.shell_script.check_existing.output.isExist.
And when I read or create some resource I can use a trick with resource count, for example (with configs separated into modules):

module "is_role_exist" {
  source = "../isExist"
  role_name = var.role_name
}

module "create_role" {
  source = "../create"
  role_name = var.role_name
  count = module.is_role_exist.is_role_exist ? 0 : 1
}

module "read_role" {
  source = "../read"
  role_name = var.role_name
  count = module.is_role_exist.is_role_exist ? 1 : 0
}

Now I have a few modules different applications depends on, with the following structure:

module
  - read
  - create
  - isExist
  - readOrCreate

It is the working solution for conditional creating resources but it contradicts terraform intention, as far as I understood, probably could be useful, but I will be glad to know other opinions 🙂 (There I ask you to share your opinion)

Task id to commit message

GF — Mon, 30 Mar 2020 15:24:10 +0000

I'm sure many of us include task id to branch name, like feature/PROJECT-123. And I'm sure many of us should include task id to commit message, like PROJECT-123 made cool stuff as well. The necessity to add task id to every commit message by hands irritates me, so I decided to write a little git hook intended to do it automatically. I made npm package with this hook and have just published it a couple of days ago.

This hook should be called only at commit-msg git hook because there we have a path to the entered commit message, however, you can find it in readme :)

I hope this hook will help to save a little bit of time!

Redux lib pattern

GF — Mon, 30 Mar 2020 06:01:32 +0000

I would like to describe an approach (could be called "redux lib pattern") which I use in react-redux applications for interacting between modules are not good associated with trivial react-redux way. Also, this approach is useful for using very complex react components extracted to separate modules or packages.

The redux lib pattern allows us to separate applications with almost any module and provides independent development process, deploy and testing for a module, however, let us organize really simple and convenient interacting with a module in an application. Also, the experience of using that pattern showed that it is really convenient to be used by application developers, especially in the case the development process is spread to a few teams with constrained areas of responsibility.

Problems which redux lib pattern allows to avoid:
1) Multiple implementations of code responsible for managing the same modules/components in different applications
2) Absence of architectural borders between modules/components and applications
3) Complex and "weird" integration of modules to react-redux flow
4) Lack of control for changes in interacting between applications and modules
5) Complexity and labor input extracting some code to architectural layer

Let's start from a complex react component example which is extracted to a separate package. Imagine that we have an application are using that component. Component, of course, has defined Props interface, for instance:


    interface ComponentProps {
        prop1: boolean;
        prop2: number;
        prop3: SomeEnum;
        ...
        prop20: Array<number>;
    }

    interface ComponentCallbacks {
        callback1: function;
        ...
        callback5: function;
    }

    type SomeComponentProps = ComponentProps & ComponentCallbacks;

Usually, props for that component could be prepared in mapStateToProps and mapDispactchToProps function in an application. However, responsibility for storing and management of that data lies with an application and the data could be got from different parts of an application redux store. In case our Component is used in a few applications, developers of each of them have to provide management for data required in Component in the application redux store. Of course, it is better to not to do the same work twice. It could be much more simple to pass a whole redux store to Component and it would pick necessary props from a store. On the other hand, it is obvious that Component must not know anything about an application store.
Unification of a part of an application redux store which are contains a data for Component could be solution for problem above, but just agreement about it isn't enough. It is necessary to create solution that will be essential for using. It is the core idea of redux lib pattern - creation additional package which provides sufficient reducer and actions set for interact with Component.

Let's start with a reducer. It implements the ComponentPops interface, excludes callbacks. Also, it is useful to provide the ability to adjust default state:

    // component-redux-lib/reducer.ts

    const defaultState: ComponentProps = {
        prop1: true;
        prop2: 42;
        prop3: SomeEnum.Value;
        ...
        prop20: [4, 2];
    };


    export const createReducer = (defaultStatePatch: Partial<ComponentProps> = {}) => {
        const defaultState = {
            ...defaultState,
            ...defaultStatePatch
        }


        // reducer itself
        return (state = defaultState, action) => {
            ...
        }
    };

    export const reducer = createReducer();

So, redux lib should provide a sufficient set of actions for managing all of Components abilities:

    // component-redux-lib/actions.ts

    const setProp1 = (value: boolean) = ({
        // it is convenient for debug to use lib prefix 
        type: 'COMPONENT-REDUX-LIB/SET-PROP1',
        payload: value
    })

    ...

    export default {
        setProp1,
        setProp2,
        ...
    }

It could be necessary to have thunk actions. However, what if we want to get some data from a store inside a thunk? For example, we need to create toggle action (in fact, I don't recommend to provide any toggle actions from lib and create in an application instead):

    // component-redux-lib/actions.ts

    const toggleProp1 = (value: boolean) = (getState, dispatch) => {
        const state = getState();

        // we don't know where component reducer is located
        const prop1 = state[?];

        dispatch(setProp1(!prop1));

    }

    ...

    export default {
        setProp1,
        setProp2,
        ...
        toggleProp1
    }

For that case let's add constant which determines a location for reducer from redux lib into root application redux store.

    // component-redux-lib/constants.ts

    const componentReducerKey = 'ComponentState';

    export default {
        componentReducerKey
    }

And let's create selector:

    // component-redux-lib/selectors.ts

    import {componentReducerKey} from './constants.ts';

    interface State {
        [componentReducerKey]: ComponentProps
    }

    const getComponentState = (state: State) => state[componentReducerKey];

    export default {
        getComponentState
    }

Now it is possible to create thunk action:

    // component-redux-lib/actions.ts

    import {getComponentState} from './selectors.ts'

    const toggleProp1 = (value: boolean) = (getState, dispatch) => {
        const state = getState();

        // Now we know where component reducer is located
        const {prop1} = getComponentState(state);

        dispatch(setProp1(!prop1));

    }

    ...

    export default {
        setProp1,
        setProp2,
        ...
        toggleProp1
    }

In case we can't store all necessary data in redux lib selector it is possible to add additional parameters to selector function:

    // component-redux-lib/selectors.ts

    import {componentReducerKey} from './constants.ts';

    interface State {
        [componentReducerKey]: ComponentProps
    }

    interface AdditionalProps {
        prop20: Array<number> 
    }

    const createComponentProps = (state: State, additionalProps: AdditionalProps) => {

        // there are could be more complex calculating

        return {
            ...getComponentState(state), 
            ...additionalProps
        }
    }

    export default {
        getComponentState,
        createComponentProps
    }

Redux lib pattern makes Component using surprisingly simple in three steps:
1) Add reducer from lib to root application reducer
2) Pass props to Component via selector from lib
3) Dispatch any necessary action from lib in any place

Step 1:

    // application/create-root-reducer.ts

    import {constants, createReducer} from 'component-redux-lib';

    const reducer = combineReducers({
        ...
        [constants.componentReducerKey]: createReducer(),
        ...
    });

Step 2:

    // application/component-container.ts

    import {Component} from 'component-package';
    import {selectors} from 'component-redux-lib';

    const mapStateToProps = state => {
        const additionalProps = state.someKey;

        return selectors.createComponentProps(selectors.getComponentProps(state), additionalProps)

    }

    export const ReadyToUseComponent = connect(mapStateToProps)(Component)

Step 3:

    // application/anywhere-button.ts

    import {actions} from 'component-redux-lib';

    const Button = (props) => <button onClick={props.toggleProp1}>
        Toggle component prop1
    </button>

    const mapDispatchToProps = dispatch => ({
        toggleProp1: () => dispatch(actions.toggleProp1())
    })

    export const ReadyToUseButton = connect(null ,mapDispatchToProps)(Button)

If Component should give some data to application it worth to add to lib reducer corresponding fields, actions and pass that actions as callbacks to a Component. This data will be available for all of the application components due to lid reducer is placed to application redux store:

    // application/component-container.ts

    import {Component} from 'component-package';
    import {selectors, actions} from 'component-redux-lib';

    const mapStateToProps = state => {
        const additionalProps = state.someKey;

        return selectors.createComponentProps(selectors.getComponentProps(state), additionalProps)

    }

    const mapDispatchToProps = (dispatch) => {
        giveSomeDataOutside: (internalComponentData) => dispatch(actions.giveSomeDataOutside(internalComponentData));
    }

    export const ReadyToUseComponent = connect(mapStateToProps, mapDispatchToProps)(Component);

Thus, all that required for interacting and management with Component we encapsulated in one separate module which is simple to control, change, test and develop. But we can use Component in three same simple steps in any application. No longer need to implement it in each application.

Moreover, redux lib pattern could be used for interacting with module which isn't a react component. Let's say, for interacting with a package provides some interface for use an API. We can easily integrate it into a react-redux application using thunk actions. The example is a little bit naive, but it demonstrates the principle:

    // web-api-module/index.ts

    export class WebApi {

        async method1(params: any) {
            // do smth
        }

        async method2(params: any) {
            // do smth
        }

        async method3(params: any) {
            // do smth
        }

    }

    // web-api-redux-lib/actions.ts

    import {WebApi} from 'web-api-module';

    let webApi;

    const setSmth1Result = (result: Any) => ({
        type: WEB-API-REDUX-LIB/SET-SMTH1,
        payload: result
    })

    const doSmth1 = (params) => async  (getState, dispatch) => {
        if (webApi === undefined) {
            webApi = new WebApi();
        }

        const result = await webApi.method1(params);
        dispatch(setSmth1Result(result));
    }

Reducer, selectors, and constants for web-api-redux-lib create like in the example above.

With redux lib, it is possible to abstract WebApi class instance from application. We can develop, test and even deploy the WebApi package in an independent way. However, integration and using it in a react-redux application will be simple. Moreover, WebApi class can be stateful and redux lib can expose to an application only necessary for UI data. It helps to avoid storing in redux store data which isn't necessary for UI, but developers could rely on.

Described "pattern" has been using for more than a year in our team and proved to be good and really convenient. I hope that approach will help someone to make interacting and management react-redux application with other modules more simple and convenient too.

Interview for an employer

GF — Tue, 12 Nov 2019 20:53:18 +0000

My name is Genrikh and I'm a frontend developer. I have passed pretty much interview over my career in IT as, I'm sure, a lot of developers. I suppose, almost every developer has passed a few interviews and will have passed a few more in the future. Of course, I have been preparing for interviews. I was repeating themes that had been starting to seem a little bit forgotten, solving algorithmic tasks, updating CV and LinkedIn account and even, probably, was trying to put in order my Github account. After a few interviews, a pattern for preparing has appeared. I formed the most frequent meeting questions list and list of themes for repeating to prepare a technical interview. Since I have done it, I look through this list before each interview. Also, there is a lot of advice on the internet about how to write a CV, etc. However, on the basis of the last few interviews, I created one more list, which I going to use in the future - it is a list of my questions to an employer.

As I said above, there is a lot of information on the Internet for applicants how to pass an interview. Mostly this information is useful, but in fact, it is quite general guidance, like, it is better to choose a product company instead of a web studio, good to have the ability to make a career and have professional colleagues. It is good guidances and it works, but I wanted to make a more precise approach to finding an employer.

Below you can find the list of themes and questions that I usually discuss with potential employers and potential managers/team-lead. I'm sure that list isn't full and comprehensive but I didn't include default questions like work schedule, salary, etc. I think it is granted questions and it doesn't need to show up it there. Also, I would like to notice, that the question list is not ordered on question value.

Decision-making process.
The ability to affect decisions is made in a team is essential for me and it is one of the most important criteria in the job choosing process. And I always ask for describing the decision-making process instead of the straightforward question about employees' ability to affect decisions. It is good if that ability is presented in the description.
Short working process description.
From the idea of a new product/feature to deploy on a production server. What kinds of teams are there, how are responsibilities shared between teams, how information streams are organized, etc. It is an important question that allows understanding, based on an answer, what are employer expectations from the position on which you are being interviewed. Moreover, it is possible to find out the diff between your understanding of a job and employer expectations
Team structure.
How big is the team, what roles are presented in the team. It is useful for more precise work process understanding.
Code examples.
I usually ask for two examples. First is the code which team-lead considered as the sample of the best code and second is the sample of the code which should be refactored as soon as possible. Great if you could be received code examples by, for example, email and look into that at home with appropriate attention.
Code review process.
Is it exist in a team? Which linters, rules, agreements, and methods are used in a team for support code quality and control about code? An answer to that question, in my opinion, has a good correlation with the degree of code love.
Tech debt.
How a team does work with tech debt? Does a team have an organized process to work with tech debt? Do managers/team-leads admit of tech debt existence? On one of my interviews, potential team lead said that developers in the team were so good that they don't produce tech debt. Probably, answer like that lets to make some conclusions.
Meetings.
How are meetings usually held? Is an agenda is necessary for meeting making? What reasons do usually lead to a meeting? Are meeting artifacts required? My opinion is that: reasons require meetings should be reasonable, not very minor, and every meeting should have an agenda and artifacts.
Question for potential manager / team-lead: Explain what micro-management in your opinion. Is it good or not and why?
I really hate micro-management and I really appreciate the existence of freedom (within certain limits). Answers to those questions you could fit in your opinion.
Question for potential manager / team-lead: Could you remember some significant decision you have made and give arguments that guided you?
It is an answer where it is possible to understand how your potential manager makes decisions. In case you are familiar with the decision theme, it might be interesting to have a discussion.
Current situation in company and working mode.
Sometimes companies search developers when don't have time to release product. And right after you have joined team, you get to the center of a rampant storm of development. I don't say that it is bad, but I'm pretty sure you want to know about that circumstance when you are thinking about a few job offers.
Expectations from an employee on a role you are being interviewed.
General question, however, expectations at each place are different, sometimes you could hear interesting things in answer.
Main inside and outside company priorities.
Of course, everyone wants to know more about a potential job. Even if you know about company priorities it could be useful to hear employee interpretation.
Plans for the near future.
A main plans and tasks for the next one or two years.

I hope this list will help someone to make a better decision about a job choosing and avoid disappointing at a new job as it helped me.

Convenient development with ts-node on server-side

GF — Sun, 01 Sep 2019 10:32:57 +0000

This article is a description of some difficulties I met while was configuring a small project for development ts-node server. The main aim of that article is sharing my experience in solving a few problems I met and make the solving process simpler for people who want to solve the same problems in the ts-node development process.

Why is ts-node? I have been using typescript for only one year but firstly was annoyed by it. A little while later, when I had become more familiar with it, I loved this language and in some cases typescript is indispensable. It is necessary to spend more time on development but it will pay off when you have to support code, especially when you doing something involves changes in much code in different places in codebase.

So, below three features I want to have while development:

Habitual imports, without require or import * as Smth from 'smth', just import Smth from 'smth'
Demon for server restarting
Ability to set --inspect flag for debugging in chrome console

Imports configuring

The first item doesn't look like an intricate task, does it? However, I have spent some time reaching that aim. In all examples I managed to find in the web, imports like require or import * as Smth from 'smth' was used. In fact, it isn't a problem, but I want to be more concise and finally, I used to use ES6 imports. For using ES6 imports I did the next:

Files structure I used:

├── src
│   └── index.ts
└── .tsconfig.json

Add to tsconfig.json

   "compilerOptions": {
      "module": "commonjs",
      "allowSyntheticDefaultImports": true,
      "esModuleInterop": true,
   }

npm script for running server:

      "scripts" : {
          "dev": "TS_NODE_PROJECT='./tsconfig.json' ts-node src/index.ts"
      }

Demon

While developing with node.js I usually prefer to use nodemon package. In a few examples, I saw ts-node projects with it. However, as far as I understood, nodemon uses previously compiled code. I.e. ts-node watches for files, compile files into a directory pointed as a source to nodemon. I don't want to use that way because I want to make ts-node making all work.

I wrote npm script below and actually it works, but...

      "scripts" : {
          "dev": "TS_NODE_PROJECT='./tsconfig.json' nodemon -r ts-node/register ./src/index.ts"
      }

But if you add "noImplicitAny": true, to your tsconfig.json it won't work.
(As far as I understand because of nodemon can't have deal with types, but I can mistake)

Moreover, even if you don't add this rule the --inspect flag won't work.

Let's go further and take the ts-node-dev package. It allows to reach what I want with the next npm script:

      "scripts" : {
          "dev": "TS_NODE_PROJECT='./tsconfig.json' ts-node-dev --respawn ./src src/index.ts"
      }

Cool! I have habitual imports and demon without intermediate compilation!

Debugging

Now it is very simple, just add the --inspect flag:

      "scripts" : {
          "dev": "TS_NODE_PROJECT='./tsconfig.json' ts-node-dev  --inspect --respawn ./src src/index.ts"
      }

Recap

Necessary fields in tsconfig.jsoon:

{
    "compilerOptions": {
    "module": "commonjs",
    "rootDir": "src",
    "moduleResolution": "node",
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "noImplicitAny": true,
  },
    "include": ["src/"],
    "exclude": ["node_modules"]
  }
}

npm script:

      "scripts" : {
          "dev": "TS_NODE_PROJECT='./tsconfig.json' ts-node-dev  --inspect --respawn ./src src/index.ts"
      }

That's it! Now it is possible to work with typescript on the server-side in a convenient way.
I hope this guide will be helpful for someone and will let avoid wasting time because I have spent several hours to discover all of that.

Forem: GF

Unlocking Istio's Versatility: A Guide to WASM Plugins in Kubernetes

Introduction

The Need for Dynamic Routing

Collecting Workload Information

Routing

Client traffic

Wasm plugin implementation

Configuring Gateway Envoy

Installing wasm plugin

Coding wasm plugin

Reading plugin config

Dispatch HTTP call from inside wasm plugin

Convenient development

Conclusion

End-to-end GraphQL error handling?

Backend

Packing error info

Getting rid of if statements

Custom assert

Frontend

My random thoughts on Svelte

Reactivity

Async

Template syntax

Event handling

Custom events

Media

Lifecycle

Layout

Stores

Transitions

Conclusion

Terraform: Is it ok to "read or create" a resource?

Task id to commit message

Redux lib pattern

Interview for an employer

Convenient development with ts-node on server-side

Imports configuring

Demon

Debugging

Recap

Getting rid of `if` statements