MigsLab About ARX.SDK
The Story Behind ARX.SDK
An idea that started in college between 2011 and 2013, and an implementation that began in 2017.
ARX.SDK did not start as an attempt to build another ORM, or to hide databases behind an abstraction without understanding them. It grew out of years of writing SQL and designing databases, from my first college projects onwards: discovering a different programming model, building an implementation for a real product, and working with many database technologies as a developer and consultant.
- 2011–2013
College
Where it started
My journey started in college, with Microsoft Access. That is where I first grasped the idea of normalization: why data belongs in separate tables, how those tables relate to one another, and why a good structure keeps the data consistent.
From Access I moved to Microsoft SQL Server, where I developed an Enrollment System for our thesis. I was working the conventional way: connecting directly to the database, writing SQL by hand, and managing every retrieve, insert, update and delete myself. That gave me a solid foundation in relational database development, one that still shapes how I work today.
It was during the thesis that I first had the idea of making things dynamic instead of hardcoding them. It began with rendering: forms that described themselves and drew their own fields, each one self-contained. Underneath, the code was still spaghetti, and the calls to the database were interpolated strings.
My first real attempt at making the data side dynamic was to drive everything through parameters. It was a really bad design, but it worked, and with it I built several more systems: an Inventory system, a Library System, and Learning and Exam modules.
Those early systems taught me what not to do as much as what to do. SQL built from interpolated strings is why every value in ARX.SDK is a parameter today, and every name is checked before it reaches the database.
- 2014
Starting work, and a different model
In 2014 I started working professionally, and that year I was first exposed to Microsoft's Dynamics XRM framework. What caught my attention was a different way of interacting with data. Instead of constantly writing database-specific queries and dealing directly with the underlying data access implementation, I could work with concepts such as Entities, Attributes, Conditions, and Services.
The metadata-driven approach and the abstraction it provided felt natural to me. I particularly liked how it allowed developers to interact with data using a consistent programming model without having to think about every underlying database operation. It was a different development experience from what I was accustomed to, and I immediately appreciated its potential.
It did not replace what I had learned. SQL and database design taught me how data actually works underneath any abstraction; Dynamics XRM showed me a more consistent way to organize and interact with it. Both experiences stayed with me throughout my career, and both shaped the architecture of ARX.SDK.
- 2017
The original implementation
The first implementation
In 2017, I started developing my own implementation of this concept. The initial version was built around Microsoft SQL Server and eventually became part of one of my early products: Aftoma, an integrated Human Resource Information System with an employee portal and biometric device integrations.
Aftoma was initially developed using .NET Framework 4.6.2 and was subsequently upgraded to newer .NET frameworks, eventually moving toward the .NET Core ecosystem.
What started as an implementation for a single product gradually became something I continued to use and improve. It had already proven useful in a real application, and I wanted to keep building on that foundation.
- Following years
Expanding across database technologies
As my career progressed, I worked as a developer and consultant across different projects involving different database technologies. Each project introduced its own requirements, database structures, provider-specific APIs, and ways of handling data.
Although each technology had its strengths, I repeatedly encountered the same development challenge: switching between different ways of interacting with databases. I wanted to bring the same development experience I had appreciated in Dynamics XRM to these different technologies. Not by making every database behave identically, but by providing a common programming model that could accommodate their differences.
My experience working with different providers also helped me recognize that a useful abstraction should not ignore the characteristics of the underlying database.
- Today
ARX.SDK under MigsLab
Why ARX.SDK exists today
ARX.SDK brings together years of development experience, lessons from real-world applications, and exposure to different database technologies. It is an effort to establish a common approach to data access while keeping the implementation flexible, provider-aware, and developer-controlled.
The intention is not to replace every database's native capabilities or claim that every provider should work exactly the same way. Instead, ARX.SDK provides a consistent foundation for common data operations while allowing provider-specific implementations to handle the differences underneath.
What started as an internal implementation in 2017 has evolved into a project I want to make available to other developers under MigsLab.
Who maintains it, and why it will continue
ARX.SDK is maintained by me, Miguel Ramos, under MigsLab. You can reach me at [email protected].
I have been building this SDK for eight years, and I will keep developing it: it is the core framework of AIRO, my metadata-driven platform, similar in spirit to the Dynamics platform. ARX.SDK is not a side project that can be dropped; the product I am building depends on it.
AI tools have sped up the benchmarking, the testing and the documentation. The core engines are still driven by my own SDK architecture.
ARX.SDK is built around an approach I have wanted to use consistently throughout my career: one programming model, multiple data providers, and control that stays in the hands of the developer.
The principles that come out of this story are on the Design Philosophy page.