DEV Community: Matuzalém Teles

LOLTV.gg - Building VLR.gg/HLTV.org for League of Legends — but way more modern and unique

Matuzalém Teles — Wed, 21 May 2025 02:11:14 +0000

Over the past few months, I've been working solo on building LOLTV.gg — a hub for League of Legends eSports, inspired by platforms like HLTV.org (for CS) and VLR.gg (for Valorant), but with a much more modern and unique approach.

My goal is to create a space where LoL eSports fans can come together to explore detailed match data, engage in meaningful discussions, and dive deep into everything from player performance to team histories — all in a way that’s clean, fast, and purpose-built for the community.

What’s already live:

Detailed match pages with timelines, scoreboards, and team stats
Player profiles with recent performance, stats, historical stats, trophies, and seasonal insights
Team pages with roster info, past results, and tournament stats
Recent transfers page teams roster changes.
Tournament pages bracket, standings, stages, schedule, results and stats.
Forums for discussion with a custom editor tailored for LoL talk (builds, meta, etc.)
Community-driven news, where users can submit news that gets featured like X (Twitter) posts
Pro builds page with champion statistics with official data from League of Legends competitions. Discover trends, champion performance, the most common pro builds, champion presence, and more.
A clean UI that keeps things intuitive and fast

Challenges

The platform is built on top of Next.js, using Incremental Static Regeneration (ISR) to cache pages effectively. Since most match and tournament pages are historical and rarely change, they’re only revalidated when a new comment is added — which triggers a cache update for that specific page.

Some UI components — like the recent activity sidebar or today’s matches — are updated on the client side, and their context changes depending on the page you’re on. This can occasionally cause a visual “blink” with SSR, something I’m still experimenting with. One idea is to move fully to client-side rendering for those pieces or find a hybrid approach that avoids unnecessary flashes while keeping the page fast.

In general, Next.js with ISR works really well, but there are still challenges when it comes to rendering uncached pages with server-side rendering. These pages can sometimes take too long to load, so optimizing SSR performance for cache misses is a priority in the next iteration.

There’s still a lot in progress. One of the biggest upcoming features is Global Stats — an entirely new layer that doesn't exist on any current platform. You'll be able to segment data by patch, region, champion, and more to uncover trends and insights.

We also have a Live Score feature — real-time stats during games, along with an interactive match timeline, similar to what HLTV.org offers, but adapted for LoL.

The image below shows the champion build page for Skarner during the current season. It includes all relevant stats, preferred builds, and Skarner’s performance against other champions in official matches.

A huge focus is on the forum experience — not just a message board, but a modern place to break down builds, react to patch notes, analyze pro plays, and share ideas. The advanced editor makes it easier to express complex opinions and link them with actual data from the platform.

Here are a few more screenshots to give you an idea of where things are going:

If you're a fan of LoL eSports or just love data-driven platforms, I’d love your feedback. The platform is evolving fast, and a lot of features are being built based on how the community wants to engage with the game.

Thanks for reading — more updates soon!

Fleet Serverless Function Introduction

Matuzalém Teles — Tue, 16 Jun 2020 15:40:25 +0000

In February this year, we announced Fleet (Formerly Hole), a FaaS platform built on Node.js to be faster than other platforms and to create a more faithful integration with the ecosystem. In this post, I will clarify how all of this works and what we are bringing differently to the Serverless ecosystem and in the next article I will comment on the platform.

What are Fleet Function?
- Common issues
- Fleet Solution
Scaling
HTTP Rest
Use cases

What are Fleet Function?

It is a technology capable of executing Node.js functions that are invoked by HTTP requests with auto-scale to zero or N with the ability to execute the functions with a cold start to almost zero.

export default (req, res) => {
    res.send({ message: 'ƒ Fleet Simple HTTP Endpoint!' });
};

Live Example: https://examples.runfleet.io/simple-http-endpoint/

Common issues

In a brief explanation about the cold start is when your service receives a request and the platform has to provision its function to be able to handle the request, usually following this flow:

Event invoke
Start new VM
Download code (from S3, normally.)
Setup runtime
Init function

The steps from 2 to 4 are what we call Cold start, in the next invocations, if the instance is available and cached the provider can skip these steps to execute the function in Warm start. There are some misunderstandings about the cold start when a function is already running and receives a new invocation, the provider will invoke a new instance with a cold start, the same happens when your application receives many invocations simultaneously, all will be with a cold start.

One of the solutions that some adopt is to ping from time to time to keep the instance alive or use the concurrency provisioning service that will increase your expenses and require you to know exactly what your application's traffic spikes are, requires monitoring to prevent unnecessary expenses which for some this is very bad because it removes the idea of you not worrying about the infra...

Fleet Solution

The Fleet Function solution for this is to execute its functions safely and quickly, so we focus on being able to execute several functions in a single Node.js process that is capable of handling thousands of functions at the same time, executed in an isolated environment, safe and fast.

Isolated Able to perform a function with isolated memory and allow them to use CPU according to the provisioned limits.
Safe In the same instance, one function is not able to observe the other or obtain resources from other functions (such as information from process.env, context, requests...), this also includes access to the File System.
Fast We eliminated the steps "Start new VM" and "Setup runtime", the source code, is available in each region where the function is available, close to the execution time. We were able to execute the functions faster within the same process.

This means that we can run Node.js functions much faster than other platforms and the functions consume an order of magnitude less memory while maintaining security and an isolated environment.

To impose a safe environment, Fleet had to limit some Node.js APIs to increase security and prevent suspicious functions from having access to resources, each running function only has access to resources that have been granted to it.

Scaling

One of the main differentials of Fleet is also how we can scale its Node.js functions. Unlike other platforms that scale their function only via concurrency, that is, each instance of a VM can only handle one invocation at a time, if it is busy it will provision a new instance but there is a limit for that, normally 1000 instances in concurrency.

Differently in Fleet, we have managed that its function can handle many asynchronous requests at a time within a configured limit, if this limit is reached for some time a new instance is provisioned for its function in just a few ms. This means that during the time that your function is running it can handle many requests and take advantage of the connection established with your database during several requests.

In Fleet there is no clear concurrency limit, it is dynamic by region. We do everything to handle the maximum number of requests, you have control over the asynchronous limit so you can multiply the number of requests that your application can handle.

HTTP Rest

Fleet Functions are invoked via HTTP Rest, there is no need for an extra API Gateway service, each new deployment Fleet generates a new URL for preview deployment (in <uid>-<project-name>.runfleet.io ) and with an option, you can define the deployment for production with an exclusive subdomain in <project-name>.runfleet.io.

All deployments are made on a project created on console.fleetfn.com, capable of inviting members to teams with privileges... that's a subject for another article.

You may want to read more about it here.

Use cases

Fleet is built to run Node.js functions much faster and will soon run functions in other languages using WebAssembly. With that in mind, Fleet does not deal with container provisioning like Cloud Run or allows you to create your own custom runtime environment.

Can handle APIs of your applications very well able to meet the high demand and save with low demand.

Fleet can handle microservices, calls between functions, and traffic changes with great confidence. We are working on what we call the Virtual Private Function or VPF which is a network of private functions, this isolates the functions inside the VPF from the outside world, allows only some of the functions inside the VPF to be invoked by the outside world, it also allows better monitoring and sharing between VPFs, in the future, we also want to allow you to securely connect your current network to the VPF network. In addition, we are working on Traffic Shifting is our service capable of making canary deployments using a set of rules based on data, you define an autonomous set of rules to increase the reliability of the traffic change to perform the split, for example, a certain amount of successful or failed requests can increase the traffic percentage for a specific deployment. This is for services that are sensitive to problems with code or when testing new features.

Although the focus of Fleet is not on website hosting, you can also handle server-side rendering with React, deploy the static files to an S3 and use the functions to routing.

I invite you to visit our website, our documentation and the examples repository, feel free to explore, if that interests you and you are curious to test it we are in the private beta phase, with some people already testing, we send invitations every week. To register is very easy:

Go to console.fleetfn.com
Continue with Github and hope that you will soon receive an email

If you want to prioritize your email in the early access list, you can fill out our quick questionnaire.

We are every week publishing our weekly changelog, you can follow closely on our twitter @fleetfn which includes some short videos of the main resources and we always publish on our specific page for the changelog with a more detailed description fleetfn.com/changelog.

Design System: Compositional philosophy of components

Matuzalém Teles — Sat, 22 Feb 2020 20:14:02 +0000

Products evolve quickly within a large organization, companies need to move fast, build consistently, deliver new products and maintain existing ones. As part of all this, the solution adopted is to build a Design System, rooted in the principles of common patterns, colors, typography and grid.

The great challenge of a team that deals with the materialization of the design system into components is how to expose the fast pace of a company and continue to deliver value to the components for the product teams. An organization's developers want to go beyond implementation because products evolve, but some of them just want to follow the implementation.

There is a big challenge in this environment, the Design System team on the Design side can take different approaches, arrest Design to specific component cases or create just the foundation (e.g Colors, Typography, spacing, Grid, Layouts...) or meet both cases. There are disadvantages and advantages in each case and it is up to you to understand how each case can work better in the context of your organization.

On the other hand, developers of the component library can take different approaches:

Create components providing only the cases of the Design System, restricting the use of the component to cases other than the one defined.
Create components with high flexibility, allowing developers to deviate from the defined cases when the product design thinks beyond what is defined.

The result of this can be bad on both sides, we can frustrate the developers because they may have to create their own component or they will have to do a lot of work with the flexible components to arrive at the specific case of the design created by the designer of his team and the Design System can block the creative mind of the designer because the component definitions are fixed.

Correcting and dealing with this is complex, but what should we do? in our company (Liferay) in the past we have followed the approach of fixed components to the Design System and not allowing developers to go far beyond what is expected, in a company context with more than 300 engineers and several product teams, this was a bad decision, which resulted in the low adoption of components, for some reasons:

The components were too attached to the Design system
Little flexibility
Designers created components beyond implementation

As a result, our components had large APIs, with low usage, high configuration complexity, increasing maintenance costs and entering the depreciation phase very quickly.

We know this was a bad decision and we quickly switched to another approach the following year. We took the approach of achieving a balance between flexibility and specialized components in our component library.

Dealing with this may seem easier, but how do we materialize the idea? We follow a hybrid approach to our components, we call this the Multi-Layered API library.

Multi-Layered API library

Multi-Layered components mean that we have two ways to provide a component:

low-level - Basic building blocks to provide flexibility so that you can customize and create high level components.
high-level - Highly specific component that tend to cover only specific use cases, limiting their flexibility.

The principles are pretty basic but to be called you need to follow some laws.

Low-level

Low-level components follow the composition, such as small blocks that build a DropDown component.

<ClayDropDown />
<ClayDropDown.Action />
<ClayDropDown.Item />
<ClayDropDown.ItemList />
<ClayDropDown.Search />

High-level

High-level components may also follow composition but may be more specific components with something in common among many teams.

<ClayButtonWithIcon />
<ClayCardWithHorizontal />
<ClayCardWithNavigation />
<ClayDropDownWithItems />

High-level components are built with low-levels, this may decrease maintenance but increase the surface of available APIs.

The benefit of this is that you can come up with a hybrid approach that reaches more adoption and many teams with different tastes.

You can read more about our composition approach in our documentation in our component library.

The result of this approach was the high adoption of our components in different teams and products with different contexts, helping teams to deliver faster and they are happier.

This seems to solve the problems at the user level but we get involved in several discussions on how to differentiate, build and structure the low-level and high-level components. I have separated some of my thoughts on this from trying to follow a theory or something conceptual and adjusting things over time.

Tail theory

Do not confuse this with The Long Tail Effect theory.

Tail theory is a rope anology with two ends or tails, where you place both types of components, low-level and high-level, at each end. The distance between them can cause great pain or great successes is all or nothing here!

Extremes can be very painful or very straightforward, meaning that high-levels attached to specific use cases can bring happiness to a team that is following the definition correctly and can create a lot of pain for those who are not.
For those in pain, the pain gets bigger because the low-level is at the other end, building from low-level to something close to high-level can be painful.
Extreme high-level cases may be of little adoption as their cases are specific and do not allow any change outside of the specified.
Low-levels tend to have a long life because they are more flexible but naturally require more work.

More stuck components tend to change more over time and their life cycle tends to be shorter.

This graph is hypothetical, real data has not been used here, but is based on my experiences over time working with component library.

Some peculiar things: we may have low-level working very well in the short and long term and having few changes, that would be the ideal scenario for us but in the middle there is one thing we can lose, the effort and development experience: these are points keys for people to adopt library components and to build without much effort.

Very specific components can change a lot over time and in a short period of time and it may happen that at some point we will have to depreciate why the component has swelled, this can happen with any component but we will have maintenance issues and a constant fight to update things before people can start using them. We can extend the life of these components and decrease maintenance so we can worry about improving or building things beyond the components.

So imagine that if I push the component closer and closer to the middle of the rope and the distance between the sides decreases, it means that we reduce the pain in the sides but getting closer will not have a clear difference, it creates confusion. Each time we give some flexibility to the high levels we push them to the middle of the rope, the experience gets better and the pain can decrease.

Note that we do not want to join the two sides but we want to get close, the tail is the extreme and the extreme has a price, we just want to distance it and we need to offer some flexibility for the high-level components and decrease the flexibility for the low-level.

With that in mind, we can:

Increase the longevity of high-level components.
Fewer changes over time
As a result, we support more use cases
People are happier

Although the greatest benefit falls on high-level, low-level is influenced because once we take away some of its natural flexibility, it slightly increases the amount of change over time and the maintenance over it also increases but this is necessary since we have to create a balance and the disparity between the two is not stark.

I believe it is easier to stick to this theory. Once we understand, it will be natural to identify when a component needs more flexibility or when we need to maintain the API.

Our Liferay component library is Open Source and you can access it through Github:

Github: http://github.com/liferay/clay
Site: http://clayui.com
Design System: https://liferay.design/lexicon/

I have been working on this for 2 ½ years and I will be very happy to hear your thoughts and experiences.

Our Github repository is full of very interesting thoughts and speeches. Explore our issues and PR's 🙂.

Follow + Say Hi! 👋 Connect with me on Twitter 🐦!

Introducing Hole a new serverless technology for Node.js

Matuzalém Teles — Sun, 16 Feb 2020 05:06:02 +0000

Publication originally posted at https://hole.build/blog/2020/02/16/introducing-hole-serverless.html

Introducing the new generation of serverless technology for Node.js, efficient and cold start to zero with hole.build.

Managing servers with a complex infrastructure a professional team focused only on monitoring and consuming several hours to decide how to scale and support large peaks in access and use of the application's APIs, has always been the problem to deal with high availability and fast growth projects.

Over time, several technologies and standards have been created to deal with this and they are one of the most critical things of a product when not well thought out and orchestrated can be a big headache for the rapid growth of a company but it requires professional demand qualified staff for monitoring and security. At the beginning of a small startup this can be a big cost because they need to grow quickly, they need to worry about their product, validate, win over their first customers and start selling.

Maintaining an infrastructure, monitoring and servers team to maintain the product can be very expensive, paying for services that are not used or are idle in times of low access can impact the company's balance sheet.

A few years ago, the "serverless" (FaaS) movement and technologies began to emerge, with a view to solving these types of problems:

auto-scaling,
scaling to down,
zero servers,
without complex infrastructure,
pay only for resources when used,

This is beautiful and it looks like the best of all worlds to start building the product on top of that, but with that it came with a main disadvantage: performance, functions that are not executed with high frequency can suffer a higher response latency than the code being runs continuously on a server.

On other serverless platforms, when a request arrives, the platform provisions a container with its function runtime, there is a waiting time until its function can actually start to be executed and process the request, called a cold start. Your container is kept on "hold" for some time so that can process another request but without cold start, when new requests arrive and some of these containers are already occupied, other containers will have to be sized to process the new requests starting with the cold start.

At Hole we built our technology to solve some of the main problems of serverless: performance, security, monitoring and debuging. Our functions are executed with cold starts to almost zero, we limit and add more layers of security in the environments of execution of the function, we show metrics of requests made successfully and failed in more details and insights on the performance of your code. In addition to improving serverless technology, we are very concerned with the experience of using the technology, console, design and friendly docs.

Our functions can be performed with cold starts to almost zero and functions can be configured to handle more than one asynchronous request increasing the limits of provisioning your function. You can read more about how our technology works in our documentation.

These are some crucial points that we are attacking but we want to improve even more how companies interact and work with serverless technologies is just the beginning, and we have many things that we want to show. It will be a long journey and we are excited to share our learnings and thoughts as we progress.

Today, we are starting to accept teams and companies for our private alpha. If you are interested in joining early and influencing the direction of Hole, sign up here and follow us on Twitter.