Approach
There are multiple ways to create a project like this, and most approaches will get the results we are looking for. Unfortunately, some approaches will mean the project stalling or being restarted, so it's critical we understand the approach we have taken and the reasons. The best approach is usually the way the team works and understands, but not always. As usual, we keep the team and everyone else involved in the process. Some of the approaches we have considered are below.
Data Driven
This is where we model our data before we do anything else, then work from the data.
Choosing this approach, we have to think about everything the system can and will do in all cases, then how the data for this will look. In our system we will need users, users have accounts, users have sessions, users have roles that have permissions, so we would need a place to store all this information and the relations between the data. Not only the relationships, but the relationship constraints, for example, we cannot delete a role if there is a user with this role exists because that would break the system. If an admin user does try to do that, they should be told with a human readable error, not the screen going blank with a code or something else that is no use for the user. In reality, the user should not be able to delete a role that is used, but we will look at that in more depth later.
Once we have all the data we need, we start to normalise or de-normalise (depending on how we choose to save the data), but this is a complex topic and too in-depth for this post. Once we have the data in a 'good' state, we end up with a schema that is the source of truth for the data and we share that with the rest of the team/s so they can use this data to build their parts of the system e.g. API, Frontend, etc.
However, until we have the source of truth, we block anyone else from even starting the work as they cannot know how the data will be saved or what it will look like, in fact, they may not even know how the system will work.
Using the data driven approach we would need to know exactly how the system will work before we can create the schema, every part of it. We will end up with flow diagrams and data diagrams and all sorts of interesting documentation that will go through iterations and versions that the architects will keep secret or something that is pulled will end up in the system. Lastly, this approach can (and should) be a rigid approach where the schema is immutable until the system is complete, then the data can be mutated with migrations.
This is a great approach and can lead to a solid system, but is a long process with seemingly no progress.
Front End First
For this approach we create the forms and layout first, so we know exactly how the system will work, then we use this to add what we need to save the data and communicate with the world.
This approach means we can show exactly how the system will work and what problems we are likely to find. We can see from a user point of view what is needed and is great for UX (User eXperience). It means we can see an interaction between the different forms and where relationships belong, it allows us to see when a UI (User Interface) element might not be the correct pick for the job at hand e.g. do we use 'fields' or 'field types' to hold the information for the config? By creating the forms, we can answer this and see we need the 'questions' on the 'field types' and the answers on the 'fields'.
However, this approach is a lot of work and can cause major issues when the layout is complete and shown to the client / bosses / stakeholders and the cost for the data or performance hit is found to make the layout unfeasible.
This is also a great approach and can lead to a great looking system early on, but the people paying usually think this is a working system that just needs a bit of polish, not understanding the project is probably only around a quarter complete when it looks finished.
PoC (Proof of Concept) or MVP (Minimal Viable Product)
This is where we create a full system from beginning to end as quickly as possible.
A PoC is about showing the basic system with basic functionality to show the client / bosses / stakeholders and is usually scrapped and restarted.
MVP is more about a product that can be sold and built on and is usually kept and updated.
Both approaches are about a full, working system, end to end, so before we start, we must choose MVP or PoC and be sure to let everyone know the decision. These approaches are great because it means everyone can see how a system could and should work, we can look at cost and security and see where things like 3rd parties will fit and understand a little of the design with the UI.
The problem with this is the amount of work that is done can be huge and is likely to be scrapped (especially PoC) because showing a working system quickly means no security or 'good' coding practices and cost is usually not considered.
This is a great approach, but the important thing is everyone know the difference and which one they are using.
Getting started
We have chosen an MVP approach for this CMS project. We have done this for the reasons above, but also because it works for us. We can work on the system as a whole and keep building until it is 'ready' then keep adding new functionality. This works with our Scrum outlook and our team understands this way of working.
Our first job was to create the Trello board and get the cards in for the main parts and start splitting the cards to tasks. While we got the work to do in place, we got started on the codebase and making sure it was using the correct branching strategy. We started with Next.js and got the basics in then created the Git repository and uploaded to the private GitHub account. We added the master and develop branches and made sure the repository was correct.
This gave us the basics to get moving quickly.
Technology
We added Prisma and chose SQLite locally, then created the Firebase account (we will use this for hosting later). Using the local `.env` file we wanted to be able to swich between our local database in SQLite and the Firestore datastore so we could test as needed. We added an example `.env` file to let developers know how to format the environment variables, but this will change as we move forwards.
Our main goal is to have minimal (none if possible) environment variables as all config will be saved in a database. We must have a way for system files to understand where the data is and this is done with environment variables. On local this is in the .env.local file, but on a development or production server the environment variables can be added in many and varied ways depending on the host. As this CMS will have the potential to be installed on any number of systems, keeping the env vars to a minimal is paramount.
Our first technical decisions have been made:
- Next.js (running on Node.js)
- Minimal environment variables
- Prisma for the main databases - MySQL, Postgress, SQLite and MongoDB (SQLite locally)
- Firebase and Firestore must be supported
We also have our local setup in place:
- Pull files from Github
- Add an .env.local file
- Run `npm dev` in the terminal
- Go to http://localhost:5610
- The browser will go to the setup page (using SQLite will create the database) from setup
Finishing up
The CMS project is now in active development, and we have our project management in place, Next week we will look at the schema and how we have started the data.
If we've missed anything or got anything wrong, please let us know.