Before we start, I would like to state that the concepts in this article are not restricted to the Angular framework alone, but can be applied to other frontend frameworks and libraries like Vue and React.
Antenatal in the human world relates to the medical care of women when they are expecting a baby. In our case,
ng new is the mother while our yet be created application is the baby.
Why this phrase? this is simply because almost all angular applications started with our glorious command
ng new has birthed thousands of applications both the ones currently in development, the ones in production, the ones they have stopped using and the ones that never made it to production.
The whole idea of antenatal is to ensure that complications are avoided during the pregnancy and delivery process. This directly applies to what you need to do before birthing a new application.
The antenatal care for the
ng newrefers to the requirement gathering, research processes, documentation and all that you need to do before you start or create your frontend application.
Below are some of the reasons why you would need to do the initial research and documentation of your frontend application before spinning up the project.
- planning the architecture of your application
- Decision on the numbers of resources needed
- Estimating and managing development time
- Easy maintainability and hand over
- Reduce back and forth with product owners and clients
So, whether you are in the consulting space or you work for a specific company, doing this antenatal across all your products makes your development process extra smooth and seamless.
If you fall under this category, there is a chance that you are going to be involved in different types of projects with unique use cases. And it is important to ask the right questions and document all the specific requirements before you start your application.
If you fall under this category, You may have to do this process once in a while because there may be less frequent changes in your application development processes and policies. But it is also very important to have all these documented so that new employees or consultants can use them as a reference.
I have listed below with explanations and examples, some of the research and documentation (antenatal) you need to do before starting a new application.
It is important to know that this is not a cast in stone. while all the below points are important, you can go ahead and pick the ones that suit your need or you can also add more.
- Application overview
- Application features
- CSS framework
- External libraries
- Device support
- Analytics tool
- Software management methodology
- Internationalisation and Localisation
- Deployment (Staging and Deployment)
This is a detailed explanation of what the product entails and it should be simple and very easy to understand by anyone who cares to look at the document.
These are the key feature modules in your application. You can derive them from the functional requirement document. Eg. Transaction Management, User, Dashboard, etc. You can further divide this into features module and shared modules. This could help in making decisions around the structure of your application.
The choice of the CSS framework is one of those things that varies across different products especially when you are working in the freelance or consulting space where each client can have their own preference. Examples include bootstrap, angular material, etc. You can also specify the CSS methodology and the CSS preprocessor.
These are external libraries apart from the CSS framework. they could range from your charting library, date/time and other critical libraries for company-specific or individual applications. It is important to always keep track of this and it is more useful for people with near static documentation. your consultants or staff will always know the appropriate permissible library to use when starting new projects or adding a new feature that requires an external library.
While it is important to make your application mobile responsive at any point in time. It is also worthy to document the target browsers, resolution information and whether the application has mobile-specific features or views.
Here, you will specify how you want to improve the SEO of your application. You can specify the strategies. Examples includes server side rendering, dynamic rendering or pre-rendering using tools like scully
You can further categorize this into different types of environments eg. for local Performance analysis, you can specify tools like the source map explorer. For production monitoring, you can use Sentry and Pingdom
for traffic, you can use mixpanel, fb, google etc.
Specify the details of the software management methodology.
You need to specify whether there is a need for internationalization, specify the locals you want to support and the translation tools you are going to use. This is very important as it is easier to implement this during application development. You also need to decide the localization strategy.
You can specify everything about the application testing
eg. The type of testing, test runner (Karma,Cypress), the testing framework (Jasmine,Jest), mocking libraries(Testdouble.js, Jasmine).
You can define the various deployment strategies and environment. Eg. Whether you will be containerizing your application with tools like Docker, the numbers of environments, server details, type of repositories, AOT or JIT etc.
This includes things like encryption method, message format. Etc.
This includes general storage information ranging from application local and global storage eg. NGRX, Ankita, Rxjs,NGRX component store, ngrx-slice, session, local, cookies etc. Also, you can include your assets storage.
I have outlined what I think are the most critical research or document to put in place before you start any new frontend application. I will gladly love to hear your opinion.
Here is a repo that shows a possible structure of your document