Recently, I've spent some time digging into the advantages of using GraphQL over REST. As a developer who is more passionate about the client-side, the intersection of providing a user with an experience that doesn't overload them with data and being able to seamlessly make changes independent of the backend is where GraphQL comes into play.
REST
RESTful APIs are stateless servers, which means they rely on strict endpoints to gather data needed by the client, rather than attempting to remember or hold onto prior requests. In order to obtain the needed data, more often than not, multiple endpoints are needed to acquire all the data needed in the application. Each endpoint resolves to specific objects, gathered most typically using an id. There are several disadvantages to this frontend-backend communication. For starters, a lot of the data contained at each endpoint is irrelevant to the UI, peripheral info associated with the user, but unnecessary or unused once returned. This is considered OVER-fetching data, which is turn can exhaust a user's data plan. Eating up the user's data is certainly not going to bring them back to the application time and time again. Additionally, the unneeded data can slow down the loading of information. On the flipside, UNDER-fetching data, requires more calls to be made to obtain all the data needed for the particular client.
Another disadvantage is that because REST APIs have strict guidelines on the endpoints needed and data returned, they are inflexible to immediate changes needed in the UI on the frontend. The backend would also need to make changes in order to accommodate the requests.
GraphQL
GraphQL, created by engineers at Facebook, utilizes a single request to fetch all information. The fetch uses query parameters to obtain the precise information needed for the client, no more, no less. Once the server receives the query, it is processed and resolved, then packaged in JSON and returned to the client, neat and tidy. With gathering only the specific data required, the user isn't overloaded with unneeded data. Changes on the client-side can be made without any extra work on the server, therefore frontend and backend can be independent of each other. GraphQL uses a strong type system to define the capabilities of the API, called a schema, which is essentially a contract betweent he client and server sides. Once defined, all further interactions are independent. GraphQL is more efficient and flexible. For instance, take any any information or communication application (facebook, twitter, blogs, etc.), if you want to display only top stories, recent posts or a handful of followers, GraphQL allows you to determine what exactly is returned and shown to the user. Prior, all of the data is obtained via varying endpoints, regardless of what the client-side needs, slowing the whole process down, end to end.
TimezoneSupport #111
Within the legacy codebase, I am taking a look at the timezone support issue. The issue is asking for consideration around supporting users within different timezones and the scheduling portion is very dependent on availability. I'm making the assumption that current time slots of 8:00 - 8:30, 12:10 - 12:40 & 4:10 - 4:40 are based on MT. In this current set up, anyone outside of mtn time would need to make their own conversions in order to be paired. This is a less convenient approach and could be improved.
I started looking within the components at the ScheduleCard to understand what helper functions it was using. I then went to the helper directory as well as the thunk directory to view the functionality. Within the thunk directory, there was a helper function that setAvailability based on time. The available 30 minute blocks were hardcoded, so it did not appear to account for timezone. Another helper function determineDisplayTime only accounted for morning, lunch or afternoon times, but again, these were hardcoded.
I familiarized myself with the redux portion of the the application, specifically the scheduleReducer and setSchedule actions.
My first wonderings are if the times are negotiable and if so, then functionality to allow users to opt in to varying times would allow cross timezone pairing. If not, then the user would need to specify in their profile setup, their timezone, meaning it would dictate the pairings. While this is doable, it's also limiting by nature.
My approach would be to allow users to select in to different time slots, having a range of available times. They could then be paired with another dev (who would not necessarily need to opt into different time slots) as the user opting in would agree that they could meet outside of the set schedule. For instance, an east coaster could in fact be available at 10:00 on Fridays, therefore they could be paired with a mtn time zone dev at the predetermined 8:00. Ideally based on your specified timezone when setting up profile, you would be able to see other's availability based on your time preferences. As a user, if I set my preference at 8:00 - 8:30, I would only be paired with users whose converted times aligned with mine. This would alleviate the need for anyone to convert their own times. They technically wouldn't even need to know what timezone the other person was in, they would just need to know their both theirs and the other user's timezones were compatible. If I'm available at 8 and an east coast user was available at 10, we could be matched.
Within the thunk directory, the formatPairingsForQuery would also need to change.
##CORS
CORS stands for Cross Origin Resource Sharing, which is a library of allows a request to come from a different origins/URLs. We need to specify our access to another origin or vice versa.