Art needs Space, and Space needs Art. Just as Airbnb connects People to Space and Uber connects People to Transportation, Tekuma catalyzes this connection with state of the art technology.

Written by Stephen White

When I started as a developer at Tekuma, I quickly realized that any development would truly start from scratch. There was no existing framework. I initially didn’t know how to feel. I was excited that I could choose any components I wanted; I wouldn’t have to walk into someone else’s way of thinking or learning a language I didn’t care about. But on the other hand, I’d never laid out a framework before. I’d never even built an app before, and I really didn’t know where to start. So, I defaulted to the process I use when when I get lost in my classes at MIT:

1) Google as much as I can about it.

2) Ask my friends (who mostly work at Google) as much as I can about it.

Perhaps not so surprisingly, after about 4 weeks of combing through blogs, forums, hacker news, and messenger feeds, I arrived at the conclusion of: use Google.

In short, the basis of my framework is to have a cloud-hosted, central data structure, which users can access through a set of web-apps that act as user ‘portals’. From there, a REST API will be developed. We can host cloud compute engines to communicate to the API and expand from there.

Development

With no formal experience in web development, and having never created a web-app before, I defaulted to the design philosophy instilled by MIT: ETU-RFC-SFB Shoutout to MaxG

ETU: Easy To Understand

The first thing I considered when choosing the framework, was personnel. Tekuma is a company of Architects. The initial engineering department consists of two 20-year old undergrad software developers, that have never build at app before, and the rest of the company has limited CS background. From this, it follows that the framework should use a high level of abstraction. Though, too often when using high-level libraries, functionality and customization are restricted. When analyzing levels of abstraction, I reflect back to Dijkstra:

“Being abstract is something profoundly different from being vague … The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.” -Ew Dijkstra, The Humble Programmer

Abstraction should be intuitive, not vague or restrictive.

SFB: Safe From Bugs

Bug-free design goes without saying, but it is important to note that the current device market is diverse. Rather than writing,producing,testing Android, iOS, osX, etc apps separately, a robust web-app that can run bug-free in Chrome and Safari will work on most of the world’s devices.

RFC: Ready For Change

Through researching web-dev practices, I noticed something. Web-dev has the intrinsic property that web-dev guides are widely and verbosely available on the web. But, unlike other fields of development, web-dev is constantly in flux and values of ‘right’ and ‘wrong’ are also dynamic. A JS guide from 2015, could already be depreciated without backwards compatibility. RESTful web-apps require complex dynamic hosting. PaaS (Platform as a Service) exists to ‘abstract away’ hosting, but PaaS is costly and the market for providers is shakey. Looking to the future, I decided to lay out a web-app framework that is static, stateless, and single page. An app that uses: 1 Single HTML file, 1 Initial HTTP request to bring all app code client-side, and a 1 step global deploy process, would be the epitome of RFC, IMO. Such an app would take serving costs from the O($0.1/yr x count(users)) to nearly O(1) free.

Wouldn’t it also be nice if the web-app was fully reactive such that any static fields such as text can be changed without a refresh? What if accessing a global-realtime database and filesystem could be handled abstractly through high-level Database() and Storage() object interfaces in the front-end code? And, if Auth() could be abstracted away into a single Auth() interface? Most of all, wouldn’t it be great if all of these interfaces could be managed through a clean, Material UI, GUI? After all of this, what if the framework could effortlessly scale into the range of millions of users and petabytes of data?

Meet the Framework

In the end, we decided to build Tekuma’s web-apps using: Google Firebase and ReactJS. Written in ES6 JS and JSX syntax. I believe that this framework meets all the aforementioned features, and when I say that this framework is brand-new, Google’s documentation on Firebase was released 1 week before development began. While some may think this is bold move, I’ve put my faith in “Google” being synonymous with ‘Ready for Change’ on the web.

Development Remarks

Through the first phase of development, having no previous experience with ES6, Firebase, or React; I found the stack to be very intuitive and clean. ES6 carries a new functional aesthetic for Asynchronous programming, take a look at a database transaction.

databaseRefrence.transaction( (node)=>{
    //perform actions on node here, with scope extending outside the transaction
    //NOTE: node is a JSON representing the requested node in a NoSQL DB.
});

Not only does the arrow function create a cleaner anonymous call-back flow, it automatically and lexically binds the ‘this’ object, making it a perfect match for Firebase + ReactJS.

Subscribe to Tekuma’s news letter!