and I am rather pleased to introduce another protein talk. As some of you may know, I am kind
of a protein person. So the other aspect of proteins apart from the structure is annotation.
So having a talk about protein from Boralia, I am a Lufjani, so you are physically based
on the VBI, aren't you? You are not visiting, yeah, yeah. So I came with Jai, I think it's the
night coming too fast and over two.
Oh, I look maybe, should I do that? I reset, just. It's good that I tried before, I was working
and made this. It's not seeing anything. I've got a third one if this one doesn't
go. Yeah, I'm loving you, you are. So I mean, yeah, there we go. It's thinking about it.
Thinking about it. Thinking about it really hard and then getting out. Yes, okay. People thought
that's can take so long. Okay, let's get started. So I, everyone, I'm Orientalisani,
I'm a project lead in the Uniprot team. So the talk is spot vista, open source protein
feature visualization with reusable web components. So as I said, I work at Uniprot is a
comprehensive, high quality, publicly accessible resource of protein sequence and function
information for the interest of the talk of today. We're going to focus on annotations.
There are specifically parts of the protein specific positions of the protein sequence and the
need that we had was to visualize those in some kind of visualization. So Uniprot is a
consultant composed of AnboleBI where I work and also PIA in the US and CB in Switzerland.
So 10 years ago, when I started IDBI, I was actually in another team in Interpro and I was
tasked with adding to the Interpro website a visualization that has been done by the PDBE team.
The issue is that the website that we had was in React. The PDBE visualization was in AngularJS,
actually the first version of Angular and it just won't work. There was no way to make it work,
actually to make it talk to each other, basically those two bits of code. So I ended up having
to just rewrite the thing, which was a bit of a pity. So at the time we started talking
within the different teams at the DBI to find a way to do visualization that we could share
regardless of the framework that we would be using and also share outside of the DBI for
for usage by other teams. That's when we started working on Nightingale.
So Nightingale is an abundance of visualization library of standard web components. This is focused
on protein visualization that has had before annotations within the protein sequence.
Those are composable components that can be associated in different ways. So you can just use
one component or a bunch of them together and it's interpretable with of standard components regardless
of the underlying framework. So so compatible with any component that would be following the
Nightingale APIs, which is just a specific set of web standard API that we've decided to use
in order for those components to talk to each other. So we started using web components.
10 years ago it was not well supported. So it was a bit of a challenge to start but then
support is way better now. So this is a work component. It's a group of APIs of the browser that
includes custom elements, Shadowdom HTML templates and we use them to be able to develop those
components. So the good thing with that is not dependent on any framework. So regardless of if
he used React or any related, like next or if he used Angular or if he used you, you should be able
to work those components because they don't depend on those framework. And also if you don't use any
framework, that would also work. We tried to limit the number of dependency that we use within
those components. You know, here the sequence length. So from 1 to 770, we have some domains
drawn there. But actually on the Interpro website, so a different website, we're able to have the same
components look a bit different, but actually they're all using the same components underneath.
And they're being fed different bits of data depending on the website. But they work in the same way.
And this is the same for PDBE. PDBE also uses some Nightingale components in their own specific
way with their own style. So for Uniprot, there was a specific need to have a turnkey component with
all of the components that were important for us to view. And that's where a product size,
property size, basically a combination of those Nightingale components are sampled in a specific
way by the Uniprot team fed Uniprot data and having some extra features on top of that.
It's yourself a web component wrapping over web components inside. And the good thing with that
is that you can just use that one and then you will use all the underlying components together
assemble this in a specific way. So the viewer is composed of tracks. The tracks are the
Nightingale components that we saw before. They are the fundamental building blocks.
And each track as we saw before can be used individually or in this case they can be combined together.
And product size, so the wrapping thing, the whole thing is associated them together, fetching
the data from new plot APIs and assigning each bit of data to each track responsible to
displaying their own thing. That could be variance, that could be domains, et cetera. And actually
the good thing with that is we also have this structure visualization. There is itself another track.
And that could work with the rest of the tracks and it can work together interact with each other.
So the architecture is that we have a manager and then within the manager you have all the tracks
and the manager is in charge of listening to what all the tracks are saying. Let's say when the
user interact with them and then propagating that to the other tracks in there and also assigning
the data to the right track. So as an example, if a user click on a specific variant in one of the
track then the manager, sorry, the event itself will emit a standard event that will be picked up
by the manager and the manager will go to all the components within itself to be able to assign
that information to all the tracks which means that you can highlight in one track and you will
highlight on all the track even on the district to viewer and same thing you can keep in
sick the zoom, the pan, the panning of the visualization or together. So under the hood, what do we
have? We have the lead library for building reasonable work component. We'll serve the 3GS for
the data driven rendering with SVG and canvas. Also recently we started using canvas to run
the specific tracks and that led to web better performance for when we had a lot of rotations
and we still have a SVG overlay on top of that. So we made the move to canvas because we are
previously using on the SVG but the more data you have on the screen, the more heavy in memory this
and that would just not be able to scale with the new amount of data that we'll get every day.
So this is the work that we did recently, performance optimization. You can see the by
number of annotations and here initial lot time and here the interaction time or refresh time
and the SVG presentation is in blue and canvas implementation is in green and you can see that
we had some threshold of acceptable time for those two metrics and we managed to reduce that by a lot
by using canvas it's the SVG. So we had some challenges. I mean it's been 10 years since we
started working on that. This is not a focus that sorry a project that one person is completely
signed on so it's a bit of a small work as step by step and so at the beginning we tried to keep
it pure and not having any dependency at all but in the end especially when integrated new developers
in the project we realized that we needed to integrate some libraries, some lightweight libraries
to avoid food guns when we had new developers in the project. We also embraced recently
type script so the compile code is not in type script so anyone can use it but actually if someone
develops they will be able to have that enhanced experience by using type script and having those
type annotations. We also have some challenges because all of those components were handled in a
mono repo and it was a bit challenging to make sure that all of them were bundled
independently without having too much data sorry, too much code in each of them and as I said before
we are in the path of having the performance improvement to have a full transition to canvas
we still have some components that are not in canvas still in SVG and we will explore webGL
implementations. We also want to improve developer experience and use the experience because some
users were asking for example to rearrange some tracks or to remove some tracks and so this is
something that we would want to implement and a big test that we want to do is engaging with a
wider community not just the EBI and so this is something that we will do soon. I just wanted to
specifically the software sustainability institute ground that we managed to get so from tomorrow
and during one year we will get some money to be able to work on the sustainability of this specific
project by organizing one hackathon having some of his hours for developers and also engaging
with a community more. Here are some links to the different reports and I don't know if we have
them for a bit of questions yeah. Questions and congratulations to keep you taught there.
So whichever whilst you're taking questions other than questions.
If they're in non I mean I can just feel a little bit oh yeah there's one.
So actually this is more star within nightingale so this is a wrapper this is the one that
is not really lightweight to be honest because if you don't use the structure viewer this is
quite lightweight but if you want to have the structure viewer within it we have the nightingale
component which is a wrapper to be able to talk if the same language with the same API with the
other components but inside it it's interactive with the most eye library which in itself is
quite big I mean yeah this is something that we're discussing with the PDV team to be able to
extract just a bit the we need and so hopefully that's something that we can do in the future.
And so yeah just so I like that the thing that I said before about the software sustainability
institute we will announce through LinkedIn I guess this is a main communication channel
the hackathon the different office hours that we'll be doing from now until next year and hopefully
this means that we will be able to fix and improve all the code that some of the code
might be 10 years old so this is something that we really need to update and and actually have time
to spend on improving that so that hopefully the community can take over and we can get contributions
even outside of API.