Web Application Team of 1 - Getting It Done
Beaver Dam Metaphor — Whether you’re building a beaver dam or a web application, get the necessary pieces in place for the structure to hold water, and then build on that.
The original title of this post was, “Redefine ‘Progressive’ in Progressive Web App”.
Backstory
Just over a year ago I started down the path of making a PWA for an app idea that my sister had. This post is an attempt to derive some lessons from my experience and express them so that I can take them to heart and so that others might save some time. Life can get very busy and you can’t afford to waste time when you’re working towards a product launch. This article is going to appeal mostly to those working on an app alone or in a very small group. The lessons that I can identify are as follows:
- Use what you know, use what’s available
- Redefine “Progressive” in Progressive Web App
- Filter the noise
- Don’t buy into the scalability myth
- Not all tests are created equal
- Invest in yourself
Use what you know, use what’s available
Don’t try to write a library and an application at the same time. You’ll find your loyalty and attention swaying between one and the other, and neither will get the attention they need. Anything that needs written needs to be tested, so the less you have to write the better. Using popular libraries is the best way to test your app. Now that we’ve limited the scope to libraries that are currently available, try to use what you know. I’ll bet there’s a framework with a slightly better API and smaller file sizes, etc, but the cost of learning another API is more significant than what you’re saving in the other areas. Kick that can down the road.
For instance, before starting this project I was comfortable with React, but I chose SkateJS. I don’t remember why, but I ended up going back to React. I then learned Vue and ended up rewriting it again. But the reason that I didn’t like React enough to keep it is mostly that I was using a few custom libraries that I had written which were becoming a headache to maintain. Had I stuck to the prescribed Redux architecture things would have been better. I am very happy with Vue now though, and Vuex.
Rewriting pieces of an application, and swapping libraries, should wait until after a minimum viable product is released. Another lesson that goes hand in hand with this is to not question your choices. Almost any choice made with a decent amount of scrutiny will be good enough for the initial release.
Redefine “Progressive” in Progressive Web App
Progressive web apps, or PWAs, are named such because they are websites that “progressively” act as an application, depending on support for the underlying technologies in the user’s browser. Offline usage, notifications, background sync, and asset caching are some of the behaviors associated with PWAs. The lesson I’ve learned that I want to impart to other small teams focused on releasing a PWA is, don’t release a PWA. That’s not to say don’t aim for a PWA eventually, just to aim for your website to be a PWA for the initial release.
Instead I propose a redefining of the word “progressive” in the context of PWAs. Progressive should stand for “progressively enhancing your website after you release it.” If you think of web app features that are nice to have, but not critical to the functionality of a website, you’ll find most of the PWA featureset in that list. The initial release should focus on data models, UX, what database is best for you, and a dozen other critical considerations. Don’t bother with things like service worker until you need it, that is to say, until you have a core set of functionality that’s properly tested and you have some extra time to work on enhancements.
It’s more important that your app is out in the wild slowly gaining attention while you work on the PWA enhancements.
Filter the noise
The first skill you need in order to avoid the pitfall of premature enhancement is to filter the noise. There are a lot of best practices, developer conferences, talks about “speed” and “scalability”, etc. that will have you running in circles for weeks comparing frameworks and always questioning your choices. Those talks, while informative, can have the effect of portraying a “bar” of expectations for web applications, with an accompanying sense of righteousness, that you owe it to your users to place these “enhancements” at the forefront of application architecture design. Nothing could be further from the truth. First off, you have no users yet. You owe it to yourself to get your product launched. As your application matures and your user base grows, that’s the point at which to start considering user experience (beyond sensible UX).
Don’t buy into the scalability myth
Most likely your app release will be more like placing a cup underneath a dripping faucet than opening the flood gate. We like to imagine that our idea is so good that we’re not going to be able to keep up with the demand to use our app. That can happen, but more than likely you’ll struggle to earn your initial users. While growth could be fast, these are also the days of blazing fast computers and cheap storage. Don’t think that you’re app needs to be immediately distributed around the world using a backend architecture that is also distributed. You can get really far on a single node. Always having infinite scalability in mind complicates things and should not be a priority over developer experience.
To small teams, often the more scalable choice is provided as a service, SaaS. If your primary reason for choosing the service is because of scalability, think twice. Time that would be spent acquiring new skills is spent learning a new proprietary API. Learn how to accomplish what you need on a single node system with the basic tools, like web sockets. There are also some in-process key/value stores, like LevelDB, that offer a wonderful developer experience and real-time events. But if you’re overly concerned with scalability, you might not choose a single-node database. If you end up having to scale, that’s what’s known as a good problem, and determining how to scale will come with many other design choices that can’t necessarily be predicted. Start as a monolith, and expect to “spin-off” microservices down the road.
Not all tests are created equal
Focus on end-to-end testing, which implicitly test the inner components. As time allows, increasingly test the inner components. This will also afford you the most flexibility in your architecture. At a point when you feel you have enough test coverage, you can release without having to delay because of lack of end-to-end coverage. To me all tests are basically the same, even though there are a lot of classifications. There’s input given to something that will produce a result, and assertions are ran on the result(s). The only difference is the scope of what’s being tested. Focus on the entire scope and work your way in. In my opinion, front-end component testing is much more difficult and of much less value than end-to-end testing.
Invest in yourself
When I started this project I knew how to develop a REST API in node.js, and how to serve web assets, etc. I ended up choosing Firebase because I thought it would be less work and scalable. It definitely wasn’t less work. All the time I’ve spent learning Firebase could have been applied to learning generic, widely applicable, web-server technology. I’m not saying don’t choose Firebase, if it’s what you already know. But if you have to learn how to use a service, you forfeit the time you could have invested in yourself, making yourself more independent from services all together. Choose a service if it’s affordable and you know it will save you a lot of time, but often learning APIs and learning how to support your use cases via a service can be a huge, unpredictable waste of time.
