www.apimatic.io Open in urlscan Pro
40.113.232.243  Public Scan

Form analysis
0 forms found in the DOM

Text Content

 * Product
   
   * SOLUTIONS
     
     DEVELOPER EXPERIENCE PORTAL
     
     Maximize API consumption with customizable portals that host multi-language
     documentation, SDKs, API Code Playground and more.
     
     CODEGEN-AS-A-SERVICE
     
     Automate SDK and doc generation on each API update by integrating Code
     Generation into your CI/CD build pipelines.
     
     API TRANSFORMER
     
     Unlock a whole array of tools available for each API specification format
     by converting your API definition into more than 10 supported formats
     
     FEATURES
     
     ENHANCE YOUR API'S DEVELOPER EXPERIENCE VIA THE FULL SET OF FEATURES
     INCLUDING:
     
     SDKs/Client Libraries
     
     Dynamic Code Samples
     
     Package Publishing
     
     API Specification Merging
     
     Assisted Authentication
     
     API Specification Editor
     
     API Specification Conversion
     
     
     View all features
     
     INDUSTRIES
     
     Fintech
 * Pricing
 * Enterprise
   
   * APIMATIC ENTERPRISE
     
     Customized Developer Experience solution. Generate SDKs in a special way,
     or Docs in a certain format.
     Learn More
     Contact Sales >
     
     APIMATIC FOR MULESOFT ANYPOINT PLATFORM™
     
     APIMATIC FOR REDHAT
     OPENSHIFT
 * Resources
   * Documentation
   * Changelog
   * Success Stories
   * Events and Webinars
   * Videos
   * Podcasts
 * Blog
 * Company
 * Login
 * Signup For Free

PODCAST

DON’T USE OUR API, USE OUR SDKS FOR BETTER DX

Guest: Brian Rinaldi

 1. Art of DX Podcast
 2. Episode 2

Brian Rinaldi, Developer Experience Engineer at LaunchDarkly joins us on this
week’s episode of the Art of Developer Experience. We discuss the role of SDKs
to enable integration of feature flags everywhere LaunchDarkley’s customers want
to use them. Brian’s work focuses on creating technical guides, code samples and
tutorials to support emerging technologies. Since feature flags can be used in
so many places, Brian comments on the challenge of supporting so many developer
communities.

Read Transcript

Note: This is an edited and condensed transcript of the podcast and will differ
slightly from the original recording.

Interviewer (Sid Maestre): Today, I’m very happy to be joined by Brian Rinaldi
from LaunchDarkly. Brian, thanks for coming on the podcast today.

Brian Rinaldi: Thanks for having me, Sid.

Interviewer (Sid Maestre): Can you share with me how you got started in the tech
industry and your path to becoming a developer experience engineer? I believe
it’s a relatively new job title, so I’m curious to know your thoughts on that.

Brian Rinaldi: I started my career as a history major in college during the
dot-com boom and began building websites, running conferences and user groups,
and writing articles. That led me to a career in developer relations over a
decade ago, and my first role was with Adobe. Since then, I’ve had other roles,
all dev rel-ish, which is a term I use to encompass the various job titles in
developer relations. At LaunchDarkly, where I currently work, the focus is
slightly different than pure dev rel. While I still do public speaking, my role
is more about creating solutions that improve people’s experience when getting
started with LaunchDarkly. A lot of what I write is about integrating
LaunchDarkly with different frameworks or languages, making it easier for people
to get started.

Interviewer (Sid Maestre): As an interviewer, I like to ask my guests what their
definition of developer experience is because I believe that the industry is
still trying to define it. So, I’m curious to know what your thoughts are on the
topic.

Brian Rinaldi: I completely agree that developer experience is a broad and vague
term and it varies from company to company. At LaunchDarkly, my focus as a
developer experience engineer is to make it easier for developers to onboard and
use our product. This includes providing resources and tools to help streamline
the process and improve the learning curve. Documentation is a significant
aspect of developer experience, and I contribute to our docs even though we have
a dedicated docs team. While some companies may focus more on developing tools
to ease the onboarding process, my role is more content-focused.

Interviewer (Sid Maestre): I’m interested in hearing more about LaunchDarkly’s
products and the problems they solve for developers. While I’m familiar with the
company and have even used it at previous companies, I think it would be
beneficial for you to give me a summary of your products and the specific issues
you address for developers.

Brian Rinaldi: LaunchDarkly is a feature management platform that helps
companies manage their releases in a way that reduces risk and allows for faster
development. As a developer, using feature flags in LaunchDarkly enables me to
work straight off of the trunk without the risk of breaking the build because I
can enable or disable features as needed. This allows for testing and ensures
that the features are released to everyone only after they are tested and
working.

Interviewer (Sid Maestre): I’ve heard of feature flags being used for various
purposes. While I wouldn’t necessarily call it “different editions,” you could
use them that way if you wanted to. Is that the same case with LaunchDarkly as
well where you could turn features on and off for customers based on their
subscription?

Brian Rinaldi: Yes, entitlements are possible with LaunchDarkly and I’m
currently working on a project where we’re discussing how to use LaunchDarkly
for entitlements. This type of use case would involve a permanent feature flag,
as opposed to a temporary one that gets removed after testing. Companies can use
this feature to enable beta programs for specific groups of users and to give
access to certain features while excluding others. This is not a new use case,
and LaunchDarkly is adapting to ensure we have the resources to support it.

Interviewer (Sid Maestre): I was a developer experience director at my previous
company and I worked with folks who were building SDKs and managing our docs and
working on API governance. So for me, that’s what my focus was because that’s
what the company needed.

But I’m curious for you, you said you do a lot of content in your role. Can you,
tell me more about that?

Brian Rinaldi: So, I work on a developer relations team at LaunchDarkly. When I
first joined the company, I was the only person on the team. At that time, the
dev rel team was primarily focused on external communication, like conferences
and high-level thought leadership content, without providing many
practitioner-based resources or actual code to help integrate LaunchDarkly into
products.

Originally, I was mixed in with the docs team and the developer experience team,
which focused on building tools for improving developer experience. However,
after a reorganization, I got moved over to developer relations, which broadened
my focus. I still work on building guides and articles to help companies
integrate with LaunchDarkly, but I also have more responsibility for
external-facing content like conferences, blog posts, and videos.

My first project was creating a guide for using LaunchDarkly with Next.js, where
I walked users through the integration step by step and provided a GitHub repo
as a resource. I still work on similar projects, but my role has broadened a bit
to include more external-facing content. In terms of my title, you could say I’m
a developer advocate, which is similar to a traditional DevRel role.

Interviewer (Sid Maestre): It seems like you have a strong technical focus. I
can relate to your approach of delving into communities, understanding their
needs, and creating sample code. I’m a big advocate of starter apps, so wherever
I go, I always look for ways to make it easier for users to try out the SDKs or
tools we provide. It’s not enough to just give them the code; we need to make it
more turnkey and help them understand how to get started.

Brian Rinaldi: Our SDKs are such a critical aspect of our product that they have
their own dedicated team. As a result, our developer experience team has always
been somewhat separate from the SDK team, even when we were part of the
engineering department. This is because the SDKs have a unique role in how they
integrate with our product.

Interviewer (Sid Maestre): I noticed that LaunchDarkly has a wide range of SDKs
available on their website and I’m curious to learn more about it. Specifically,
there are 14 different server-side SDKs and 15 client-side SDKs, which seems
like a lot. Can you explain the reasoning behind having so many SDKs?

Brian Rinaldi: There are no limitations on which programming languages can be
used with feature flags. Multiple languages can be used within the same project
for different parts of a feature. Using LaunchDarkly’s SDKs is preferred for
implementing feature flags because they provide unique features that are
critical for efficient flag evaluation. For example, when using the server-side
SDK, it pulls down all the rules for all the flags in the environment and stores
them in an in-memory cache, making flag evaluation extremely fast. If a change
is made in LaunchDarkly, it gets pushed to the server immediately, and the flag
can be turned off almost immediately. However, if something outside of what the
SDK does is needed, such as creating a new user profile, the API would need to
be used.

Interviewer (Sid Maestre): When you compare using the API versus using the SDK,
the SDK uses all of the public APIs, but presents them in a user-friendly
interface that includes extra features. While it’s possible for customers to
create these features themselves, it doesn’t make sense to add more complexity
to their codebase when the problem has already been solved. Additionally, since
the company has a stake in keeping the SDK working well for all customers, it’s
in their best interest to maintain and update it regularly.

Brian Rinaldi: I think implementing that on your own is entirely possible, but
why would you want to get into the business of maintaining it? You get all of
that built-in with SDKs, which improves the developer experience. Our SDKs are
not just a pure wrapper over the API to make it simpler to use. They add a ton
of features that you just won’t get if you go directly through the API.

Interviewer (Sid Maestre): I really like how you described the difference. You
could potentially be using three different SDKs inside of the same application
because things are written in different languages by different teams. You know,
that’s why that totally answers my question of why you have such broad support
for so many different languages on the client-side and server-side.

Now, you mentioned that there was a team that owns that. Is that considered part
of your product? Is there a specific engineering team at LaunchDarkly that owns
it with product managers and all that?

Brian Rinaldi: It is a core part of our offering. Yeah, there’s an SDK team that
has a product manager who determines what new SDKs we’re going to work on or
updates to the existing SDKs and so on. It’s such a big task that even a couple
of developer experience engineers couldn’t do it as a side project.

Interviewer (Sid Maestre): It’s interesting that you mentioned how many
developers maintain SDKs on the side for fun, which I think summarizes a lot of
people’s lives. At LaunchDarkly, SDKs are like a first-class citizen as far as
the product goes. This leads me to another question I’ve been curious about:
when our API changes, how do those changes get integrated into all the artifacts
we provide to developers, such as documentation, SDKs, code samples, and starter
projects? How do we manage that at LaunchDarkly?

Brian Rinaldi: Most of the time, the changes we make to LaunchDarkly are small
and won’t cause big issues across the board. The docs and SDK teams are
notified, and we use a tool to track everything. But we are currently working on
a major project that will require a lot of changes and coordination across
teams. There is a master project in place, and I work with the docs team to
update examples and resources related to the change. The SDK team has a lot of
releases waiting to roll out with this big change. We have engineering resources
working on the LaunchDarkly dashboard and the underlying application, while the
SDK team makes changes to the SDKs, and the docs team updates all related
content. Each team has its own leadership, and managing communication across all
of them is essential for a project of this scope. I typically hear updates
through the docs team since my work relates to content and GitHub resources. So,
I don’t have as much insight into how engineering and the SDK team work
together, even though the SDK team is part of the engineering group.

Interviewer (Sid Maestre): I’ve had situations where a product change affected
the API, which flowed through to developers using it, resulting in feedback
about property changes or additions/removals. This caused us to scramble to
communicate and figure out how to make things right or get on the right path. It
seems like you guys have good coordination in place to avoid those kinds of
issues.

Brian Rinaldi: At LaunchDarkly, we have a feature called “feature flags” that
helps us coordinate changes effectively. We are the biggest user of our own
product, so we use it heavily. When we make changes, we first turn on the
feature flags for the people who need it, including myself. This way, we can
release changes to a smaller group of users before rolling it out to everyone,
which decreases the risk of any problems. We gradually turn on the feature flags
for more users, and then move onto Q&A testing. Finally, we release it fully for
everyone to use, including the API, dashboard, and SDKs. This approach helps us
avoid any unexpected problems or poor experiences for our customers.

Interviewer (Sid Maestre): When I visited LaunchDarkly, I noticed that there
were two different menus: one for API docs and another for LaunchDarkly docs. I
was wondering what the reasoning was behind having these two different
groupings.

Brian Rinaldi: In general, most LaunchDarkly users, including developers and
product managers, won’t need to use the API directly. The LaunchDarkly docs
cover how to use the dashboard, manage users, and integrate with different SDKs.
The API docs are for users who need to automate certain tasks or do something
outside the scope of the tools provided. It’s important to keep the two separate
and encourage users to use the SDKs instead of jumping straight to the API.

Interviewer (Sid Maestre): You mentioned that you’re on the developer relations
team and I think that’s a really important part of developer experience as we’re
coming out of this pandemic. What are the plans for LaunchDarkly in 2023 that
you can share?

Brian Rinaldi: We plan on doing more events than we did in the past. My schedule
will be relatively booked with travel and events. We also plan on doing more
streaming, including live video on other platforms such as YouTube. This means
more campaigns and more live and recorded videos. Our goal is to keep doing what
we’re doing but with more events and live streaming. We also plan to run our
community conference at the end of the year, but we haven’t decided whether it
will be virtual or in-person.

Interviewer (Sid Maestre): Do you know of any developer experience challenges
that remain for the company? It really feels like you’ve done a great job with
your SDKs and tooling but I’m curious from your perspective, what challenges
remain?

Brian Rinaldi: One of our biggest challenges is our surface area, which makes it
difficult to have all the necessary tools for integration with different
frameworks and environments. For example, our server SDK is node-based, so using
it in non-node environments like Deno requires some workarounds. It’s something
we’re working on, but getting enough resources to do everything is a challenge.
It’s hard to prioritize where to put our resources to have all the necessary
tools for easy integration with everything. Unfortunately, we just don’t have
the resources to cover every tool one might want to integrate with.

Interviewer (Sid Maestre): Are there any tools or anything that you’re seeing
out there or you’re playing with nowadays that you’re really excited about?

Brian Rinaldi: Astro. It is a static site generator that uses an “islands
architecture” to send only JavaScript for dynamic components and pages to the
client, reducing the amount of JavaScript that needs to be shipped. Astro can
use React, Svelte, Vue components, and more together. It allows for bringing
already-built components to new projects and still benefiting from its
architecture.

Interviewer (Sid Maestre): Thank you so much, Brian, for joining me today. I
loved hearing about your career and LaunchDarkly and wishing you all the best.
Looking forward to seeing you around in 2023.

APIMatic is an API documentation tool that provides a complete set of DX
components such as autogenerated SDKs, API portal, API docs, live code samples,
and more.

 * Facebok
 * Twitter
 * LinkedIn

COMPANY

 * About Us
 * Blog
 * Success Stories
 * Careers

PLATFORM

 * API Transformer
 * Integrations
 * APIs

PRICING

 * Plans
 * Enterprise
 * APIMatic Lite

SUPPORT

 * Contact
 * Terms
 * Privacy Policy

104416


 * Home
 * Product
   
   * Developer Experience Portal
   * Code-Gen-as-a-Service
   * Features
   * Fintech
 * Enterprise
   
   * More about Enterprise
   * Redhat Openshift
   * Mulesoft Anypoint
 * Resources
   
   * Docs
   * APIs & SDKs
   * Changelog
   * Success Stories
   * APIMatic Events & Talks
   * Videos
 * Blog
 * Company
 * Contact
 * ———-
 * Login
 * Signup For Free