OSD700 Release 0.7

I tried to become a fullstack developer for this release. It... went better than I thought somehow? For this release I finally got to work on some front end. I remembered again why I like the back end so much more.

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.

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.

Fullstack Developer Wanted??

I don't get these job postings.

There was apparently an infamous post written on Medium by a big named guy declaring Fullstack is dead. 

After working on Telescope, I think so too. The field is so broad now with ever increasing amounts of technology a developer is supposed to know. A typical fullstack developer posting on sites goes as follows

We're looking for a fullstack developer with the following experience:

• Node.js + Express/Java/Golang/Python/.Net
• Javascript, CSS, HTML5
• Angular/React + Redux/Vue
• Docker
• No SQL: MongoDB/ Cassandra/ DynamoDB
• SQL: Oracle/ MySql
• AWS (may or may not include serverless functions)
• GIT

Bonus if you have experience with the following:

• Redis/Memcached
• User Experience design
• GraphQL
• CI/CD: Travis, Circle
• Kubernetes
• JWT/Auth0

WTF? One of the students in the class has spent pretty much a semester if not two, just learning and trying to implement SSO for Telescope. I mean I understand this is a wishlist, but this is insane. You might as well hire my Open Source Prof, @humphd at this rate. Thanks.  

OSD700 Release 0.6

Worked on a few issues for Telescope for this release:

GraphQL documentation for Telescope
Issue can be found here

This was fun, I knew nothing about GraphQL going into this. By the end of it I was even hacking away at nested queries on my own branch which we haven't even implemented yet in Telescope. I always shied away from documentation, because I rather be coding. I guess it is true. To see if you've really learned something, you should be able to explain or teach it to someone else.

GraphQL filters for Telescope
Issue can be found here

Aside from documenting on how to use GraphQL, I also took on an issue which required me to rewrite some queries to allow filtering and support future search functionality for the front end. This taught me some pain points about GraphQL as I always assumed it could do stuff like a traditional database, fro example: select * from posts where posts > provided date or something along those lines. GraphQL cannot or rather is unable to support this without installing another library, I ended up writing my own logic to do filtering and pagination.

On a side note, I also learned people can publish scalars(GraphQL typing) in packages for other people to download and use.

Include logic to filter inactive feeds and invalidate inactive feeds for Telescope
Issue can be found here

Another issue I started over the Christmas weekend and finally finished. This went through a few iterations and in the end it was suggested to scrap the current code written in favor of a more Redis oriented solution.

Refactor promises for plumadriver
Issue can be found here

I was suggested this issue by our prof, since I did quite a bit of work on refactoring promises for Telescope. It was an interesting experience reading typescript code and contributing to another repository after a few months of just working on Telescope.