I'm Caly Heasman, Developer Advocacy Director
here at DocuSign.
Normally, in our developer deep dives,
we talk to other engineering teams
within DocuSign about the tools and products
that they're working on.
But today is going to be fun.
We're going to do something a little bit different
and talk to one of our own engineers on the Dev Center.
[MUSIC PLAYING]
Today, we're going to be talking about our new developer center.
And for those of you who haven't visited it yet,
you can go to developers.docusign.com
and check it out and see all of the changes
that we're going to be talking about here today.
And joining me here today to talk
about all of these new changes that we're doing
is the lead engineer on the Developer Center
team, Alex Cooper.
Welcome, Alex.
Hey, thank you for having me.
No problem.
We're excited to talk to you about this.
So before we dive into the nuts and bolts here,
I have to ask my first question, which is why?
In my opinion, the developer center
was already pretty perfect, of course.
So why did we do this revamp?
Great question.
And I agree.
It achieved its original goal, which
was to get us off of the traditional Drupal-based CMS
and to use an in-house headless one instead.
While it was running, we used this opportunity
to gather feedback about our information architecture,
performance SEO, stuff like that,
and the kind of channel we learned to the new platform.
Yeah.
And I know that this also came at a fortunate
time for DocuSign where we were doing an overall rebrand.
And in addition to that, we got our own developer specific
branding that you guys were able to incorporate into the look
and feel of the new Dev Center, correct?
Absolutely.
And on top of incorporating the new UI,
we felt it was a great opportunity
to overhaul the UX in general.
Let's talk about under the hood, though.
So aside from the sort of aesthetic and UX updates
and changes, which are significant
and which are awesome, let's talk
about the major technical changes that you guys made.
What are some of the major architectural decisions
that you made for the new site?
So I would say the single largest
one is the architecture under the hood, given
that the old site was an isomorphic react app.
For those of you who are watching this
and maybe don't know what that means, Alex,
can you talk a little bit about an isomorphic app and sort
of the significance of that?
Yeah.
So your traditional react application-- what happens
is when you're web server receives
an HTTP request, that is when your page starts
getting rendered.
Isomorphism is a way to optimize this
by offloading some of that rendering process
onto the web server.
So it's split between the client and the web server.
However, even though we're optimizing it,
we're not addressing the underlying root cause here.
Yeah.
So I know we had some underlying performance
issues that you guys were trying to address with this.
Talk to me a little bit about that.
How were we able to address some of those problems
with these changes?
Yes.
So when we started to hit scale, we
were noticing large initial payloads, as well as
subsequent increases in that secondary rendering phase
that you see in the isomorphic apps.
We found ourselves spending a lot of time hand crafting
optimizations to deal with our infrastructure
as opposed to building out new features.
So one example of this was we converted a good portion
of our site to static, which, even though it alleviated
our immediate performance concerns,
presented other challenges.
It sounds like you guys just got to the point
where you decided, chuck the whole thing.
Let's start over, and let's start
with a better architecture.
And in this case, for you guys, that meant a jam stack, right?
So talk to me a little bit about what is that tech stack,
and how is it helpful for you guys?
The real problem that we needed to solve
was offloading this big render phase.
And so one of the things that jam stack does
is it moves us to the build time.
And what happens is that we do this pre-rendering
and then produce a bundle of highly-optimized HTML, CSS,
and JavaScript and serve that from our production web servers
instead.
Site speed is very important to developers,
when they're trying to get more information off the site
and find the correct pages.
So I know that made a big difference.
Can you talk to me a little bit about some
of the sections of the site that maybe previously were
static, but were moving to more dynamic pages?
Yeah.
So a big candidate for us back when we made this transition
to static was eSignature REST APIs reference
due to its sheer size.
And so if we click around here--
so here I'm at the old site.
And as I'm clicking around, you'll
notice that it's actually pretty snappy compared
to maybe other regions.
And that is because it is static HTML.
In contrast, if we go to the new site, and I click around,
this is fully dynamic, and we're still
seeing a similar performance.
And this is extremely important for us
because even though the performance of the static pages
is great, it's going to hold us back from future development
that we want to add in.
Can you tell me a little bit about maybe
what some of those features would be?
What are we planning to put on some of these dynamic pages
that we couldn't have before?
Yeah.
So we have another product called the API Explorer,
which is a tool that allows engineers to fire off
API calls.
One of the biggest things we want to do here
is pull that in to these pages, so your developer
can make these calls side by side to the documentation.
Awesome.
So as I'm going through the reference documentation,
and I'm looking at individual endpoints,
I will actually be able to test those out, see the requests
and responses without ever leaving the documentation page,
right?
Exactly.
Little coder pad will take care of everything for you.
And I know we had some overall goals, too,
in just evolving the Dev Center and making
some of these changes.
Where are you guys really trying to go with this?
At a high level, it's a whole new philosophy
of how we're looking at the site, right?
Instead of being a repository for documentation,
we really want to take this to the next level
and create sort of a place where developers can come,
try out new features of the DocuSign cloud,
and test out different tools, and code right there on site.
So really, less of a documentation
warehouse and something a little bit more fun
and interactive for people to really test things out.
Exactly.
All right.
Before I let you go, I would love
for you to show me a demo here.
And just walk me through some of the workflow side
by side so people can really get a feel for what has changed
on the new Dev Center site.
So if I start with the old site here on the left,
and I navigate to just eSignature REST API,
you're going to start seeing this isomorphic behavior.
You're going to see this momentary spin that
happens in the middle of the page and kind of this sort
of two-phase rendering process.
In contrast, if you go to the new site--
and I'm going to do the same thing here, just navigate
to APIs, eSignature REST API--
and you'll notice that it's quite a bit snappier.
We're not seeing the second spinner on every page load.
And as we click further and further,
this prefetching cache behavior over Jam platform
really takes into effect.
And we start getting near-instantaneous page loop
times.
All right.
Thanks for the demo, Alex.
And thank you for joining us today.
Thank you, Caly
See you all at our next developer deep dive.
If you like that video, be sure to subscribe
to our channel for the latest DocuSign developer content.
If you want to see a specific topic in a future video,
comment below.
For everything else, visit the DocuSign Developer Center.
[MUSIC PLAYING]