About pullModel

Photo by Thought Catalog on Unsplash


Drip Educate Me!

PullModel is for when you need information, but not all at once, please. 

Might not be as weird as you first think.


Every week I tend to add features and/or refactor, so this video is always out of date, but still it gives you a basic idea of the functionality.

#1 or #2? … No! #3

Information can generally fall into 2 categories,

  1. wanted
  2. unwanted ( this information showed up, and I never asked for it).

But what about a 3rd, weird category? Wanted information that is both sought after, but it shows up later, by design. That’s just crazy. Who would seek information – and then asked that it be delivered later?

Turns out, education fits this exact model. Stuff that we could never absorb in one big chunk. Then too, so do some subscriptions, such as newsletters that our financial advisor might send us.

In an increasingly over-informed world, drip education offers something intentional that might be counter-intuitive, information that comes later, by design.

Subscriber Motives:

You might start with two different motives for requesting that the information you want be delivered later, rather than now.

    The information doesn’t exist yet, you want it when it on a schedule, as it becomes available. Again, your financial advisor’s newsletter comes to mind.
    “I can’t even get my head around this yet.”This is why you take courses and pay a professor to spoon feed you over a semester, instead of just reading his textbook. First, you get this one main idea, then let it sit in the brain for n days. After that, the next idea will make sense. Lather, rinse, repeat, pretty soon you’re understanding complex ideas like E=mc2 that you never thought possible.

There are other motives, to be sure. PullModel doesn’t prescribe a motive, but it does offer a remedy.

Timed Information

pullModel is a timing engine for information. When you subscribe to a collection of information that you want to learn about, you get it on a specific time schedule, set by the author, from the start date that you subscribe to that information.

For example, if you subscribe to lessons from your running instructor:

  1. Day1: First information on the day you subscribe.
  2. Day7: Second information a week later.
  3. Day14: Third information another week after that.
  4. Day30: Fourth information a month after you subscribe.
  5. etc – any days as prescribed by the publisher of that information.

As an alternative (such as your financial advisor’s newsletter) pullModel allows you to send information to a subscriber, but on a schedule that you set.

Hopefully, that spacing/timing strategy works to your advantage. It’s all about you, the receiver of information, and what’s going to work best for your learning process.

What Medium:

Email? Text Message? Facebook Message?

Let’s just start with facts, again. We’re in an over-informed world, and it’s only getting worse, not better. Cutting off entire channels of information is often the only way to survive. “Don’t call me on my home phone, I never answer and don’t even check my messages very often!”

pullModel delivers information via email.

For those – and there are many – who never even check their email, but would still like to get their pullModel information, pullModel offers alternative notifications that an email has been sent to them.

  1. Text Message Notifications
  2. Facebook Messenger Notifications

These features are not currently turned on, but approximately 75% of the development has been completed on these features.

Ripe for Abuse:

pullModel, like all forms of information, is always ripe for abuse. Since it cannot change this fact, instead it offers the subscriber a remedy.

Here’s an example that lives outside of pullModel. I went to a wedding last night, and someone stood up to raise a toast, but then instead droned on for 15 minutes. Everyone except that person was ready to pull their hair out.

This is why pullModel is designed to make it difficult to become a publisher, and super easy to un-subscribe.

It is also why pullModel is provided as open source software. If you want to deploy it yourself, go for it. But you take the risk of abuse, not me. It’s your installation, your users.

Market Alternatives

There are an indeterminable number of great alternatives to pullModel for publishing your information in a drip format, some free, some easy, some powerful, some are super popular. They are usually variants on spamming systems for information providers such as vendors, or just newsletter software. They might include these great options:

  • AWeber
  • Mail Chimp
  • Constant Contact
  • Socket Labs
  • InfusionSoft

These are almost always better options than pullModel, because they are designed to be fully featured and typically heavily staffed. But there may be costs and/or technical capabilities required.

PullModel was created for a different purpose than email marketing.

Open Source

The code that runs pullModel is open sourced and may be used by anyone.

Future Plans

See Personal Motivations below, the plan for pullModel is to keep it in operation for a very small subset of people to use, and as a vehicle for my own personal motivations below.

As such, it’s maturity as a platform may always be questionable. The prospective user is always directed to the many alternatives above.

Primary Technical Features

All primary features are developed first in poly-on-fire projects separately one at a time. In this manner, you can isolate the code for achieving that feature without the confusion of the entire app.

These features are all pretty normal features as might be found in any modern application.

The poly-on-fire projects linked below are code building blocks or demo projects for this pullModel codebase.

  • cookies
  • query params
  • state management
  • CRUD: Create, Retrieve, Update, Delete
  • db permissions for actual data security
  • visibility hiding for functional UI security and workflow management
  • Authorization/Authentication using external OAuth (google, facebook, twitter, github)
  • messaging via SMS, Facebook Messenger
  • back end processing – fired by database events





Managing State in a Polymer App – My Takeaway

Photo by Jack Douglass on Unsplash


Cliff Notes Version:
Managing State w Web Components

Here’s what I settled on, stripped of the rationale, which is below:

  1. Avoid 2-way binding, even if Polymer templates provide for this capability.
  2. Propagate state via “properties down, events up”, whenever the specific state is simple enough for this to work easily.
  3. Use polymer-redux (or redux or flux or mobx or … )  to manage state in all other circumstances.

Hopefully, article will save you some time, if you’re just entering this world. I’ll detail where I spent my time, below.

Weird meets Thought

Web components are already weird for the front end developer marketplace, so if you add the idea of having to think about your design re: state rather than having your framework impose some thinking on you, that can slow you down. It did me.

Managing state quickly became an issue for me, as I was learning Polymer and/or web components basics.
I’m still a first year JS coder – nevermind the 3+ decades of writing abandon-ware in over a dozen previously popular platforms, from APL to Java Swing or even Oracle ADF.

Managing state was one of three areas that has, so far, consumed most of my time learning how to write an an app in web components, or in this case, Polymer. What follows is how I actually had to learn to think about it.

Rationale for the 3 rules:

You won’t find the 3 rules reflected in all of my github thought experiments, because it took me a lot of trial and error, and time on the Polymer Slack feed, to divine some of these conclusions.  I had to do it the hard way, first, often in several different variations.

Also, see Credits below.

1. Avoid 2-Bay Binding

First, the bad news. If you’re coming in from the cold and Polymer has a reputation for being too hard, some of it is from this odd combination of capabilitiesToo clever by half, as some might say. The data system, with 2 way binding, helper methods, and careful techniques that work in certain situations and not others, is really pretty amazing, but only if you have the patience to wade through it. The edge cases can be a MF, but I must have started with the edge cases, because it confused me like crazy.

Bottom line is that even before lit-html is considered, using 2-way-binding can be a little like making a deal with the devil. Sometimes it works easily, other times not, and it fails the being obvious test more often than not. So there’s that.

PRO TIP: This ‘Data flow examples’ section helped me the most, when learning how the data system works.

As if to put the nail in the coffin on 2-way binding, Polymer3 offers, but does not require, lit-html as an alternative to it’s initial templating piece. Many of us, myself included, have come to regard this option as the go-to plan for migrating our apps to Polymer3.

And lit-html doesn’t do 2-way binding. So that conclusion to avoid 2-way from above? It becomes the only option, if you go with lit-html. Nail in the coffin.

The exception that proves the rule?

Benny Powers points out that there are actually some places where 2 way binding works out swell. Like for example, this, from the slack feed:

If I'm buillding a reusable element, and it contains an input, and i won't ever need to track the internal state of the element between it and it's input (e.g. i'm exposing that input's value), then IMHO there's no reason not to use declarative two-way binding inside my shadow dom.

I'm starting to move from this "compose shadow dom into apps" approach to exploring a "use shadow dom only for reusable components and write app code in the light dom" approach so that fits in as well.

What makes this so instructive is the level of detail required to even describe it properly. So as with all things, the ‘never 2 way’ rule only applies to the beginner/intermediate dev, such as myself. Once you get to the black belt level, you can break such rules with abandon, and still be just fine. Just so long as the beginner/intermediate coder isn’t responsible for maintaining your code, later, when you have moved on.

2. Properties down, events up

So I’m studying all this stuff and watching the various published talks and monitoring the slack feed and it still isn’t obvious, because everyone seems so agreeable about everything. There are just so many options, so many ways of managing state. I don’t want many ways, I just need to get my job done! So here’s how I settled on properties down, events up, as the default.

A whiner might say “gosh they made me read all this documentation on my options and never told me to just default to properties up and events down until that doesn’t work.” Because that’s the main thing you need to know. Everything else can just confuse you, initially. Or it did me.

Go to work. Write your app. Follow this simple principle, until it fails you, then you can read the kajillion of words of documentation. In that order.

3. Redux

At last, we’re writing our app instead of combing through endless docs and slack chatter. See? This web components stuff isn’t so bad after all.

But there is this one area. In my case it was the workflow/navigation/content-hiding kind of use case.
For you, it could be something else.

“Sure,” you say to yourself “I could do this with properties down and events up, but it’s starting to feel a bit awkward.” Like way too brittle, and maybe it shouldn’t be. What to look for? Usually it’s when following the nested components up and down gets really hard to manage, properties wise. Again, your mileage may vary.

This is where Redux, or Mobx or … comes into the mix. A state management system. I tried designing my own using a global window namespace, that was the dumbest thing I ever did since the previous dumb thing. Main thing is you don’t have to re-invent this wheel, it’s there for you to use, and it’s mature.

I chose Redux specifically, for three reasons.

  1. It seems to be the darling, in all the talks. Others are rarely even mentioned.
  2. It is more explicit or verbose than Mobx, which is more my style of coding.
  3. polymer-redux is an already mature web component, so I didn’t have to re-invent that, either.

It still took me a while to learn, but mostly that was because I kept trying to make it harder than it already was.

PLEASE NOTE: Everyone will tell you the same thing – ignore this at your own peril – don’t default to [redux] for all shared state, just use it where it is worth the extra complexity.


Too many helpful talks, slack posts, and doc writers to all credit here, but special thanks to Benny Powers and Daniel Bustowicz for the hardest part, which was nailing it all down into one concise set of thought processes. Without that, much of my clarity on these issues would never have been possible.

The History of Polymer – Comic Version

Photo by Aman Shrivastava on Unsplash



In 2004 a committee produces something called the DOM, which was a browser spec.
It was thought of as inadequate, and there wasn’t much you could do.


But wait! This is a chance to re-invent! Coders love that!
A succession of frameworks emerged, each competing to re-invent DOM better than the others, with bolt-on JS. There were many. Each, was of course, ‘the best’ especially compared to the other choices. Developers love that.

Some figured “Heh, since we’re re-inventing, we may as well throw in the kitchen sink.” So some of these frameworks got pretty fat. “We’ll run your app, but first it has to download 700k of minified js.”

Web Components, and Polymer

Years later, the chrome team somehow observed all this crazy activity and said “Hey, since everyone agrees the DOM sucks, why don’t we just fix it?” The web component spec emerged, not even sure by who, but google’s chrome team was all over it.

“Hey, this is a good spec, let’s implement it in our browser, and we can write polyfills for other browsers that aren’t ready yet. Then we can write a helper library to implement stuff like getters and setters, for this new spec to consume. We can call it Polymer. It will be more of anti-framework than a framework. Use the platform!”

The chrome team guessed that first Polymer would help, but eventually it almost would go away, as browsers implemented more and more of the spec as core browser functionality.

Frameworks Respond

“Oh great, now there’s no need for a re-invention of the DOM wheel any more!” said no authors of bolt-on frameworks, anywhere.

Even more new frameworks emerged, just in case developers needed more design approaches to evaluate, and more apps to be written in future abandon-ware.

Polymer Captures Massive Market Share

Many years and 2 major versions later, Polymer emerged as a prominent alternative to the other, fatter, do-more-better frameworks. Polymer captures over 1% of the front end market by January 2018, some believe!

Most developers refuse to mention Polymer as an alternative, because “It’s too hard, too low level, you have to know javascript”
Developers hate that.

Youtube and a few other google products were re-written in Polymer.

And that’s the end of Polymer’s short history. For now.

poly-on-fire: Polymer, on Firebase


poly-on-fire is my collection of commonly required functionality pieces, in isolation.


The big gripe about Polymer – whenever I talk to front end devs here in Austin TX, is that it’s “… too low level, too hard to get things done, you have to know javascript.” I didn’t find that to be the case, maybe it’s because breaking the functionality I needed for my apps into these isolated, easy to learn pieces made it all work easily, for me.

Leaving them behind in github, as really dumb, easy, projects, makes it fast for me to re-learn them again when I forget. Or when I need some perspective. Especially compared to real apps, where everything gets all mixed up, and a little more time consuming to distinguish which component is doing what.

You’ll also find there, something more than only the most isolated pieces. Some projects then integrate more isolated pieces, in layers. One project for just CRUD, one for social logins, one for redux, but then an integration project that combines the CRUD with redux and social logins into a visibility controller, but without the complexity of a finished app.

Last but not least, it’s all combined into a more finished (never truly finished) app called pullmodel, which brings it all together and tests whether these pieces are ready for prime time, in a consumer oriented PWA for both mobile and desktop.

Find it all on github/poly-on-fire

The on-fire part:

There is no pretending, with poly-on-fire, in the sense that you don’t have to wonder how it would actually deploy in real life, with real hosting, on a real phone or desktop with real integration with a db and server side functions.

Because everything deploys immediately onto firebase, and firebase is free for modest usage, you can experiment to your heart’s content with the real deal. The only thing that changes for me when I go into production is that the increased volume will eventually start dinging my credit card.

I won’t even go into how cool this is compared to everything I’ve been through previously, at least not in this blog. Another blog, however, does make the comparison.


The good news: Polymer isn’t a framework in the swiss-army-knife sense that most frameworks mean it.

The bad news: Polymer requires you to build your app piece at a time, with web components.

poly-on-fire is a collection of code repositories that explore how certain pieces might be combined or used together, for assembly into a larger app.

Use Cases:

Business requires more common features than is provided for by the Polymer Starter Kit.

If the feature is common enough to be needed in most any typical business app that I would have to build, but is not provided by the Polymer Starter Kit, this is a typical use case for a poly-on-fire project.

This lets me work out the basic kinks in a sample project, and easily migrate it to a real project when the time comes.

Such as:

  • How to bring in and consume query params?
  • Using Polymer and Redux for state management
  • Using Redux for visibility control (client side form of workflow and/or security)
  • NodeJS for server admin
  • SpringBoot for Firebase DB Admin
  • others

Polymer on Firebase

Polymer is a very small framework for building web components, presumably even into entire applications.

Firebase is an aggregation of hosting and 20 or so other products for deploying and supporting web applications.

Both are fully supported by Google and not necessarily intended to be used together, nor does it appear to be the common use case. But it can be a very keen strategy, for many reasons not clarified here.

Polymer Version 1,2, or 3?

All projects are currently written at Polymer 2 level.

There is an intent to migrate everything to Polymer 3 when it is released, but both schedule and my current lack of Polymer 3 skills mean this probably won’t happen anytime soon.

The Advantage of Entry Level Javascript Skills:

There are three very difficult aspects to learning Polymer, all of which are addressed by poly-on-fire projects.

  1. Polymer requires much more ‘low level’ JS skills than other platforms. Intentionally.
  2. Polymer enthusiasts tend towards advanced, and often don’t even remember what beginning JS coders have to learn.
  3. Poly-on-fire are isolated, fully deployable projects – including hosting code.

I started writing Polymer with no understanding of how javascript, the DOM, or the web component standard even worked. That’s pretty dumb to do, especially for a lifetime coder, but it did give me the chance to learn everything from scratch.

As a consequence, you may find that these projects are a bit easier to learn from, if you’re a coder coming from a non-javascript background.

You can deploy them for free on Firebase, and to a great degree, they should just work.

The Dis-Advantage of Entry Level Javascript Skills:

The veteran JS coder might find some of these projects too fundamental or uninteresting.

I have made an honest effort to learn everything I need to learn before publishing each example project. But that’s a fancy way of saying there may be subtle tricks that a 10 year JavaScript veteran could probably show me, and these projects might wish some of them to be included.

Please feel free to submit pull requests or even just a note to pete@datafundamentals.com, if you see anything missing.

Firebase Assumed:

For decades, we have avoided vertical stacks because lock in can be expensive and technologically limiting.

Firebase is free for low usage, and has excellent enough tech stacks to default to this platform first. It’s weird to hardwire to one vertical stack, but for the specific use-cases of these projects, it’s actually pretty appropriate.

Specifically, these firebase products are used in poly-on-fire, to date.

  • Hosting
  • Realtime Database
  • Cloud Functions
  • Authentication


A more fully featured app with most of the other projects incorporated within is featured in pullModel.

This is a kind of seedbed for learning Polymer, for me. In it, you may discover that Polymer is a pretty powerful app.

With the exception of the workflow model – which took me foreeeeeeever to design and implement, even though it really isn’t very hard or even very much code – pullmodel proved to me that Polymer and Firebase make a pretty dang easy way to build a real PWA.

There are many aspects to PullModel, most noticeably service worker and testing, which are completely ignored to date.

Pullmodel is currently, and will probably always be, an incomplete, work-in-progress.

Autopm is the server side of pullModel, and does event based admin, responding to Realtime Database events.