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.
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.
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.
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.
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.
- GitHub: https://github.com/kyoto-framework/kyoto
- Presentation materials: https://github.com/kyoto-framework/gophercon-2021