We had long used an internal API by our accounting software, which was also utilized by thousands of our end users. We decided to make our experience and expertise available to external developers, allowing them to integrate electronic invoicing into their applications quickly via a public API. Thus, the Invoicetronic project was born.

We had made a similar choice in the past with the open-source release of FatturaElettronica.NET, also a library initially created for internal use. Eve and Cerberus for Python started as an internal projects too.

We didn’t limit ourselves to just opening our API to the public. That alone would have been challenging (as any veteran well knows, opening a private product to a broader and more diverse audience is already a real challenge in itself). We seized the opportunity, years after its creation and with millions of invoices having passed through the system in the meantime, to refresh the design, improve performance, and add important features that proved stimulating to implement.

I certainly wasn’t lacking experience with REST APIs, but I still learned a lot, especially while working on the tools accessory to the actual API. An example is the client SDKs. We support all the most common programming languages: JavaScript/TypeScript, Python, PHP, Java, C#, Ruby, and Go. They’re built using OpenAPI Generator, a tool I initially underestimated but which turned out to be excellent, thanks also to the remarkable ecosystem built by the community. Working on the SDKs also provided me with the opportunity to improve my Continuous Integration skills. Beyond the usual test-containerization-staging-deploy cycle, every API update is followed by an automatic release of all SDKs, each with deployment on both GitHub and the reference package manager for the language: PyPI, NuGet, npm, etc. Seemingly obvious tasks (such as inferring the new API version number from CI and then reusing it in the package version of individual SDKs) required considerable brainstorming.

The Invoicetronic project, which gave me the most satisfaction and taught me the most, is invoice-cli. This open source command-line tool enables sending and receiving electronic invoices from the terminal, and is available for Linux, Mac, and Windows. You don’t need to be a developer or study the API in depth to use it, and, not secondarily, it can be conveniently inserted into a script. A trivial usage example would be:

# send a single invoice.
$ invoice send file1.xml

# send multiple invoices, then delete the local copies.
$ invoice send *.xml --delete

# individually send multiple files.
$ invoice send file1.xml file2.xml file3.xml

# receive all unread invoices.
$ invoice receive --unread

From my point of view, though, the interesting thing about invoice is that it’s written in Go, a language I hadn’t yet had the chance to use professionally. A veteran would likely find fault with the implementation details and the chosen approach, but I hope they’ll be merciful, considering I’m a beginner in this space. We could have used C#, which is now our reference language. Still, in the case of the command-line, Go seemed like a better choice, first of all, for the exceptional support in creating native multi-platform binaries, then for performance both cold and hot, and for deployment simplicity. If I had to make another command-line tool, I would return to Go rather than orient myself toward languages I know better and with which I’m more comfortable, like Python and C# (speaking of C#, the recent improvements in AOT and cross-platform support are remarkable - we’re on the right track, come on guys!)

A second stimulating project was the Invoicetronic MCP Server. We were interested in having developers interact with the Invoicetronic API via LLM, and an MCP server serves precisely that purpose. Fortunately, C# has an excellent official library (still in preview but sufficiently mature) that simplifies the work, and implementing and deploying a first experimental version was relatively simple. There is enormous potential in this area, and I want to stay on top of it: objective achieved (I also gave a couple of presentations on the topic).

We released Invoicetronic for our own use, but I hope other developers will adopt it. Throughout many years of activity, our primary client has consistently been the end-user, the company that utilizes our accounting applications. In recent years, we also engaged with developers, but only in the context of our open-source projects. I’d love to serve them professionally as well.

This talk will discuss the experience of moving from C# to Go for a video coding project. The pros and cons of using Go, a modern and efficient programming language, and how it compares to other languages will be shown. In addition, the use of FFmpeg, an open-source tool for video encoding, and how it was used to create the video encoder will be discussed. Advice will be given on using Go and Ffmpeg for future projects. Together, the benefits of using these tools for video encoding will be understood.

Like me, Daniel has a C# background, so it will be interesting to see the whys and hows he picked Golang for his video encoding work. I’m curious about his perspective on both languages and what he learned from adopting a new stack. Leaving the safe path to adventure into unknown territory is a safe way to broaden knowledge and improve self-confidence, or at least it was for me when I added Python to my tool belt. In surprising and unexpected ways, most of the new expertise also proved invaluable in my C# & F# work.

The session will be held in person, in Italian. So if you’re interested, join us!