Antenatal for ng new - The mother of all angular applications both dead and alive
Tags: angular, react, vue, architecture
Published: 2021-08-27 00:23:09

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. 

###Why antenatal?

![surprise emoji](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gixo3cyr4mfzr0bibhbm.jpeg)

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. 

###ng new : The mother of all angular applications dead and alive.

Why this phrase? this is simply because almost all angular applications started with our glorious command `ng new`. `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 new` refers to the requirement gathering, research processes, documentation and all that you need to do before you start or create your frontend application.

###Why Should you Care?

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.

###Consulting

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.

###Company-Specific

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. 

 1.	Application overview
 2.	Application features 
 3.	CSS framework
 4.	External libraries
 5.	Device support
 6.	SEO
 7.	Analytics tool
 8.	Software management methodology
 9.	Internationalisation and Localisation 
 10.	Testing
 11.	Deployment (Staging and Deployment)
 12.	Communication 
 13.    Documentation
 14.    Storage
 
###1.    Application Overview
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.

###2.    Application features 
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.

###3.    CSS Framework
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.

###4.    External Libraries
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.
      
###5.    Device support
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.

###6.    SEO 
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](https://scully.io/)

###7.    Analytics tools And Monitoring 
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](https://sentry.io/welcome/) and [Pingdom](https://www.pingdom.com/) 
for traffic, you can use mixpanel, fb, google etc.

###8.    Software management methodology
Specify the details of the software management methodology. 

###9.    Internationalization and Localization 
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.

###10.    Testing
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). 

###11.    Deployment 
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.

###12.    Communication;
This includes things like encryption method, message format. Etc.

###13.    Storage
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.

###14. Documentation
This is the actual documentation for you angular application. eg. For components libraries documentation you can specify [Story book](https://storybook.js.org/) and also [compodoc](https://compodoc.app/index.html) for the angular application documentation 

### Summary
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

[Frontend Documentation Guide](https://github.com/valoni01/fe-documentation-guide/blob/main/README.md)