A good start is half the battle..
Such or similar statements also apply to the development of web applications. Anyone who starts with the right tools, in a suitable environment and with a solid foundation, may later not have to tediously restructure the app. Design patterns and best practices in general are often taken very seriously in boilerplates, giving the developer clear guidelines.
With this mindset I have looked at the “Ultimate Boilerplate for Products” Pup from cleverbeagle.com. This is a template for the development of a web application based on Meteor, React, MongoDB and GraphQL. Subsequently I want to answer the question to what extent boilerplates help us with the development of prototypes and when they may actually hinder us.
What does Clever Beagle’s Tool Pup have to offer?
With the installation of Pup (currently in version v2.0.1) you get the executable source code of a small web application for managing Markdown documents. The app contains components to realize the following tasks:
- User registration via OAuth and user administration via an admin panel
- Sending e-mails based on HTML and text templates
- Automatic generation and indexing of a random database set
- Table definitions via GraphQL and an own GraphQL Playground
- Create a sitemap and SEO metadata with app details
- Routing setup for public and authenticated requests
- Server side rendering (SSR) for faster presentation in the browser
- Form validation
- Styling and customization via bootstrap and styled-components
- Browser policies for protection against XSS
- Data export, account deletion and declaration of consent according to GDPR / DSGVO
- Local git repository with an own Linter Script Hooks
- Unit and end-to-end (E2E) tests
- Configuration for Development / Staging / Production Settings
- Complete workflow for app releases and continuous integration including DNS entries, SSL certificates and hosting on Meteor Galaxy (Requires additional access data)
This list is constantly being expanded, as Pup always strives to relieve the developers even more and cover more areas through this boilerplate.
The swiss army knife for web apps
The benefits of using such a large base are clear: As a developer, you do not have to worry about many things that sooner or later belong to a solid web application anyway. When the boilerplate is still being further developed, it also answers the question „How do you do it right now?“ Because in the current Javascript environment, current and well-coordinated modules and libraries are very important.
Pup is clearly aimed at web applications in an production environment. That means this app can go live at the touch of a button. But what if we do not want to develop a “solid app”? When we create a prototype, it’s usually about fast, traceable functionality, maybe something to show or something to test. Most of these prototypes also disappear long before an actual roll-out or are developed from scratch in further phase. In this case a bulky boilerplate will cost us a lot – a lot of time.
$ meteor npm install added 2111 packages from 905 contributors in 129.893s $ ...
The installation is very simple – but also extensive. With Pup, over 2,100 npm packages are installed – that’s over 60,000 Javascript files with over 5,000,000 lines of code. A “cold start” (after meteor reset) of the meteor development environment takes about 6 minutes. From then on, the web application can be reached on the local machine. The Node.js service uses, even without further intervention on the website, a lot of resources:
In comparison, an empty Meteor / React project needs just under a minute to get ready on our development machines. This will be improved by compilation, packaging and final deployment. However, for the time being these points are negligible for the development of our prototype. Here we want to try out stuff and celebrate fast successes. Unfortunately, the use of design patterns and correct directory structures – even when done in best intentions – often prevent us from doing that. We tried it – for the presentation and editing of two additional lists in the frontend, a total of 20 new Javascript and GraphQL files had to be created and twelve existing ones had to be edited in order to comply with all established coding guidelines.
When implementing a prototype, it is now up to you to decide whether or not it makes sense to follow these guidelines throughout the entire development process in order to facilitate the later conversion to a productive app.
In summary: The slim army knife
Boilerplates are good – to a healthy extent and at least as a reference book. A prototype does not have to start from scratch. Especially in Node.js environments, there are a variety of templates. At the same time, development must not be hindered by too many regulations. It is better to start with a boilerplate which is as small as possible and piece by piece, as soon as the need for another module arises, get parts from the “ultimate” Pup reference book. Trying it out, and seeing what is possible pays off in any case! I think it is better to know the rules and decide not to follow them, than not knowing at all what is wrong.
Suggestions for Pup
Things I noticed when using Pup:
A Note in the documentation for the GraphQL Playground: the currently authenticated user is not sent with queries. Thus, no queries are possible that require such a user. In the app, unfortunately, this affects all the data – this makes the playground pretty much inoperable. The note that you should provide data first without authentication and add this in a next step, does not comply with the overall boilerplate use.
Login via OAuth: according to the documentation, those are controlled in the application settings. In fact, there are several places in the source code each with their own lists to display options for registration, login and callbacks.
The documentation on the website is quite extensive – still the actually used source code is not always clear. In the source of the boilerplate itself, in turn, there are hardly any comments or hints to the underlying chapter, which often requires manual searches of all documentation. In comparison, the Meteor tutorials make it better, although the code base is clearly a lot smaller there.
Furthermore, points are noticed that are already known to the developers and may be done soon. These include separate data validation at the client and at the database level, and the overall performance of the Web application.
About qnipp
We’re building prototypes for web applications and mobile apps, so we regularly evaluate technologies and tools in this area. If you are interested in our services, please contact us at office@qnipp.com.