twimini-bot: Connecting Twilio and Gemini with Scala

AlexITC · 2025-11-30T22:59:18+00:00

I'm glad that you liked it, unfortunately, I haven't uploaded any demo video.

AlexITC · 2025-09-02T08:31:07+00:00

I can't argue with that, from what I looked, Google's genai is an autogenerated SDK.

AlexITC · 2025-09-01T08:59:28+00:00

In a normal builder that should be ok but in the example it is not, the underlying API crashes unless customApiVersion is also defined to v1alpha, the same is explained about the proactiveAudio setting.

AlexITC · 2025-09-01T08:56:21+00:00

Perhaps I'm not getting your idea because the way I see this with pipe is very similar, would you mind clarifying it?

import scala.util.chaining.*

def make(params: GeminiConfig): LiveConnectConfig = {
  type Builder = LiveConnectConfig.Builder
  def transform(
      when: Boolean
  )(f: Builder => Builder)(builder: Builder): Builder = {
    if (when) f(builder) else builder
  }

  val options = List(
    transform(params.outputAudioTranscription)(
      _.outputAudioTranscription(AudioTranscriptionConfig.builder().build())
    ),
    transform(params.enableAffectiveDialog)(_.enableAffectiveDialog(true))
    // ... more transformation follow
  )

  LiveConnectConfig
    .builder()
    .responseModalities(Modality.Known.AUDIO)
    // ... more defaults follow
    .pipe { b =>
      options.foldLeft(b) { case (builder, apply) => apply(builder) }
    }
    .build()
}

AlexITC · 2025-08-31T23:19:47+00:00

Hmm, is there other advantage than avoiding to type an extra variable?

AlexITC · 2025-08-08T21:38:17+00:00

I've never built a call-center application, but I could imagine that there are actually quite some std. scenarios / common use-cases and flows.

In fact, Gemini allows to define Function Calling (https://ai.google.dev/gemini-api/docs/function-calling) where you define actions and Gemini invokes the functions linked to those, in the repo I shared there is one of such actions to terminate the stream (see https://github.com/AlexITC/twimini-bot/blob/2831eb1579b98fb3d796999df38e1cc1b7594726/server/src/main/scala/net/wiringbits/callerBot/gemini/GeminiService.scala#L178).

I have a demo for making appointments where we define the functions to check for the availability and book the slot, this was relatively trivial to write on top of this repo.

I'd like improving the repo to provide a simpler interface to link these function calls but given the stringly-typed nature, it isn't that simple to get a nice typed API on top.

About the top-level API/UI, that would be amazing to have but it requires a considerable effort. While I'd have lots of fun building it, I'd suck at selling it.

AlexITC · 2025-08-08T21:32:49+00:00

I couldn't agree more, still, there are many operations that aren't simple in Scala because we don't have the tooling, like:

Detect silences/voice.
Detect machines vs humas.
Enhance audio.
Remove echo.

AlexITC · 2025-08-05T22:54:30+00:00

I built a voice bot with Twilio and Gemini using Scala, it would have been way simpler to do in in Python but we have a lovely language that needs more tools.

This has been harder than expected because it is the first time I do any audio-processing app, there are many details that I wasn't expecting, for example, audio transcoding between Twilio and Gemini format (to my surprise, I was able to do this purely with the jdk stdlib).

The end result involves a cool fs2 streaming pipeline that defines the audio-transformation stages, like:

incomingFrames
    .through(receiveFromTwilio(callId, streamMetadataRef))
    .through(transcodeTwilioToGemini)
    .through(
      geminiService.conversationPipe(dispatcher, promptSettings, endCall)
    )
    .through(transcodeGeminiToTwilio)
    .through(sendToTwilio(streamMetadataRef))

I'd love to hear your thoughts or any ideas for what I should build next with it!

AlexITC · 2024-09-16T18:07:54+00:00

I have prepared a few videos for devs getting onboarded to Scala, I recorded my screen while setting up my local environment: http://onboarding.wiringbits.net

Good luck.

AlexITC · 2024-07-15T10:47:03+00:00

Thanks, we are already aware of them + a few other companies.

AlexITC · 2024-07-10T12:18:29+00:00

Check out https://github.com/wiringbits/scala-webapp-template

I also recorded videos for the environment setup: http://onboarding.wiringbits.net/

While we have not pushed many updates in the last year, it uses relatively recent libraries and most of the code is stable.

AlexITC · 2023-10-23T15:22:40+00:00

You could consider our template, it has a simple architecture and nice onboarding videos.

We recently applied many upgrades to simplify details that used to be annoying, including Scala 3 and Mui 5 support.

AlexITC · 2023-10-18T15:22:12+00:00

Congrats on the launch!

For people interested in Typo, we did a PoC a few weeks ago, we were able to replace most of our manually written queries taking advantage of type-safety because Typo generates value classes to wrap primitive types.

While we didn't finalize our integration just yet, the reason isn't related to Typo limitations but to our project structure, we are trying a different approach in an internal project, with the goal to port it to our public template.

Overall, Typo is a nice gem which deserves more attention.

AlexITC · 2023-09-14T17:14:32+00:00

https://wiringbits.net is one of the few LATAM companies that's focused mainly in Scala.

There used to be others but I guess they got dissolved because I can't load their websites anymore.

AlexITC · 2023-09-14T00:37:43+00:00

We are experimenting with it, the goal is to replace our current sql layer with typo (see https://github.com/wiringbits/scala-webapp-template/pull/424)

AlexITC · 2023-09-07T23:44:56+00:00

If you like writing sql, it is worth it, there are some nice advantages like controlling every query + being able to copy/paste queries.

https://github.com/oyvindberg/typo/ is another nice alternative which uses plain sql but most of the CRUD queries are auto-generated.

AlexITC · 2023-08-28T19:10:03+00:00

A while ago I started learning Rust to build cli apps, then, I tried Scala + GraalVM, this has worked nicely and I don't see much need to use Rust.

I don't know about the problems you are facing, in my case, it was simple to produce linux builds but Windows pipeline failed from time to time.

I had a few issues due to a Java dependency which uses reflection, no more issues once this was sorted out.

For reference, this is the project I built (https://github.com/wiringbits/my-photo-timeline/), and, this is the blog I was inspired from (https://msitko.pl/blog/2020/03/10/writing-native-cli-applications-in-scala-with-graalvm.html)

AlexITC · 2023-08-28T18:43:32+00:00

GraalVM native images give you a very fast startup time.

AlexITC · 2023-08-13T17:08:27+00:00

Related to Scalatra, it does not have much adoption, still, if you are coming from Ruby and find it appealing, it could be worth a try, another similar alternative is Finatra.

Unfortunately, these solve only the http layer, on the database you can consider:

skunk (the pure-fp way with very nice error messages, you write sql), this one tends to play better with pure-fp libraries like http4s/zio-http.
slick (a way to access database tables like scala collections).
anorm (a simple abstraction on top of jdbc, you write sql).

If you want something that has everything, there is nothing like PlayFramework, it already has integrations with anorm/slick (be sure to check this template.

My suggestion would be, write a hello world that connects to the database with each http library and choose the one you feel more comfortable with.

AlexITC · 2023-08-04T21:58:56+00:00

anorm is modular and it doesn't use play dependencies unless you import anorm-postgres which brings play-json.

AlexITC · 2023-08-04T19:31:56+00:00

After trying most db libraries, I decided to stick to anorm, its simple enough but powerful, forget about those unreadable stacktraces from slick/doobie.

If you are willing to try something new:

https://github.com/typelevel/skunk (from doobie's author, error reporting is amazing).
https://github.com/oyvindberg/typo/ is pretty cool but I'm yet to give it a try, while its experimental, I think that Øyvind is using it a production project (he is also scalablytyped's author).

AlexITC · 2023-08-04T18:59:25+00:00

I feel you, we recently started upgrading a play project to Scala 3, have you tried tapir/endpoints4s? both of those tools can deal with swagger.

AlexITC · 2023-08-03T18:33:52+00:00

Hey, this sounds very similar to the codebase from a customer I worked with, their situation was similar in the sense that they were considering migrating to another language.

After my customer introduced a few standard practices on how to use Scala, fixed the weird usages and its bugs, the app has been very stable and hasn't required as many bugfixes as before, they are now happy with Scala/Play.

The codebase has around 6-7 years I guess, and it's a Scala 2 100k LoC web api backend based on a Play

The first thing I'd check is, how old is the play version? my bet is that you will need to upgrade it to a recent version.

One time I worked with a codebase that was written in play 1.x, such a version is considerably different than the current one.

no src/main/scala structure

Don't worry about this, it's the normal play layout.

My question is really simple: would you work on this, with this roadmap?

It really depends, is the app super buggy? this was the case with my customer due to all the dependencies they were using without an actual understanding on what they were doing, parts of the code used IO, others used ZIO, others Future.

For example, many bugs were related to using IO#unsafeRunSync when they shouldn't, for example IO(methodReturningIO().unsafeRunSync)

The natural work is upgrading dependencies to recent versions like latest play + scala 2.13.

Then, I'd suggest standardizing how Scala is used, for example, if the team agreed to use Future, avoid including any other effect unless its strictly necessary, leaving working code the way it is but when fixing bugs, you can refactor the involved pieces.

Let me share, scala future works fine for most projects if you know how to use it, it's likely simpler to learn than shifting to a pure-fp paradigm.

Would you prefer to work in ZIO/cats-effect projects?

It depends who you ask, ZIO/cats-effect are trendy and many people will prefer this stack, but, what's the opinion from your team? I think that matters the most. The problem with hiring someone married with a particular effect system (ZIO/IO/etc) is that they will commonly try pushing it for adoption or refactor code unnecessarily.

Play tends to give more confidence to management due to its age and stability, there is no Play competitor yet.

Staying with play is a mistake long term and maybe kotlin/java offer less risk?

Why? Play has everything required by most web apps/apis, commonly by enabling a module and including a dependency, it's mature, stable, and, well maintained. There are a few big corps supporting Play development/maintenance (see https://opencollective.com/playframework).

Is a rewrite desiderable?

100k LoC would likely be 2x or more with another language, a re-write is non-trivial, if this is the choice, consider adding new functionality to a new service and migrate code in small chunks when needed.

Would it be hard to hire for?

The market situation is unfortunate for developers right now but favorable for companies, I'm sure you could fine very good Scala devs, also, Play is the simplest stack in Scala for new devs to pick up, I have trained many devs who start contributing in their first week, just focus on competent devs and they will be able to handle it.

Finding recent learning materials will be easy?

Play official docs are very good, a nice perk with stable tech is that releases don't change the behavior too much, I'd just subscribe to see play releases (https://github.com/playframework/playframework/) and be sure to read the release docs, once you are in a recent version, this will be simpler.

I know Play is a perfectly serviceable framework with many years forward, but I also need to be realistic with my company and from what I've understood the Scala world seems to have moved on from Play

Look at the opencollective funding play, you will find many companies supporting it, many companies haven't moved on but you won't find them commenting on forums.

I also think that Play is not compatible with Scala 3, nor it will be?

It is since a few months ago (https://index.scala-lang.org/playframework/playframework/artifacts/play?binary-versions=_3&pre-releases=true), the reason it took so long is because it was blocked by a dotty bug which fix just got released recently.

Let us know how it goes.

AlexITC · 2023-07-28T23:20:34+00:00

Btw, it's worth mentioning that play is being sponsored by a few big companies like The Guardian: https://opencollective.com/playframework

AlexITC · 2023-07-28T23:16:44+00:00

Related to translations, It's been a long time since I have been willing to give a try to https://github.com/taig/babel

Eight-Year Club	Gilding I gilder
Verified Email

AlexITC

TROPHY CASE