DEV Community: Yurii Zinets

Kyoto on GopherCon 2021! (including text version)

Yurii Zinets — Wed, 22 Dec 2021 10:29:41 +0000

Intro

Hi everyone!
Today I'd like to present the library named kyoto. It's an SSR-first go frontend library.

First, let me introduce myself. I'm Yurii Zinets. Software Engineer at Akamai, but also a Core Developer of BrokerOne Real Estate platform on part-time. The overall story I'm going to tell is actually related to BrokerOne development process.

Backstory

Before I start to talk about kyoto itself, it's important to know backstory because we are not creating technologies for technologies, but for solving different problems. So, a long story short. In the beginning of the platform creation, we decided to create a prototype first. We took a well-known JavaScript framework with a set of ready to use material components. As usually happens, the prototype became the main project. Over the time, we began to feel the impact of this decision. It was hard to keep the project clean and tidy. We had a lot of difficulties with SSR, memory leaks on the server side and performance score issues. We completely lost control. After discussion, our team decided to drop this prototype and go in more traditional way - use template engine.

Why template engine?

So, why did we choose such a radical way? We had several reasons. Unnecessary complexity was one of those reasons.
Not many people really understand how their project setup works under the hood. Webpack with tons of configurations, babel, tree shaking (especially when it doesn't work as expected), lazy loading. You need to bring a significant runtime and Virtual DOM just to render a simple things like articles or pages with minimal dynamic behavior. Template engine reduces overall complexity and allows taking full control over frontend. Also, this approach reduces amount of bugs and quirks because we can find most of the problems on building and testing stages.

What problems kyoto is trying to solve?

Our project became much better with this migration, but we faced some common inconveniences. We have started to use more copy-paste. Our handlers became a spaghetti because of asynchronous API and DB requests. And we all have to admit, vanilla JS is quite verbose even for simple dynamic things.
That's why kyoto was born.

What features kyoto provides?

First issue I solved is code organization structure.
For each page and component, you have separate Go structure and template definition. You can include data fetching and display logic just right inside a component. Second thing I provided is page rendering lifecycle. This allowed me to solve asynchronous calls issue. You can implement asynchronous method for component, and it will be called with own goroutine under the hood on page rendering. As an example, you have 10 instances of the component on the page.
In that situation, 10 goroutines will be created for each asynchronous call. And the most interesting thing in this library I've implemented is a built-in dynamics functionality, inspired by Hotwire and Laravel Livewire.
It's pretty simple and limited because it's created for simple things. But people really liked it, and I'm extending functions over the time.

Future plans

As the project has solidified its core idea, I'm able to make some plans for the future. We are already working on UI Kit, based on Tailwind UI, and already using it for our internal tools. Anyway, it still needs a lot of work. Also, one of the features I'd like to provide is a Server Side State. This approach will reduce the initial amount of data to transfer between server and client. And last, but the most interesting and crazy idea I'm experimenting on is bringing the whole rendering process to the Edge Workers. It's giving to us a serverless setup and insanely fast responses. Unfortunately, Cloudflare Edge Workers have a lot of restrictions (like 1 MB executable size limit) and don't have official support for Go. I was able to run Go on the Edge Workers with tinygo compiler and WASM, but it's not enough to be able to use kyoto as expected.

Summary

So, here is a quick summary for this talk. I think Go have a big potential and is not limited by current domain. Otherwise, it would be impossible to create tools and libraries like this. I'd like to note that kyoto is not a framework by its own. On my opinion, combination of UI Kit, project blueprints and best practices are actually become a framework. I'm not creating kyoto opposite to JavaScript solutions. Even more, it's possible to integrate them. I just believe that every solution has an own purpose. And I hope this solution will help someone too.

Bonus links

Scheduler: https://github.com/kyoto-framework/scheduler
UIKit (WIP): https://github.com/kyoto-framework/uikit

kyoto on GopherCon 2021!

Yurii Zinets — Thu, 09 Dec 2021 11:14:25 +0000

For those unfamiliar with kyoto, it's an SSR-first Go Frontend Library. It's my first time going public and I hope it was not as awful as I think 😅

Library: https://github.com/kyoto-framework/kyoto
Talk recording: https://youtu.be/35eIxI_n5ZM?t=11860

I was really happy to participate, the atmosphere was delightful!

Kyoto: Golang SSR-first Frontend Library

Yurii Zinets — Wed, 27 Oct 2021 10:45:00 +0000

https://github.com/yuriizinets/kyoto

This library implements an HTML render engine concept that brings frontend-like components experience to the server side with native html/template on steroids. Supports any serving basis (net/http/gin/etc), that provides io.Writer in response.

Main motivation is to reduce usage of popular SPA/PWA frameworks where it's not needed because it adds a lot of complexity and overhead. There is no reason to bring significant runtime, VirtualDOM, and Webpack into the project with minimal dynamic frontend behavior. This project proves the possibility of keeping most of the logic on the server's side.

References:

Library: https://github.com/yuriizinets/kyoto
Documentation: https://kyoto.codes/docs/
UIKit (in active development): https://github.com/yuriizinets/kyoto-uikit
Starter project: https://github.com/yuriizinets/kyoto-starter

ssceng: Golang Frontend Components

Yurii Zinets — Thu, 16 Sep 2021 11:15:17 +0000

https://ssceng.codes

SSC, changes and propositions

Yurii Zinets — Fri, 30 Apr 2021 09:45:32 +0000

https://github.com/yuriizinets/go-ssc

Latest changes

Actions handler simplified. Now, it's implemented as http.HandlerFunc and much easier to use. I've added some documentation for that, but it still far away from "done".
Actions arguments handling changed. You can just specify as much arguments, as you want in that way: {{ action "ActionName" 1 2 3 }}. That arguments will be passed as interface slice into your Action.
Demo page upgraded. It's still not so awesome as need to be, but I'm doing my best :)

Asking for ideas and propositions

I'm building development roadmap now and would like to listen for community ideas, about your vision of this concept. Feel free to propose anything you would like to see in this project, I would be very glad for any feedback :)

Frontend components with Golang

Yurii Zinets — Sat, 24 Apr 2021 08:25:48 +0000

First of all, thank you for attention!
I'd like to present you HTML render engine concept, that brings frontend-like components experience to the server side with native html/template on steroids. Supports any serving basis (nethttp/Gin/etc), that provides io.Writer for response.

yuriizinets / ssceng

⚙️ Concept of Golang HTML render engine with frontend components and dynamic behavior

Please, keep in mind that it's work-in-progress, but already used in BrokerOne for some parts of our frontend and already shows good prospects.

Why?

I'm trying to minimize usage of popular SPA/PWA frameworks where it's not needed at all because it adds a lot of complexity and overhead. Nowadays JS ecosystem is overcomplicated and huge. I don't want to separately implement API, API communication layer, bring large runtime, state management engine, VirtualDOM and webpack into project with minimal dynamic frontend behavior.
This project proves posibility to keep most of the logic on the server side.

What problems it solves? Why not plain GoKit?

While developing website's frontend with Go I realised some downsides of such approach:

With plain html/template your're starting to repeat yourself. It's harder to define reusable parts
You must to repeat DTO calls for each page, where you're using reusable parts
With Go's routines approach it's hard to make async-like DTO calls in the handlers
For dynamic things, you still need to use JS and client-side DOM modification

Complexity is much higher when all of them combined.

This engine tries to bring components and async experience to the traditional server side rendering.

Features

Component approach in mix with html/template
Asynchronous operations
Component methods, that can be called from client side (Server Side Actions, SSA)
Different types of components communication (parent, cross)

GoogletransX update!

Yurii Zinets — Tue, 06 Oct 2020 10:05:16 +0000

https://github.com/yuriizinets/googletransx

Hi guys! :)
A bit earlier, I published my extended version of Googletrans (check here). And now, I'd like to introduce to you some changes

Interface translation

From now, with TranslateInterface you can translate your structured data directly! Without handling fields getting and setting by yourself. It supports all the features, that github.com/stretchr/objx provides (nested interfaces, slices, etc)

Example is here:

package main

import (
    "github.com/yuriizinets/googletransx"
)

func main() {
    input := map[string]interface{}{
        "A": map[string]interface{}{
            "B": "I'm a test",
            "D": []string{"Example", "Example"},
        },
        "C": "Example",
    }
    params := TranslateParams{
        Src:  "en",
        Dest: "ru",
    }
    fields := []TranslateField{
        {
            Src:    "A.B",
            Dest:   "A.B_ru",
            Params: params,
        },
        {
            Src:    "A.D",
            Dest:   "A.D_ru",
            Params: params,
        },
    }
    output, err := TranslateInterface(input, fields)
    if err != nil {
        t.Fatal(err)
    }
    fmt.Println(output) // Will be map[A:map[B:I'm a test B_ru:Я тест D:[Example Example] D_ru:[пример пример]] C:Example]
}

Ordered results from bulk

It wasn't in the plans, but TranslateInterface requires correctly ordered results from BulkTranslate. So, UID field is added for TranslateParams struct. It's optional, you can just leave it as-is, BulkTranslate will put UIDs for you.

Summary

I hope, that changes will be useful for you.
Thank you for your attention, and good luck!

P.S.

Don't forget to check my another articles and packages!

Go private packages

Yurii Zinets — Sun, 04 Oct 2020 07:33:07 +0000

TL;DR
git submodules

What's the matter?

Imagine a situation when you're following best practices, splitting your code on different parts, and ... facing an issue to collect them.
Unfortunately, go does not support private packages well.

So, how?

I'll describe the situation I faced. Private go mod packages, located in the GitLab subgroup (let's say gitlab.com/org/department/repo1.git just for example)

First, go not actually supports GitLab subgroups. To bypass that issue, we need to set GOPRIVATE env variable and add .git in the end:

$ GOPRIVATE="gitlab.com/org/department" go get gitlab.com/org/department/repo1.git

Second barrier is access to that repo. SSH key must be added to the platform, I didn't found a way to fetch with https.

Pros:

Native experience (go get, which handles go.mod changes itself)

Cons:

SSH key must be set
go.mod package name must fully correspond that naming (with .git in the end)

Problem is solved ... or not?

The first problem was faced in just after half an hour. It's a CI/CD, or just building step.
As we understood from previous "summary", SSH key must be added. We are using Docker to build our project, and passing SSH key to the Dockerfile build actually is a security problem.

Alternative way

I found a solution in git submodules and replace feature for the go.mod.
Just add needed repo as a project submodule with git submodule add and add naming replacement in the go.mod.
For example:

Adding submodule

$ git submodule add ../repo1

Pulling newly added repo

$ git submodule update --init

Adding go.mod replacement

replace gitlab.com/org/department/repo1.git => ./repo1

And that's all! Handling package as a submodule is much easier than go package.

P.S. Don't forget to add submodules pulling in your CI! In case of GitLab it's GIT_SUBMODULE_STRATEGY: recursive variable.

Thank you for reading!

GoogletransX: Free unlimited translation

Yurii Zinets — Sat, 19 Sep 2020 11:01:49 +0000

Hi guys!
I'd like to share with you my work on extending existing google translate library project with some features.

https://github.com/yuriizinets/googletransx

So, what features?

All that original library functionality, including unlimited free translates! :)
BulkTranslate with goroutines processing
HTML translate support
Built-in API server for integrations
Dockerized server

Why not original library?

To be honest, I started that project due to absence of normal BulkTranslate functionality. I had to translate a really huge amount of different data, and to make it fast and functional I created fork with extended features.

API server? For what?

Golang may be not the only language in the project. For simple integration I bundled functionality as a simple API to use that as a service.

P.S.
I hope that it will be useful for you. Even if not, thank you for your attention :)

GoPlaces: Go Algolia Places API Wrapper

Yurii Zinets — Sun, 13 Sep 2020 16:10:15 +0000

Hi, guys!
I'm new to the Golang and that ecosystem, so I'd like to share with you my small experimental library :)

Sometimes geocoding functionality is needed on the server side, but Algolia Places only provides basic API for that purpose. So, I decided to wrap that API with small Go library to simplify work.

https://github.com/yuriizinets/goplaces

DEV Community: Yurii Zinets

Kyoto on GopherCon 2021! (including text version)

Intro

Backstory

Why template engine?

What problems kyoto is trying to solve?

What features kyoto provides?

Future plans

Summary

Links

Bonus links

kyoto on GopherCon 2021!

Kyoto: Golang SSR-first Frontend Library

ssceng: Golang Frontend Components

SSC, changes and propositions

Latest changes

Asking for ideas and propositions

Frontend components with Golang

yuriizinets / ssceng

⚙️ Concept of Golang HTML render engine with frontend components and dynamic behavior

Why?

What problems it solves? Why not plain GoKit?

Features

GoogletransX update!

Interface translation

Ordered results from bulk

Summary

P.S.

Go private packages

What's the matter?

So, how?

Problem is solved ... or not?

Alternative way

GoogletransX: Free unlimited translation

So, what features?

Why not original library?

API server? For what?

GoPlaces: Go Algolia Places API Wrapper