Trying to implement Apollo client for making GraphQL queries
Worked on the mobile app that I'm doing with a friend.
Reading more articles on proper ways to write tests for the app.
Setup Auth0 integration with Graphcool
Setup Graphcool's hosted backend for my database, so now I can use GraphQL for my queries
Read Kent C. Dodds's articles on testing and going to try out a TDD approach.
Netlify's support helped figure out what was causing the build issue and was able to resolve it
Got Netlify functions working, the Spotinst functions were causing timeout when called from the app.
Almost got caching working with Netlify's CDN for an API response
Read up on different CDNs and their functionalities
Looked into another BaaS, Baqend, when I was reading up on API Edge caching. Going to try them out as a possible alternative to Firebase.
Read more about GraphQL and surrounding technologies like Apollo, Graphcool, Prisma, etc.
Read about GraphQL and Apollo and it sounds very interesting, so thinking about trying that out as well
I've been paying attention to those- graphql really seems like the future of APIs.
As a query language GraphQL seems to make a lot of sense compared to the REST, but the implementation of the language to get the actual data from the database seems a bit fuzzy to me. Did a lot of reading today and started getting more confused about the different technologies surrounding it and what they try to accomplish like Apollo, Graphcool, Relay, Prisma, etc.
Read up on Cloudflare workers and going to try them out
Moved from using AWS Lambda to Spotinst Functions because it costs half as much and the API calls are free unlike AWS. The functions only run for less than 10ms, but the network latency of connecting to and getting the data is actually about 100ms, which reduces the savings in speed from using a caching layer.
Research different types of feeds and how to cache them. Read up on scaling problems that might arise with this type of architecture.
Finished adding Redis through AWS Lambda, but ran into issues with the latency being ~300ms. Turns out creating a new Redis connection on each Lambda call is expensive, so just reusing the same connection, which brings it down significantly.
Fell into a rabbit hole with trying to access Redis through client-side javascript and spent 20+ hours getting nowhere 😞
Didn't want to have additional overhead of running a cloud function to access Redis, so tried exploring a Rust -> WebAssembly -> Javascript approach as maybe a way to get Redis working on client side javascript. But unfortunately, getting WebAssembly to even work with the current project was hard enough and getting Rust to compile to WebAssembly in a format that's working was even harder. Due to the amount of time spent of this already, I'm going to move forward and just have AWS Lambda function get the data from Redis.
Researched API request caching and decided to manually setup a Redis cache for read requests to Firestore
Integrated Firebase's Firestore database
Created responsive nav bar
