Contribute Media
A thank you to everyone who has made this possible: Read More

Stateless / Immutable Webapps - Stealing Ideas from Functional Patterns

Summary

STATELESS / IMMUTABLE WEBAPPS - STEALING IDEAS FROM FUNCTIONAL PATTERNS

Thursday 10 a.m.--10:45 a.m.

Audience level: Intermediate

DESCRIPTION What would happen if we replaced Django's orm with an analogous but immutable equivalent. This is where my story begins...

ABSTRACT This talk started after I heard a talk by Gary Bernhart at a conference in Chicago(SCNA). There he talked about a hypothetical programming structure that held many functional principles(SOC, data-in-data-out functions, etc...), but included enough latitude to keep non-functional tools and structures.

So I decided to write my next project(https://github.com/MattyO/trackerCharts) in this style to see how things would play out in the real world. And it turned out great. This style of a "functional core surrounded by an imperative ring" pushed me towards more and simpler unit tests, the ability to push back many data decisions much later into the process, and a really speedy test suite for little to no extra work. However, this program had no database; being that there was so little data that it fit into a document style store so nicely, everything was held on the file system.

With the next project being written in Django instead of Flask I was pushed into trying this structure while dealing with Django's ORM. In the process of trying to turn django's ORM calls into more pure forms of straight data, I wrote some code to turn turn the ORM query object into something that had an equivalent DSL, but without the ability to make further calls to the database. ORM's ended up being abstracted into a db module that returned this new type of data. Some more great things happened: Data access was much easier to see in views, db integration tests only covered the specified uses cases in the module, what data a view or function actually needs is readably apparent, mocking database calls become completely unnecessary (due to the makeup of the new data models), other kinda data sources were trivial to convert; so data just looked like data no matter where it came from(the file system, an ORM, redis, mongo).

I would like to share some of this journey, talk about separating data from functionality(the good times, the bad times), some of the code that emerged form my journey, and things we can take away from this grand experiment. Thanks !! -Matt

Details

Improve this page