Jan. 12, 2019
I picked up a few projects to help support my friends (they include data journalism platform about China and a mini web-series! I can't wait to share them when they're ready!)
We need a simple, fast way to get up static sites with SEO, sites that can be Google'd easily; that usually means server side rendering (ssr). Basically Google's bots crawl on the server side to gather relevant info to feed into your search results.
Check out this tweet for visuals.
My readings and recommendations from friends led me to Next.js and Gatsby.js. I've dove a bit into the initial reasons to use Next.js and server side rendering through my work place (it led me into Netflix dev team's awesome run down on their switch.) Server-side rendering, especially the pre-rendering can save a lot of performance for the user if there's a lot going on. But all that management might be more bloat if what you're creating is actually really slim. Gatsby.js was introduced to me through my friend, Sophia who is experienced in building slim sites as a freelancer. The basic run down is Next.js would be more beneficial for web apps, things that need a lot of interactions and data exchanges. Gatsby is great for more simple displays or basic info.
There is plenty of useful debate between Next.js and Gatsby.js on Reddit.
Nov. 29, 2018
I first learned about progressive web apps when I took part in Milwaukee's Hack4MKE, a hackathon for civic engagement.
A large group of us were trying to create an app for people to use when stopped by police. It was an interesting proposal. The group of ladies from Girl Develop It took on the front-end of the development.
A few weeks after this, I had some browser caching and saving to look into myself. My work place is creating a multilingual e-commerce site with server-side rendering (SSR). This was my first time working with SSR.
I didn't understand the implications until I started implementing a level of persistence to the language toggling. We used react-intl to implement the language change.
Layered above the app we had our Apollo wrappers to handle API calls. At first I wanted to store it in the browser - in the local storage, but then I thought it would be fun to play with Apollo's new apollo-cache.
Both lines of thoughts were a bit futile when I saw that it'd be a bit cumbersome to access the browser's storage or cache from the server. I was basically telling the server to look at the browser for information - when the browser didn't exist in the server.
Running into that wall, I also learned that another method of preservation in browsers, service workers. They're basically snippets of code that can exist in the browser, even if you change the page. A classic example I've creating is thinking how does Facebook send me notifications on the web event though I've already switched to procrastinating on YouTube? Thinking about that - it's quite crazy thinking how much data can be passively collected from individuals. These service workers are what makes progressive web apps so powerful even when 'off-line'. The service workers will help save information (usually pages) into your browser's cache or storage, so that pages a 'usable' when offline and activates and reconnects to servers when it connects to the internet.
Anyway the solution to my problem at work: we simply moved the state change for the language up a level onto Apollo Wrapper so that it holds the data even though the page refreshes.
P.S. for the hackathon, I ended up working with my dear brother, Jordan, on a voting poll locator. We used Geolocation and Civics. Jordan is a new to programming. I has used most of the hackathon time showing him how to make API calls and creating a simple app with React. :)