Add back support for mapping Swift structs to collections in Atlas, a functionality removed from Stitch

[puiz666]

Goals

I have a Swift struct, and I want to add it to my collection in Atlas. Previously, I was able to map a struct to a collection:

let itemsCollection = mongoServiceClient.db(“myDatabase”).collection(“myCollection”, withCollectionType: MyStruct.self)
itemsCollection.insertOne(myStruct) 

After the Realm integration, this functionality seems to be absent. Instead, the SDK now expects me to convert my Swift struct into a Realm-supported, Objective-C-compatible Object subclass, which is a very significant regression:

• Not all data types are easily (or, at all) convertible into Objective-C-compatible types, even if they are codable and compatible with MongoDB data types; this is an unnecessary limitation from a developers' point of view.
• Nesting structs was trivial; nesting ("embedding") Object subclasses is much more cumbersome.
• Swift guidelines and Apple's own APIs are moving fast towards structs as opposed to classes, thus Realm should not force the use of classes because they imply complex and error-prone data mappings and conversions.
• Stitch was a thin layer connecting clients to MongoDB, respecting the latter's data model and schemaless nature. Realm, on the other hand, imposes an entirely new data model that requires schema, relegating MongoDB into a mere back end. Developers who used Stitch as a thin layer to connect to MongoDB are now forced to either re-architect their data and apps around Realm (i.e. move away from MongoDB), or abandon the platform altogether.

I understand that Realm provides a local persistency functionality for the objects it manages, and syncing that into MongoDB adds a lot of value for certain use cases. I also understand that the Realm SDK might have been written in Objective-C, and only recently migrated to Swift. Finally, I also understand that it may be a tempting idea to maintain feature-compatibility with Objective-C.

However, I also believe the following should be important considerations:

• The future of Apple development is clearly and unquestionably based on Swift, and Objective-C compatibility will not be possible to maintain in the long run. It would also unnecessarily limit the evolution of the SDK, hurting developers, and MongoDB as well.
• While it may be worthwhile for a developer to move to a very dated Objective-C-based class architecture for the data he or she wants to persist locally and also sync with MongoDB, this is by no means true for use cases where local persistence is not required. For those use cases, using lightweight and modern Swift structs for MongoDB CRUD operations is much more preferred, for the reasons outlined above.
• Realm relegates MongoDB to a mere behind-the-scenes implementation detail, while developers who want to work with MongoDB directly are now unable to do so with the ease Stitch provided.

Expected Results

Please consider the following:

• On the short term: add back missing Stitch functionalities for working with structs, and do not require a deep Realm integration for all use cases. Do not worry if these functionalities won't be present in the Objective-C API: it would be a very misguided idea to withhold features for the most dynamically growing user base in order to meet an abstract goal of feature parity that wouldn't bring any benefits for the end users (even if it might help the development team at MongoDB).
• On the long term: consider moving to a Swift-first approach in general, and embrace structs even for local Realm persistence (even if a lightweight wrapper class may always persist).

[dianaafanador3]

@puiz666 Thanks for taking the time to comment, we take into account all our community inputs. We'll let you know any further actions we take from your comments.