Ask an Onner: Eduardo Santamaria
The next installment of our Ask an Onner blog series is here! This time, we’re spotlighting the dually talented Eduardo Santamaria who is both a Lead Software Engineer and squad lead on the Connectors team here at Onna.
Tell us a bit about you and your role.
Eduardo: I’m Eduardo Santamaria and I’m a Lead Software Engineer and squad lead of the Connectors team at Onna. While I’m purely working on software development now, my background is a bit “different,” having graduated from university as a Biotechnologist and soon after realizing that my favorite part was Bioinformatics. What drew me to it the most was knowing that doing research is awesome, but that it’s also very vocational and sometimes slow-paced, and I preferred the computation approach since the feedback loop is much quicker.
As a Lead Software Engineer on the Connectors team, I’m mostly responsible for getting content out of third-party services and into the Onna platform, plus the associated functionalities that come with it (authentication to those services, data collection configuration, and scheduling). Being part of the Connectors team, we try to build some of these core functionalities to support that process. I’m the founder of the Functional Programming Guild at the company (and a Scala aficionado in my free time).
What drew you to Onna originally?
Eduardo: Having worked in small bio-related companies, I was drawn to Onna because of the sector, customers, and the new set of challenges that I would help face and tackle.
In addition to that, the technical level of the team was astounding — during the interview process, one of our principal engineers mentioned they barely used any library/framework … and he wasn’t lying! We build many things on our own from scratch. Not being able to stack-overflow your way out of a problem can be hard, but you’ll learn a lot about a programming language and its possibilities.
Can you tell us a little about what connectors are?
Eduardo: Essentially, they are processes that connect to third-party applications via APIs, collect data, process it to make it easy to find and extract meaning, and store it in the Onna platform.
While this is the simplest explanation, there are other elements involved for it to work: there is the authentication to those services and the user selection of the content to sync (for example, a customer may want to collect just one folder from their GDrive account rather than the whole thing). There is also a scheduling mechanism for both new sources and recurring ones, a checkpoint system to avoid retrieving already stored content, as well as some transformations to fit our models and the final uploading of the content.
What challenges are you facing in the connectors team right now?
Eduardo: I would say there are two main types of challenges: the technical one and the human-related one.
From the technical perspective, we get content from nearly 30 different third-party application APIs that each have their own characteristics, ways of presenting data, and limits. Connectors need to take all of that into account and be able to model what’s obtained from there into our own schemas. Not only that, but they have to do it in a scalable way, and they have to keep up with the latest changes in those APIs. We are currently working on an exciting plan to not only improve it so it can scale even better, but so that the time to develop a connector for a new application is reduced.
On the human side, as other companies in the sector, we need more people. We want to do complex things, and we need a hefty squad of talent to do that.
How do you see the team growing in the future?
Eduardo: We have a clear mission on what we want to build and we know the path that will get us there, so it’s just a matter of working on it with more people.
In a more specific way, Onna is a platform on which anyone can develop a connector to an application or information source in order to sync the data to Onna, keep it safe, and make it easily accessible. We see the Connectors team as the one providing the tools to build this sort of thing (and also developing more connectors ourselves).
Any final thoughts?
Eduardo: If you’re a great engineer and you want to join other great engineers in an exciting journey toward building a platform that integrates any kind of data that you can imagine, feel free to contact me (*psst* we have great benefits and even a functional programming guild)!