CFPs

Here I maintain my CFPs

🔗

Calling your API

description

There are two main types of APIs that are called on a regular basis, the first is when you call a third-party API via their API client, you have to trust that they do everything right. The second is when you call your own API, where you should learn all nuances yourself.

At Algolia, we develop various API clients for different use cases, and recently rebuilt a version of our main API client from scratch and would love to share with you what the key learnings are we had regarding calling an API and all its surrounding architecture.

notes

All the learnings we made during making v4 and earlier versions of our JavaScript API client are shared here. Also some references to things in other API clients and things we chose not to do.

Bio

Maintaining front-end libraries at Algolia like the API client, React InstantSearch. Belgian living in France.

🔗

Reimagining InstantSearch as a framework-agnostic library

description

Let’s say you picked a framework to use. You use some libraries that work well with that framework, maybe you make your own. A few years later you don’t like it anymore and need to find replacements to work with your new framework.

As a library maintainer, a great bunch of your users will be switching frameworks over time. You’ll want to make both your life in maintaining multiple versions simple as well as avoiding users to jump through many hoops implementing your library.

summary

Tips on how we switched from an architecture where we had a complete new InstantSearch flavour per framework, to one where we can build onto the primitives of InstantSearch into other frameworks.

notes

This talk will focus on the concept called Connectors used in making InstantSearch for Angular, based on the version for plain JS (using preact behind the scenes)

Bio

Maintaining open source libraries for Algolia like InstantSearch (js, React, Vue) and lower-level libraries used by those. Belgian living in Paris.

🔗

Searching for dependencies

description

You might have noticed before, but since the end of last year, its been possible to look up packages on the Yarn website. It’s a community project done by Algolia, by replicating the npm registry, together with other sources. A front-end search has been made with React, as well as a detail page, which fetches data from sources with other types of rate limit.

summary

Find out how the Yarn search became a possibility, from replicating npm in Algolia, to fetching extra data from GitHub and working OSS.

notes

Depending on some other factors, the public announcement of the free to use Yarn search API might happen here or at another event, but it’s going to be part of the focus.

I was an intern from February to May at Algolia, responsible for search on the Yarn website, the npm ↔️ Algolia replicator and the detail pages of the packages, like yarn.pm/react

Bio

Maintaining front-end libraries at Algolia like React InstantSearch after doing an internship focused around research and the Yarn search experience