What Does Orbit Do?

Viktor: Yeah, I had to show my credentials that I’m also technical, and I'm not just a talking face. And of the many things that we do, one is all about learning our users—learning what they do and how we can help them better. And specifically, you know, how we can help the better we understand their problem first. There are plenty of places on the internet where people complain, and Orbit helps aggregate those places where the people complain so we can understand where to find the available information.

Ben: Exactly! Where they complain, where they discuss things, where they share feedback and ideas.

One of the fundamental principles that we believe in at Orbit is that community doesn’t just happen on a single platform.

Community happens on a Twitter thread. It happens in Discourse. It happens on Discord. It happens on Stack Overflow questions and answers. It happens on Reddit subreddits. It happens on comments on YouTube.

It can be hard - and this is something I get a lot of feedback on - to understand a single member of your community across all the different places they exist. One of the cool things that Orbit does is it gives you that aggregated, collated member unit across all those platforms. So it’s a single member with multiple identities, and it's a one-to-many relationship. You have a single member, and they can have an identity on Stack Overflow, several blogging platforms, GitHub, GitLab, identities all over the place. We bring those all together for you and offer analytics and reporting to help you engage and understand their particular needs in a bit more of a coherent fashion.

Viktor: It sounds like a real-world implementation of the meme where there's a bunch of pictures showing “this is me on Twitter,” “this is me on GitHub,” “this is me on LinkedIn,” “this is me on Instagram.” The different photos show the person looking professional in the LinkedIn picture, but like more on the beach with the glass of some drink on the Instagram picture. So that’s exactly what Orbit does, essentially.

How long have you been with Orbit at this point?

Ben: As you know, there are human years, and there are developer advocate years, and they’re not the same. In human years, I’ve been at Orbit for about six months. And in that six months, we have done so much. We’re a very fast-paced, nimble startup. When I joined, I was employee number 10, and now we’re on the cusp of about 25 employees or so in the past six months, which in real terms is a lot of growth really fast. And it’s been an adventure.

Establishing Developer Communities

Viktor: The reason for this question is to understand what you learned. Maybe like some of the three fascinating facts about where the people interact more or where developers interact more. Do you have some eye-openers and some things that you've learned?

Ben: It’s actually quite interesting, and I've discovered that there isn’t a one-size-fits-all perspective when it comes to this.

Every kind of niche developer community has its own niche platforms in which it exists and preferential spaces that they kind of occupy.

Without over-generalizing too much, game devs occupy certain spaces more than financial services developers might occupy. And communities that run developer tooling might occupy different spaces. That’s kind of the macro level.

On a micro level, even different product lines and tooling within the same space will have a different emphasis, depending on what they do. A lot of that depends on where you, as a company or product community, initially invest in creating spaces. A lot of product communities make a scattershot approach when they’re first starting. So that means you’ve created a lot of disparate spaces for people to exist on. Then it becomes a bit more challenging as you grow and gets exponentially harder as you keep on growing to manage all those different places. That’s one side.

The other side is you. You may have been very focused initially, and you may say, "I only want to generate conversations on Discourse," for example. But then your members start going on Twitter all the time and raising questions, and they get feedback on there. So they’re getting that sense of responsiveness to those questions. And suddenly, Twitter becomes a more active space, even in ways you haven’t or didn’t necessarily anticipate or even necessarily want.

Some of it is you lead the community, and others the community is leading you—you have to be in the moment with them and understand where it’s happening or where it’s growing organically.

So that didn’t fully answer that question…

Viktor: That’s actually a perfect answer. When you try to build a community, to quote Jeff Goldblum, “nature will find a way,” from Jurassic Park. The user will find a way how they can organize. What’s important to understand is that if they self-organize somewhere, you just need to help them. So do not try to break this habit by steering them somewhere else. Just be there where they are. That’s your purpose.

Ben: So true.

Viktor: If they’re not where you want them to be, eventually they will be. But that requires trust and patience.

Ben: It’s so true. That’s such a good point.

How Orbit Consolidates Community Platforms with APIs

Viktor: So that’s my rule of thumb when thinking about where to interact with our users.

So since we’re talking about all these communities and places, integrating this stuff would be hard. You need to parse the HTML pages manually, and that's how you do it in the modern days. Just start scraping the pages and analyze these pages, right?

Ben: [Smiles] Exactly. The big proposition that the product took was that you give us data, and we will help consolidate it, aggregate it and present it to you in a meaningful way through reporting and analytics. That’s a huge proposition to take, which means we need to be capable of absorbing and offering you multiple pathways to bring in that data from what is honestly an ever-growing list of community tools.

One of the biggest lessons I’ve learned in the past six months is that so many community platforms pop up all the time.

I’ll give you one example, which from my own ignorance, I didn’t even know about until a few months ago, was a platform called Circle. I don’t even know if you’re familiar with it?

Viktor: No, I haven’t heard about it.

Ben: I had no idea about it. Suddenly, I was getting community as a product coming and asking how we can create integrations and connectivity between the interactions happening on Circle and feeding that into Orbit to help give a more comprehensive picture of their users and user engagement.

The first thing I had to do was go to my search bar. I’m like, “What is Circle?” And then, that reality TV show from Netflix popped up first, and I’m like, "No, not that Circle. A different circle."

Viktor: Naming is incredibly hard. You know…

Ben: Naming is ingenious sometimes.

Viktor: During early Web 2.0, we understood that the startup services should have something like "er" at the end. Twitter, Tumblr…

Ben: Yeah.

Viktor: And usually, you throw in some of the letters there, so it looks cool. But now it’s getting ambiguous, like with the Circle.

Ben: I remember the 90s, and everything had to have an "e" in front of it to be a real digital service.

Viktor: You know, like eShop. I still remember some of the IBM computers and services are ready for eBusiness. Oh okay. It’s no fun here, and it's just business here…

Ben: Exactly.

Viktor: For the people who were thinking, "Victor’s talking about scraping the internet." I was joking because it’s a podcast about connectivity and APIs. We’re living in the world post-Web 2.0 era. And one of the components of a Web 2.0 service is exposing the APIs. We're looking to integrate certain systems through sets of APIs. And that’s where we want to spend some time next.

So does the Circle platform have an API so you can easily integrate it with your platform?

Ben: Circle has an API. Using that example, which I think is a good example of SaaS products' evolution nowadays, as you just said, they all have to have an API that goes along with them that’s externally accessible and available. Here’s a relatively new community platform that offers a lot of value to its members. They want to integrate that data, and immediately out of the box, they offer API functionality to their users.

So you don’t have to scrape the website. You don’t have to try and use NoSQL or something to try and find the HTML tags and get the data. There’s a REST API that you can use—sometimes it’s a REST API, and sometimes it's a GraphQL API, kind of depends on the engineering team and their preferences—but whatever it is, it’s usually there. It may require OAuth or require a Bearer Token. As long as it’s secure is really what’s most important at that point. But it’s there. Yes.

Viktor: And what’s most important with the emergence of the protocols, like OAuth, is not about security but about understanding what access you as a user provide to the service.

I think about some of the presentations when the people start explaining OAuth, and they often bring up the old times of Yelp when they would ask you to enter your email and password to send emails about this new cool service called Yelp to your contact list. And the protocol, like OAuth, actually helps users understand what kind of data APIs will be able to share. So when you connect to these platforms, those API levels will be graded by certain access. You can access a certain API so you can have access to a certain API. You can restrict this as a user and the owner of this data. And most importantly, who will be able to see it.

This is becoming more important in recent years based on what happened at Facebook and how this data was used…

Ben: There were issues with Facebook?…[Laughs]

Viktor: I don’t have issues with Facebook. I do have Facebook, but I don’t really use it, and I kind of have been happy about this.

Ben: Your life is probably a bit better for it.

Viktor: But I still cannot give up Twitter. It’s my thing.

Raw APIs vs. SDKs

So speaking about the API, what’s your take? Do you prefer raw APIs or SDK? Since you have a view as an expert being an engineer and the developer advocate working with companies who provide APIs, you now work with the company that consumes the API. So what is your take on this?

Ben: So actually, we do a bit of both. We consume APIs, and we provide an API. So we’re kind of in that middle space.

I think you have to answer that question by asking another question: What is the need you are trying to solve for your users? An API is a tool to help accomplish a need.

So first, you have to wrestle with that primary question. At the most fundamental level, the answer to that primary question is that you’re trying to help your users accomplish and solve problems as expeditiously, painlessly and maybe as enjoyably as possible. If those are my goals and I have a few tools in my tool belt, I think I need to solve that with the tools I have. My goal as a developer advocate is to help my users do that. Solve things expeditiously, painlessly and joyfully.

SDKs abstract a lot of that work out the developer's domain building something, so they don’t have to worry about the peculiarities of the API or figure out pagination because every API does pagination a little differently. They don’t need to think about all those little nuanced details. They only need to think about solving the problem. What is the function or method that I can invoke in this SDK to accomplish that for myself? The SDK helps me do that in a faster, more expedited and easier way than just making the HTTP calls to the API myself. If the API only makes HTTP calls to an SDK, and that’s all it does, I would argue it doesn’t serve a purpose. Most developers can write HTTP calls in whichever language they’re developing in. An SDK’s goal is to do a lot more about that. It’s to wrap that and provide another layer of handling errors and handling pagination and thinking about how to handle when things go wrong. Take that off the developer's shoulders so they can focus on what they’re building and less about the tool they’re building with.

Viktor: That makes total sense. I like your answer because it’s a little bit of both. Sometimes when people are just starting to do something, they want to have a fast track. Properly designed SDKs will have some idiomatic constructs that people will easily grasp in their language. An SDK should not do more than you can do with an API. So everything that you consume still needs to be available through an API in case people decide to come up with some alternative implementation or whatnot.

Ben: Absolutely.

Exotic APIs in the Financial Services industry

Viktor: So let’s talk about this a little bit. What’s the most exotic thing that you’ve seen in terms of what a service is exposing…SOAP or like XML RPC?

Ben: Honestly, nowadays, I don’t find a lot of those exotic APIs so much. They’ve kind of standardized. How about you, Viktor? Do you still see any of these exotic APIs out there in the wild?

Viktor: Unfortunately, not every bank is exposing the APIs that we want to consume. Instead of using OAuth, some banks still require you to provide a username and password. That’s unfortunate. Fellow developer advocates and business owners in the financial industry should think about this. It’s a huge opportunity. Banks and financial institutions have always been more conservative about the use of technology. So that’s like most exotic things that I see in the real world, and I’m still like, “Really? In 2021, you cannot provide a normal API?”

Ben: If I see abnormal authorization patterns, almost like dark patterns or anti-patterns nowadays, it throws me off, and I will stay away from that API. Because what else is going on wrong there? I don’t want to talk too much about working in the financial services industry because I have a lot of things to say about it that I probably can’t by legal contract. Still, there's a lot of stuff that happens under the hood that you see as an engineer working in one of these companies that would make you second guess doing business with the financial services world at large. Not to say one specific company, but just at large.

But having seen that, it’s kind of like when you’re a cook in a fast-food restaurant; you never want to eat in the fast-food place ever again. It’s kind of a similar experience, but those are red flags for me.

Viktor: Yeah, I agree. Not enough investment into modernization. But anyway, I think there’s opportunity there, and there are leaders who understand this and are finding ways to make the world a better place in financial services.

Subscribe to Kongcast to learn more about this topic in our next episode: "Keeping SOAP in the Back With the Mullet Pattern."

Problems Orbit Solved With GitHub Actions

So let’s talk about some of the technicalities and how you would integrate this for Orbit.

Ben: There were a couple of problems we wanted to address.

We wanted to enable people to build tooling to connect third-party APIs and their data to Orbit.

And we wanted them to be able to build that tooling in whatever language they wanted to build in. So if they were a Node.js developer, build an npm package; if they were a Python developer, build Python packages; if they were a Ruby developer, build Ruby gems. We didn’t want to privilege and say, you have to build this in this language. So that was one problem.

And the second problem was we wanted these integration libraries to be as accessible as possible.

Understanding that our audience encompasses people from the most senior developers - principal level developers - to people who are just opening a code editor for the first time in their lives, to people who are in that no-code, low-code and indie hackerspace who maybe have varying levels of comfort with code or no comfort with code and yet need to integrate this data for either personal reasons or professional reasons.

So we wanted to build something that would accomplish all of those goals, and those goals all seemed kind of hard to be able to accomplish at once.

But we were struck by a service offered by GitHub called GitHub actions.

If you’re not familiar with it, it’s basically a runtime environment provided by GitHub. It provides to every account 2,000, I believe, runtime minutes a month, which is quite a lot. Unlimited runs, unlimited repos you can run it on in your GitHub organization or GitHub account.

You can do a lot with GitHub Actions. Most people who have seen GitHub Actions will have seen it in the context of workflows running their CI/CD deployments, like CI checks, testing suites, managing release flows, things like that. But there is so much more you could do with GitHub Actions.

It’s pretty agnostic as far as what you choose to do with it. We decided that we would make GitHub Actions one of the prongs of our tooling.

What’s cool about GitHub Actions is that the runtime environment supports almost every language a developer writes in today, which accomplishes that first problem.

So you can write your tool in basically any number of languages. Maybe not COBOL, but you can write your tool in any language today and be happy and enjoy writing. It can run on an Actions runtime environment. We won't have to say you have to write these tooling in X, Y or Z. You could do whatever you want to accomplish the first step, which opens it up to the devs to write in whatever they want.

And the second thing was making it accessible, and we did that essentially by offering GitHub Actions as a third way to use the libraries.

And I could show that in the demo.

Demo: Integrating Services in Any Language With GitHub Actions

In every Kongcast episode, we ask our guests to show a cool tech project they've worked on lately. Check it out in the below video:

Thanks for Joining Us!

I hope you'll join us again on November 15 for our next Kongcast episode with Aaron Weikle from Mountain State Software Solutions (MS3) called "Keeping SOAP in the Back With the Mullet Pattern."

Until then, be sure to subscribe to Kongcast to get episodes sent to your inbox (and a chance to win cool SWAG)!