Relate

Relate is a web platform based in Canada, still under development, that brings forward a new way of working with information.

It’s layered and it gives you a very visual way of organizing things in space. Inside this space you can actually work, it’s not just about note taking or organizing. You really bring your information in there to work with it. So while you work, you organize things and it’s easy for people to work with you.

The research for this ingenious, new way of working online started way back in 2010 and it’s getting close to release. We asked the mastermind behind Relate, David Foley, to tell us more about how this unique project is shaping up and what the results of his yearlong collaboration with RollOut IT are.

David told us that through the massive, decade-long history of developing Relate, there was a clear dividing line: to promote worldwide adoption, David wanted it to become truly global and platform-independent.

The key challenge: going full web

‘We decided that to move forward and have a worldwide adoption, something that is really easy to add up and very easy to increase in number, we needed to go web. It’s very hard to bring that type of thing in the web because it’s very graphical. So we needed to have something very efficient and very innovative with the current technologies. And this is where Bíró came in, and we designed the full thing in web, using RUST.’

Bíró, meaning David Bíró is a Rollout IT developer and RUST enthusiast. (Check out this video where he describes what his favourite programming language is capable of!)

His contribution is helping Relate to basically kind of ‘bypass’ the normal web.

‘We create a full system that draws things on screen where we want them to be, because what we build is not just like HTTP, it’s very different. So we redesign a full thing that runs in the web.’

Bíró’s experience with Rust helped the vision of Foley come alive in a new, scalable way. He helped the team get better at Rust and also helped in making some key decisions during the design process.

But why Rust?

‘To bypass the normal layout engine of the browser, you need a technology that runs very fast. We went with Web Assembly, a fairly new technology.’ – Foley explained.

‘There are not many languages that are very good to compile into Web Assembly. The frontend was using a C++ framework that was not compatible with web assembly, and event if it could, it would be heavy and would not leverage web browser technologies. And Rust has all this type safety that made it very attractive to avoid some of the bugs we already had to fight in the C++ version. And since we had to build the thing from scratch, we might as well go with new technologies that are picking up and very interesting. It’s a pain when you start using it because all the things that it forces you to do, to be safe. Once you get the hang of it, you can really like it!’

Based on this experience with Rust, Foley thinks it’s here to stay and it might get even more popular:

‘I think Rust is going to be a main language, not replacing any others very fast, because it’s a very big war, but it’s definitely got a place and it’s there to stay, pretty sure. It brings forward some new ways of thinking about programming. And it’s good for the computer. It’s very efficient and pretty easy to use. It actually has been designed for more back-end-ish, and server stuff, but it worked very well for the front end, surprisingly.’

‘It forces you think about the different categories of things you are doing. When I went back to Python, I was looking at my code and I was like: >> Okay, this is not so clean. << So there’s also this idea of Rust pushing forward a lot of practices.’

The Relate-project, and Rollout’s involvement: the Architecture

When asked about how far off Relate is from its creator’s vision, Foley remains stoic:

‘I still have notebooks. So the goal is not there yet. We need to have something even smoother, integrate more stuff. But it’s the basics, the platform that we’ve designed now, it’s all there to be able to support a lot of the next things. So there’s a roadmap ahead, but it’s ready to go forward.’

Foley describes Bíró as ‘almost like if we had hired a mentor for coding in Rust. And he was also extremely helpful in other technologies like React.‘

They had to build a web system, but part of it is data, that doesn’t need to run on Web technologies, but the module talking to the Web, the browser, that was Bíró’s work. It is taking the raw data and making it show on screen as lines and graphics inside a React container.

In Foley’s words, ‘a fairly complex piece of software, and he made it work gracefully.’

One of the main challenges during their collaboration was that they had to architect the software. It was different to C++. Foley describes the process as ‘challenging each other with design principles’, and as an expert with 15 years of experience in designing from the ground up, he relished this opportunity for mutual learning and growth. Their arguments have never been opinionated, because they could just easily share the sources that back their claims up with each other.

‘Sometimes it’s challenging to be argued when you’re not used to it. But I think he found it challenging too, because I was arguing about some of his designs. But it made us move forward, I think in a very thoughtful direction, because both of us knew that the code we write should be clean, else the other will give feedback about it…’

Obviously, Foley started working on the architecture in Rust, while still learning it, way before he started working with Bíró. He wanted to keep working on the back-end part of the front-end, the layout and structuring of data, because he felt that it requires all the knowledge about the data structures that are particular to Relate. So Bíró moved to the other part, where the graphs of information are drawn on the screen in realtime. From the moment they had two distinct systems running, it was pretty well defined that Bíró would mostly work on the ‘renderer side’, as the Relate team refers to it.

However, from time to time, they turned to Bíró to solve specific ‘Rust problems’, how certain things can be done well in this language. That also meant that often Bíró and Foley have often found themselves engaged in researching how certain modules could be refactored and connected. As the system grew, they started to understand better which blocks should be separated. Once a block was separated, it was easier to work on it in parallel.

One example for these ‘blocks’ would be the one which communicates with the backend via special protocols, they call that the Remote Procedure Call mechanism. This block feeds information into the Presenter, which contains other parts, like a semantic graph, these represent the knowledge. And then, there is the Layout Engine that transforms that to a visual graph which describes how things should appear on the screen. This is the final output that is received by the Renderer and it goes to the Web, almost like a Domain Object Model.

One of the biggest parts of Bíró’s contribution was translating these into draw calls that will appear correctly and in realtime on the screen, in the Web.

The collaboration with Bíró has now finished, mostly due to budget constraints, but the project is also moving forward into the next phase. The passion and dedication of Foley is contagious. He wants to give everyone, from school teachers to top researchers a platform-independent Web tool for organized work. And he is getting close.

‘We need something that’s more powerful than opening 50 tabs of web and trying to keep everything open everywhere because you need more memory. We need something that’s more powerful that helps mimic how the brain is organized. So, that was the idea of my Phd. I wanted to study the brain, study how we learn, study how we work, study how we collaborate. Many scientific fields research these subjects, but they are mostly separated, the brain stuff, the language stuff, but I’d like us to try to understand all of that and reinvent a system that will really touch on every one of these.’ – he explains.

Relate is really unlike anything we had the pleasure of working on, and we hope we get the opportunity to get involved again, being a part of a true user interface revolution.

Book a call or write to us

Or

Send email

By clicking on ‘Send message’, you authorize RolloutIT to utilize the provided information for contacting purposes. This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Vibe Coding is the process of developing AI-driven applications in a flow-based, intuitive manner, where developers build prompts, logic, and workflows rapidly, often without writing traditional code. This approach emphasizes creativity, flexibility, and speed, allowing teams to iterate quickly without being constrained by traditional development lifecycles. Focuses on rapid iteration, natural language, and modular building blocks. Popular in environments using LLMs, chatbots, and generative AI products. Empowers non-traditional developers (project managers, designers, analysts) to prototype AI features. Encourages exploration and experimentation with model capabilities. Lowers the barrier to entry for creating intelligent systems.
Many enterprises struggle with outdated systems that don’t work well together. As businesses grow, they add new software and tools, but without a solid integration strategy, these systems become disconnected and difficult to manage. Traditional development often treats APIs as an afterthought, leading to slow development, high maintenance costs, and limited flexibility. API-first development takes a different approach. Instead of building software first and figuring out integrations later, it starts with designing APIs as the foundation. This ensures that all systems, whether internal tools, customer applications, or third-party platforms, can connect smoothly from the beginning. The result? Faster development, easier system upgrades, and a more scalable, future-ready architecture.
By 2025, the mobile learning market is expected to reach around $94.93 billion and is projected to grow to $287.17 billion by 2030, with an annual growth rate of 24.78%. With smartphones becoming more widely accessible, mobile learning (m-learning) has become an essential part of modern education.  This rapid growth reflects a shift in how people access education, making learning more flexible, interactive, and personalized. Whether it's students looking for supplementary resources, professionals upskilling on the go, or educators seeking innovative teaching tools, mobile learning apps have revolutionized the way knowledge is shared and consumed. As technology continues to evolve, the demand for well-designed and engaging educational apps is higher than ever, shaping the future of learning across all age groups.
By 2025, the mobile learning market is expected to reach around $94.93 billion and is projected to grow to $287.17 billion by 2030, with an annual growth rate of 24.78%. With smartphones becoming more widely accessible, mobile learning (m-learning) has become an essential part of modern education.  This rapid growth reflects a shift in how people access education, making learning more flexible, interactive, and personalized. Whether it's students looking for supplementary resources, professionals upskilling on the go, or educators seeking innovative teaching tools, mobile learning apps have revolutionized the way knowledge is shared and consumed. As technology continues to evolve, the demand for well-designed and engaging educational apps is higher than ever, shaping the future of learning across all age groups.
In modern software development, Continuous Integration and Continuous Deployment (CI/CD) have become essential for delivering high-quality applications at speed. By automating the development pipeline, CI/CD solutions reduce manual effort, minimize errors, and enhance software reliability. These solutions help organizations scale efficiently while ensuring robust software releases. This article explores the significance of CI/CD, its key components, popular tools, best practices for implementation, and technical considerations for DevOps engineers and agencies, including advanced topics such as Infrastructure as Code (IaC), security integration, microservices deployment, and multi-cloud strategies.