Hello, I'm trying to wrap my head around the implementation for a platform for developing self describing "services" or as we might call them "drivers". The basic lifecycle of a "driver" is essentially: 1. Driver describes Service registration requirements: Announce what registration info (keys, permissions, web-hook URLs, etc) it needs to register 2. User adds Service: Register an instance of Service X by providing "registration info" that were asked for by the driver 3. Driver describes Service interfaces: Use "registration info" to imperatively declare its interfaces (I have these functions, that take these types, that provide these representations, etc) 4. User can begin using this Service from their own code. This cycle exists to enable something like registering an Airtable database through a driver. We aim to allow for generative interface based on the Airtable's columns. You could just as easily replace "Airtable" as an example with an "SQL DB driver" even. The main problem I'm wrestling with is mostly in how I would design the Driver SDK for step "3. *Driver describes Service interfaces*". In some respects, I want to allow the SDK developer (myself and my team members for now) to have a lot of flexibility with how they end up describing the Service interfaces & provide that service interface's implementation. But, when it comes to considering how deployment, versioning, and development and debugging for SDK dev I feel quite naive. Does anyone have reference material or admirable examples of this kind of problem? Even things adjacent could be very inspiring. cc @Garth Goldwater @crabl @taowen P.S. This seems tangential to: reflective type systems / declarative type providers (like building FSharp Type providers); VS Code Language Server protocol; game dev modding; and maybe #C01CD90V1NF.

There are two kind of services, service for read, service for write. There is no standard way to write, writing into a external service need various properties according to the need. Expose the write interface as a generic interface such as SQL INSERT is a mistake, it will not work in cross domain setting. To protect the data integrity, some kind of stored procedure is always needed to validate business constraint.

First thing that comes to mind whenever people talk about the future of versioning, SDKs and a malleable public API ecosystem is the Unison project: I believe @Paul Chiusano would be the guy to ask about that. Seems like a particularly good model for your app domain as you will be the ones controlling the entire stack for the development of these drivers (correct me if I'm wrong). On the topic of service announcement and registration, unfortunately only WSDL comes to mind (sadly).

Not sure I understand what you are trying to build. Do you intend to proxy the calls through the "platform"? Something like an API Gateway? For service specification I imagine you would have to use some form of IDL.

hm. this smells like cambria to me: https://www.inkandswitch.com/cambria.html (at least as far as versioning goes)

I don’t really understand what you’re trying to build. The API is going to be different depending on the registration info provided? The registration info is provided programmatically (by client software) and you want the client to be able to compute the resultant API’s type/interface so static checking can be performed? If so, it sounds like your language needs a specially-crafted type system. The next step would be to show some examples of the types you want to be computed for specific registration info (inputs).

@Nick Smith, yes. You've got the right idea, here. The type-system we've designed has several distinguishing properties that make it better for our privacy-focused, semi-structured, editor. For example, the projection of any type is separate from the type's "registration ID".