``Hi, remember how I was boasting around that I would have to pull an all-nighter in chapter 1? Yeah, I absolutly failed in that, I spent 2-3 hours coming up with a concept and wireframe only to discard it all this morning. Welcome to the world of developers my dear readers, and just like Monica says, " It sucks, you'll love it " 😄

About my so called app

I don't really know about you dear reader, but I grew up living in a township (a small residencial area far away from cities), and we never had any Swiggy, Zomato, Urban Clap etc. We had to call the reception of our township to even complain for a broken door or window, only for it to be fixed a day or two later. People in townships live an isolated life, far from the city life, in their own kinda bubble, so naturally to entertain themselves, people used to form group, they'll hold some random contests, organise parties, meetings etc. and all this happened through phone calls and texts. You already get where I am heading with this right?

Yeah, yeah you do. So, I though how about I make an application to centralize all of this. Let me give you an example and bear with me for a second, imagine you living in that township, you wakeup, and oh! your tap doesn't work well, or a electricity port is not working, instead of calling a receptionist all the time, you can just (in Barney's way) wait for it.... use this app to raise a ticket (Raise a ticket ?!? God I've been working in this cooperate for too long 😂) for that issue, and the receptionist, on the other side would recieve it. This not only saves you time, but also helps the receptionist streamline the process of keeping track of all the houses that require electric repairs and call the electrician or directly tag him into the list ! That would be cool right?

So, now that you have raised a ticket for an issue, you saw that someone in the town is organizing some fun event, Hmmm...how about you take a look into it? Well, no problem, all you would need to do is just, click on a button and boom you have participated in an event, change your mind? Sign yourself out. Your can organise event, take part in it, all things centralized in one app.

Now, off course, all people who live in townships know about this, but for my readers who don't we generally have some announcements like very frequently, sometimes it concerns everyone in the town, sometimes only to few select people. Well, targeted announcements, in the same app? Here we go.

Open discussions, everything, this app would be like a small scale facebook without any friends feature.

Frameworks I am going to use in detail

So, yeah this is the basic idea about the application I am going to build. So, the way I like to approach building any application is to atleast get the login page and landing page ready. Yes, I would be starting out with the Front End this time. Why?? Well, every application would have a sign up and a login page which mainly needs all the normal user details like `firstName, lastName, username or email and password`. And the landing page should display, the details of the user in a header component. In my thinking, if I go by coding up my backend first, there would be things I miss, and If I go with front-end first, I could miss out on key details.

So, normal issues, I feel like i'll run into

• what sort of database design would I be needing? How many tables? What kind of relationship?
• How do I make sure I implement the features in a loosly coupled way?
• What sorts of data would I need to collect?
• Reducing the number of clicks a.k.a making sure my server gives out accurate response API response to the client with each click.
• How do I pre plan for my error managment?

How would I approach to solve all this?

• Well, as far as the database is concerned the ticket feature can be a different table with no relation to other tables except for the prime user's table which would contain all the user data.
• Loosly coupled or tightly coupled these are all context related as some are preffered over the other in some context. But for this app I would be needing both.
• Reducing the number clicks is utmost important for me as it's all about user experience. So, the only way this could be handled well is through code modularity, aka reusing my code logic as much as possible, how would I do it? Well, that's what development phase is for. But if I would have to sum it up briefly, arranging your data is the key, the better arranged your data is, the better you can perform business logic on every fetch and patch on your DB, the better the response your client can get.
• Errors? Well, limiting the user input is the first thing to consider. We have to consider "Zero Trust Policy" meaning, that we'll take every user input as an error. The more you allow your user to make an input in your code (except for text feild, option selection and all, duh...), the more code you'll be writing to handle those errors, the more bulky the code will become, the more error prone it would be.

I would be going with Redux toolkit as my default state managment in my React app, but for simple things like storing the username of my user so that it can be displayed in every header component, storing my access_token so that I can attach it to all request headers , basically for every state which won't be changing more than once or twice, i'll be using React context, and for the rest i'll be using redux as the main manager. I would be going in with axios as my Http Client. And Ionic for component library and for PWA. Rest like for showing list of events after a GET request, I would be handling those data inside of an redux central state. All the API calls would be done through action creators.

Well this is it guys, I promised I would attach the wireframes for my application, but then I am pretty sure the look and feel of the application would undergo a lot changes as I go on developing this application, so might as well, pull out screenshots and link my repo with every chapter for you dear reader to see.

well, i better get to code this thing up, would take me a month or two hacking all this together, we'll let's see. Bye Bye.