Advanced filtering on your API endpoints with SQLAlchemy and FIQL

Short Form


How robust is the filtering of your API? Let's delve into how a string of text can become a set of instructions to the API on exactly what records should be returned.


Modern web frameworks make it easy to stand up an API with fairly robust filtering, sorting, and pagination out of the box. The point of this demonstration is not to say that the approach we’ll be looking at is better than the approach of some other framework. But, rather to provide a glimpse into how it could be implemented and gain the subject knowledge required to grep the strengths and weaknesses of this as well as other approaches.

During this demonstration, we’ll pull apart the FIQL draft to find it’s strengths and weaknesses. We’ll investigate how SQLAlchemy applies filters, how this effects the strategy for parsing the FIQL expression, and the implication of this strategy. We’ll subclass SqlAlchemy’s Query class to allow filtering directly from a FIQL expression. And, if time permits, we’ll improve our API by adding sorting and pagination.

It is expected that participants are already familiar HTTP, Python, and WSGI.


rest, flask, python, ORM, fiql, sqlalchemy, fiql-parser

Speaking experience

This would be my first speaking engagement where participation was “really” voluntary. My previous experiences have been either internal to my employment or technical training aimed at individuals who were getting paid to learn what I was teaching. I am hoping that the topic being fresh for debate will help keep the discussion lively but also promise not to get upset if someone chooses to leave. At least, not while they are still in the room.


  • Profile pic

    Serge Domkowski

    Kavi Corporation


    I’ve been involved in making web software for about 22 years. I design and write code, talk about code (much to the delight of my wife), play with my son, ride my bicycle, root for the Timbers, drink beer, and once in a while sleep.


      • Title: Micro-services provide some benefits, but at what cost?
      • Track: Theory
      • Room: B302/303
      • Time: 10:0010:45am
      • Excerpt:

        Several years ago, there was an architectural paradigm shift toward “micro-services” and away from the “monolithic” application stack. A micro-service architecture comes with scalability and replaceability, among others, but is it worth the time and effort to build it? Is it worth debugging API calls gone wrong? If you’re thinking about making this move, have already started, or have already deployed to production, this is an ideal venue to see what others are doing with micro-services.

      • Speakers: Serge Domkowski

Leave a private comment to organizers about this proposal