Thankfully, this release spanned 3 weeks instead of the normal 2 we're normally allotted. The first week I spent relearning how to use React and also learning how to use Material-UI. We're using Material instead of Bootstrap because some students in the class have developed a severe allergic reaction to Bootstrap.
Author Result Component
Issue can be found here
I'm ashamed to admit, it took me at least 3+ hours just to make the search result component which can be found here (the time didn't include the design by @agarcia-caicedo). I'm very grateful I didn't have to design the component as well or we might not even have a component at all, also big thank you to @cindyledev for her reviews and suggestions as it made the process a lot quicker.
Attaching the MyFeeds Component to the Backend
Issue can be found here
Wow, this took a whole day. Prior to this release, I saw our professor @humphd submit a PR to refactor some previously merged React code from class components to functional components and didn't understand what was going on... since it was front-end stuff.
Well... a day was spent learning what functional components are(I learned React the class component way) and all the changes the React community have implemented. I read about how they are trying to steer people towards using React hooks instead of the previously used class components(although they are still supported). It took a while to understand (their docs are extremely helpful), still a newbie, but I understand it a lot more and have to admit, it is much better than their previous class components. Thank you to @Grommers00 for his work on the backend code changes and @Silvyre for creating the component + quick review.
Automatic Deployment to Staging on Master
Issue can be found here
I spent an afternoon with a frequent collaborator @manekenpix to figure out how this all works. It was pretty interesting as we thought it would take a very long time to get this working, but after 2 hours we had a simple server that was listening to issues filed in a private Github repository and would output a message. The next step would be to automate all the shell commands that are currently being manually executed by him whenever we want Staging to be updated. I am just hoping he gets to work on more issues aside from deployment because he has expressed how much he enjoyed coding.
Now, automatic deployment can range from being really simple to extremely complex. We can have an app that experiences some downtime as the app is updating to being really complicated where we apply the Green/Blue model and minimize any downtime.
Green/Blue - Two identical versions(Green and Blue) of the app will be available, one sits idle as the other one is running. When we bring down the one that is running (Green), we direct traffic to the other(Blue). This minimizes whatever downtime is being experienced as the current files in Green are being deleted, updated to the latest updates of the app from the GitHub repo and Green's containers are being spun up. Once Green is up and running again, we direct traffic back to the newly updated Green and idle Blue again. In this case the Blue can also act as a back-up which we can revert to if there are changes breaking the app or if Green is somehow experiencing issues.
Green/Blue - Two identical versions(Green and Blue) of the app will be available, one sits idle as the other one is running. When we bring down the one that is running (Green), we direct traffic to the other(Blue). This minimizes whatever downtime is being experienced as the current files in Green are being deleted, updated to the latest updates of the app from the GitHub repo and Green's containers are being spun up. Once Green is up and running again, we direct traffic back to the newly updated Green and idle Blue again. In this case the Blue can also act as a back-up which we can revert to if there are changes breaking the app or if Green is somehow experiencing issues.
Switch our app from REST to GraphQL
Issue can be found here
We implemented GraphQL and it works, but only if you go to http://localhost:3000/playground or https://dev.telescope.cdot.systems/playground. Out of all the issues this one was the most frustrating. I thought we were using Gatsby because it works well with GraphQL, I didn't know how it was going to work well, but it would just kind of work. This wasn't the case, we had to install an extra plugin called gatsby-source-plugin, It took a whole day for me to understand the changes I was making in gatsby-config.js 😂.
Anyways, this issue was so we can use all the queries we built for GraphQL to be used in the front end code too. A PR is ready to go which specifically addresses this issue... however moving forward some experimenting to understand how to use the data properly as well as what Static Query/ Page Query/ Static Query Hook are is going to be needed in order to use Gatsby properly with GraphQL
Overall, this release was a fun way to move away from just working on back end, refreshing/updating my knowledge on front end stuff and working on issues that were in between the two. I can't design things to save my life, but I can probably implement the design in React! Since I can do back end and front end things, I'm now a full stack developer right? Probably not.
For 0.8 alongside triaging issues, my goal is to try to get Kubernetes/minikube up for Production.
Overall, this release was a fun way to move away from just working on back end, refreshing/updating my knowledge on front end stuff and working on issues that were in between the two. I can't design things to save my life, but I can probably implement the design in React! Since I can do back end and front end things, I'm now a full stack developer right? Probably not.
For 0.8 alongside triaging issues, my goal is to try to get Kubernetes/minikube up for Production.
No comments:
Post a Comment