When building a new product, you suddenly face countless challenges and decisions. Sadly, there's no magic formula for making the right choices, whether you're just starting out or are a seasoned entrepreneur. Having walked this path several times as a team, we understand the excitement and worry it can bring. We are a small team that recently launched , a global network testing platform. This project is special because it is our second attempt after a startup with a similar product idea didn't reach the desired outcome. With Globalping, we're taking a different approach to reach our goals and vision for the product. Globalping In this blog post, I'll share insights and learnings from our experiences with the startup and how they influence our approach at Globalping. In particular, I'll write about why we built a JavaScript-based open-source platform and how these choices have transformed the project. Reflect and Learn: Growing From Past Experiences Let's go back a few years to when we founded a startup called PerfOps. The idea was to build a B2B SaaS platform for optimizing Internet-based applications. It used RUM (Real User Monitoring) data to gather performance metrics on CDN providers and enable Multi-CDN load-balancing functionality. As a bonus, it also allowed users to run network measurement requests like traceroute and dig from different locations worldwide. Like many startups, we needed funding. Luck was on our side as we received VC backing, allowing us to build a team and rent hundreds of VMs (virtual machines) to build a global network for on-demand network testing. As a result, we could develop new technologies to analyze billions of RUM data points and utilize them in DNS-based load-balancing in real time. While this venture didn't work out as envisioned, the experience gained was invaluable and shapes Globalping's path today. Some takeaways: : VC investment urged us to change the pace and priorities of our work. As we focused on meeting metrics to secure the next round of funding and shifted our priorities from small businesses and single users to larger enterprises, we felt the joy and enthusiasm for our idea fade. Pressure dampens passion : Developing the product to meet investor expectations often didn't match our vision of building what our users needed. Focusing on what the users want and need is important as long as you understand the industry and market, something that our investors had no experience with and pushed to improve different metrics and priorities that were incompatible. Building for users . While useful in large amounts, it quickly became apparent that most Real User Monitoring (RUM) data were problematic and not ideal for debugging networking issues. You could never know whether the problem lay with the CDN or the client running the test. Plus, RUM data is not reproducible; once a test has run, there's no way to re-run it from the same location to assess the impact of your changes. RUM data is unreliable . As a VC-backed company, we had to keep all the code and data under wraps and hidden from the public. Our users could never verify the authenticity and accuracy of the data shown to them. Moreover, anyone could claim that we manually changed the performance rankings in favor of high-paying customers without being able to prove the opposite. Black boxes don't help But even after the unfortunate fate of the startup, we still saw the potential and need for accurate, open, and reliable network testing and performance monitoring. And so, Globalping was born, a second chance to do things differently and draw from experiences to create a better service for our users and ourselves. Now, let us share with you how we do that. Embracing Open-Source & Putting Users First We believe it was a natural progression to make Globalping an open-source project. For once, we’re already familiar with the concept. We've been running for about 10 years, a free, open-source, multi-CDN service that serves more than 230 billion monthly requests. jsDelivr So we already knew the pros and cons of open source, what to do, and what to avoid – the more we thought about it, the more it made sense that Globalping must be open source. The main reasons to make Globalping open source were: : Most people who contribute to the project also use it. So they help build their own tool and get the desired features by contributing their skills or simply giving feedback. Also, Globalping grows with its community because instead of renting VMs to build the test network, we rely on the community to host Globalping probes in their homes and offices. Leveraging the community : Building a community doesn't happen overnight. Luckily, we already have a great community supporting our other project, jsDelivr. Many existing users and supporters can join Globalping because of the technical overlap: jsDelivr provides globally distributed infrastructure, and Globalping is a way to monitor, test, debug, and compare such global systems. Utilizing jsDelivr : With the pressure of growth and profit reduced, we can now focus on building a platform that is accessible to all. The platform is free, with generous limits, offering the same features to everyone, whether they're a huge enterprise or a student just learning how the Internet works. Building for everyone : Open source makes our work transparent and visible to all. Anyone can review our code and logic, be it our probes or core API. This helps us validate our security and privacy claims and reassure users that we're fair and not selling ratings or using biased algorithms to calculate CDN performance. Also, any person or company who finds an issue with the code or functionality can submit a patch, requesting to add their update or fix. Being transparent Naturally, open source also has its challenges. Product development requires developers, designers, marketers, and developer relations experts. And while we have the support of tech experts from our community, we still work with a core team that's compensated for their work. Instead of relying on VC funding, we're now building partnerships with like-minded companies and seeking support from GitHub sponsors, whose donations keep us running. Choosing JavaScript to Develop Globalping The next important decision was the technology we wanted to build Globalping with. We confidently picked JavaScript, relying on our experience in operating large-scale, real-time JavaScript apps. The benefits of our familiarity with the language have already paid off, allowing us to build new features faster and find and fix bugs more easily than with less familiar languages. In addition, among app and web developers worldwide made it an obvious choice for us. The language has a rich and robust ecosystem of tools, libraries, and packages that align with our development goals. By using other open-source projects, we can leverage the knowledge and efforts of the community, avoiding reinventing the wheel. JavaScript's popularity Since JavaScript itself has a vast community, there are many potential contributors to Globalping. And because JavaScript code is mostly straightforward to read, it's easier for newcomers to navigate and understand the source code. As a result, developers can contribute faster, which keeps motivation up and drives the project forward. Ultimately, while our core team continuously works on Globalping, to the platform. By choosing JavaScript, we can maintain an open and collaborative environment that invites anyone interested in making Globalping a helpful and user-friendly network testing platform. we welcome any contribution Using Globalping Yourself or in Your Team Finally, we'd like to briefly introduce you to the Globalping platform and hopefully spark your curiosity to try it out to improve troubleshooting and network testing in your teams! We've developed a variety of integrations to meet the needs of different users, whether they're network pros or newbies. If you are most comfortable in your terminal, use our . Our and are great helpers for teams working together on network issues. Get quick access to measurement results: CLI tool GitHub bot Slack app Finally, you can also use Globalping in a simple and user-friendly graphical interface to run tests when you don't have access to your usual setup, for example. on our website Since we don't want you to learn everything from scratch every time you switch integrations, we've implemented a uniform command structure. In general, all Globalping commands follow the same format: Write commands consistently across integrations: globalping [command type] [target] from [location] [flags] So, for example, to run ping to from Vienna and Berlin using two probes (defined with the limit flag), you write the following command: jsdelivr.com globalping ping jsdelivr.com from "Vienna, Berlin" --limit 2 And this is what the result could look like: Want to build your own tool using the Globalping platform? No problem – you can use our REST API (with generous limits) to create whatever you want! Create your own tools with our API: Globalping relies on a globally distributed network of probes powered by our community. We're happy to welcome anyone who at their home, office, or servers to help deliver reliable results to all users for free. Become part of the network: sets up a probe in Docker Looking Ahead: Building Globalping Together Today, we're happy to see how evolves and grows, shaped by our past experiences and learnings. Eventually, we hope Globalping will become the go-to platform for anything related to Internet performance, latency, and uptime. Globalping We'll continue refining features and delivering a great user experience so anyone interested can use the platform.

Too Long; Didn't Read

Making security fun one episode at a time

The Power of Open Source and JavaScript: The Journey of Globalping

Too Long; Didn't Read

Globalping

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

The Power of Open Source and JavaScript: The Journey of Globalping

Too Long; Didn't Read

Globalping

About Author

TOPICS

Languages

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES