Weekly Update (April 22nd to May 7th)

Sync Design

  • No hidden information — Optic doesn’t guess what you want to sync or keep the relationships in some unreadable config file. All the relationships between parts of your code appear within the code itself. Annotations are used to name the models found in your code and then set those models as the source of another part of code. When you transform code these annotations will be added automatically unless you opt-out of creating a relationship between the source of the transformation and its output.
“//name: User Model” names this section of code “User Model”
“//source: User Model -> optic:mongoose@0.1.0/createroutefromschema” defines a relationship between “User Model” and this section of code. Changes to “User Model” will trigger changes to this code.
  • Sync will not happen automatically — Let’s be realistic, the last thing any of us want is a bot making unannounced changes to our code as we work. Optic maintains a dependency graph of all the key sections of code and when it sees a change that will trigger a sync it notifies the programmer. The programmer can then review Optic’s pull request, make any changes they see fit, and update the source code.
  • Sync Pull Requests walk entire tree — The sync graphs Optic constructs for a project can be very complex. For instance a form might be synced with a route, which might be synced with a model definition (User Model -> User Create Route -> User Create Form). If you change the User Model, Optic will walk the entire sync graph and stage changes for each affected relationship. There are sanity checks built in that ignore circular dependencies and other invalid states that could happen when computing the patch.
  • Single Project (Sorry!) — In Version 1.0 of Optic (launching this month) the sync feature will only work within the context of a single project. We’re working to make it available across multiple projects i.e. your node backend syncs with your Android Kotlin Project.

Sync Implementation

Here we have a Model Definition for Users and a Post Route we created by transforming that model. If you calculate a sync diff on this example you get no changes
Here we’ve changed the name of the model from ‘users’ to ‘people’ and added a new field ‘age’. Before Optic you’d have to manually find and update all the code that depended on the shape of your model. Optic can generate a patch to make these updates for you without overwriting other code you wrote.
Here’s a look at the Pull Request Optic generated for this file after you changed the model

Some more thoughts on Sync

Thanks for all your support! 1.0 is coming soon




Building Tony Stark’s workshop one company at a time. Founder useoptic.com (YC S18)

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Airtable Webhooks with Slack + Pipedream

GUI for Docker Container

Flutter Tip : Column or List View?

GitHub: Purpose and Functionality

The joy of remote working/studying

Shell and BASH

Review : Todoist

Load Balancing using Spring Cloud Netflix Ribbon

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Aidan Cunniffe

Aidan Cunniffe

Building Tony Stark’s workshop one company at a time. Founder useoptic.com (YC S18)

More from Medium

Go Lang Tutorial: log.Fatal

Implementing Capacitron — an expressive Text-To-Speech VAE model — a Master’s Thesis Project

Retired Programmer Tries AI Programming in Python. 11) Development — Game End

Corda 5 — Unveiling the P2P Preview