poly-on-fire is my collection of commonly required functionality pieces, in isolation.
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.
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.
- 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
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.
There are three very difficult aspects to learning Polymer, all of which are addressed by poly-on-fire projects.
- Polymer requires much more ‘low level’ JS skills than other platforms. Intentionally.
- Polymer enthusiasts tend towards advanced, and often don’t even remember what beginning JS coders have to learn.
- Poly-on-fire are isolated, fully deployable projects – including hosting code.
You can deploy them for free on Firebase, and to a great degree, they should just work.
The veteran JS coder might find some of these projects too fundamental or uninteresting.
Please feel free to submit pull requests or even just a note to firstname.lastname@example.org, if you see anything missing.
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.
- Realtime Database
- Cloud Functions
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.